Introducción

En el siguiente post, veremos el procedimiento con el cual podremos realizar la puesta a punto de una arquitectura híbrida, comentando los requisitos y diferentes configuraciones necesarias para su creación y funcionamiento.

Para esta arquitectura, debemos también comentar como antecedentes la arquitectura clásica de un dwh y la arquitectura Dwh moderna.

Arquitectura Tradicional DWH

Teniéndolo como el componente central del Business Intelligence ya que aporta a las empresas la posibilidad de analizar y respaldar una amplia gama de decisiones de negocio, vemos como en su arquitectura tradicional y sin tener en cuenta posibles variantes y casos excepcionales, se tiene en el flujo de “movimiento” de los datos, el que desde un origen OLTP se pase a una capa de Staging pasando por una fase de extracción, transformación y carga en cada transición hasta finalmente almacenar los datos en nuestro Data Warehouse.

 

Entornos tradicionales de BI desplegados en arquitecturas cloud

Modern Datawarehouse

Mediante las arquitecturas de Modern Data Warehouse  podríamos optar a los siguientes beneficios sobre las arquitecturas tradicionales:

  • Capacidad de manejar una variedad de áreas temáticas y diversas fuentes de datos.
  • Capacidad para manejar grandes volúmenes de datos.
  • Expansión más allá de una sola estructura DW / data mart relacional (para incluir estructuras como Hadoop, data lake y / o bases de datos NoSQL)
  • Arquitectura multiplataforma que equilibra la escalabilidad y el rendimiento.
  • Virtualización de datos además de integración de datos.
  • Capacidad para facilitar el análisis casi en tiempo real de datos de alta velocidad (potencialmente a través de la arquitectura Lambda)
  • Integración híbrida con servicios en la nube.
  • Governance para apoyar la confianza y la seguridad.
  • Gestión de datos maestros para la conservación de datos de referencia.
  • Soporte para todo tipo de usuarios y todos los niveles de usuarios.
  • Soporte para BI de autoservicio para aumentar el BI corporativo
  • Exploración de datos, además de informes y paneles.

 

Entornos tradicionales de BI desplegados en arquitecturas cloud

Hybrid Architecture

Respecto a esta arquitectura, tendremos en cuenta dos partes diferenciadas. Una parte OnPrem en la cual tendremos ubicados los origenes OLTP y cualquier BBDD que vayamos a utilizar como replica de ese origen y que vayamos a utilizar como puente hasta la capa de staging.

En cuanto a la segunda parte, esta se encontrará en Azure, donde haciendo el uso de diferentes servicios podremos tener tanto las bbdd de STG y DWH como nuestro modelo tabular desplegados en la nube.

Entornos tradicionales de BI desplegados en arquitecturas cloud

 

Requisitos en la Arquitectura

Una vez comentado lo anterior procederemos a comentar los requisitos necesarios que debemos de crear en Azure y que nos serán necesarios para esta arquitectura.

Para ello, nos dirigiremos al portal de Azure  y generaremos los siquientes recursos:

  • Azure SQL Databases
  • STG
  • DWH
  • Azure Storage Account
  • Data Factory v2
  • SSIS Azure
  • SSAS Azure

 

Datawarehouse: stg + dwh Azure sql databases

Azure SQL Database es un servicio administrado de base de datos relacional de uso general que le permite crear una capa de almacenamiento de datos de alto rendimiento y alta disponibilidad para las aplicaciones y soluciones en la nube de Microsoft Azure.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Azure Storage Account

Entornos tradicionales de BI desplegados en arquitecturas cloud

SSAS Azure

Azure Analysis Services es una plataforma como un servicio (PaaS) completamente administrada que proporciona modelos de datos en la nube de nivel empresarial. Use las características de modelado para combinar datos de diversos orígenes de datos, definir métricas y proteger los datos en un modelo de datos semántico tabular único y de confianza.

Entornos tradicionales de BI desplegados en arquitecturas cloud

 

DataFactory v2

Tal y como se hace referencia en la web de Microsoft, Azure Data Factory se trata de un servicio de integración de datos basado en la nube que le permite crear flujos de trabajo orientados a datos en la nube a fin de coordinar y automatizar el movimiento y la transformación de datos. Con Azure Data Factory, puede crear y programar flujos de trabajo basados en datos (llamados canalizaciones) que pueden ingerir datos de distintos almacenes de datos.

Entornos tradicionales de BI desplegados en arquitecturas cloud

SSIS Azure

Para la ejecución de SSIS en Azure, nos será necesario el uso de Azure Data Factory ya que se trata de un servicio interno que presenta.

Para ello, una vez estemos dentro del panel interno de Azure Data Factory, deberemos de seleccionar la opción de Configure SSIS integration donde en los pasos posteriores configuraremos nuestro SSIS integration runtime.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Tras seleccionar esta opción, nos aparecerá una ventana de configuración donde enlazaremos nuestro servidor onPrem con el SSIS azure.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Tras finalizar la configuración anterior,en Entornos tradicionales de BI desplegados en arquitecturas cloud

Del mismo modo que para el caso de la configuración de Azure SSIS, debemos de crear un enlace entre nuestro entorno en Azure con nuestro origen OnPrem para que una vez generemos en Azure data Factory una ejecución  tengamos conectividad a nuestro origen de información.

Entornos tradicionales de BI desplegados en arquitecturas cloud

 

Entornos tradicionales de BI desplegados en arquitecturas cloud

Tras toda la configuración anterior, podemos comenzar a generarnos dentro de Azure Datafactory una serie de pasos de ejecución, los cuales en cada paso podremos realizar diferentes tipo de ejecuciones.

Para el siguiente ejemplo, podemos diferenciar entre ejecuciones de procedimientos almacenados y ejecuciones de paquetes de SSIS.

 

Entornos tradicionales de BI desplegados en arquitecturas cloud

 

 

Para el caso de las ejecuciones de Procedimientos almacenados, la configuración interna es la siguiente:

Entornos tradicionales de BI desplegados en arquitecturas cloud

Tenemos un apartado General donde podemos asignar un nombre al paso, el timeout y tanto la cantidad como el intervalo de tiempo para posibles reintentos en el caso de que se de algún error de ejecución.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Por otro lado tenemos el apartado de SQL Account, donde debemos de asignar el Linked Service que corresponde al servidor OnPrem donde tenemos creados los Procedimientos almecenados deseados.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Finalmente, tenemos la opción de Stored Procedure donde asignaremos a que procedimiento almacenado queremos llamar.

Entornos tradicionales de BI desplegados en arquitecturas cloud

El otro tipo de proceso que nos encontramos en el ejemplo es la ejecución de un paquete de SSIS ubicado en el catalogo de SSIS (SSISDB).

Entornos tradicionales de BI desplegados en arquitecturas cloud

Entre su configuración, en el panel de General podemos tanto modificar el nombre, como la cantidad de reintentos y su  intervalo en el caso de que tengamos algún error en las ejecuciones.

Entornos tradicionales de BI desplegados en arquitecturas cloud

En el panel de Settings, enlazaremos con el Azure runtime que hemos configurado previamente y donde habremos desplegado previamente en el catalogo de SSIS nuestros paquetes .dtsx.

Entornos tradicionales de BI desplegados en arquitecturas cloud

Por otro lado, también tenemos la configuración de los parámetros de SSIS en los que podremos asignar los diferentes cadenas de conexiones como pueden ser usuario, contraseña y punto de conexión a las diferentes bases de datos implicadas en la carga.

Entornos tradicionales de BI desplegados en arquitecturas cloud

 

Conclusión

Mediante la anterior solución, podemos implementar una arquitectura híbrida que permite una convivencia entre una arquitectura tradicional DWH con servicios en la nube que nos ofrece Azure.

De este modo, podemos ahorrar costes de mantenimiento, tanto por un uso menor de servidores OnPrem como por el uso de SSIS sin necesidad de una licencia de SQL Server. Además, tenemos la confianza que nos aporta que todo el desarrollo este gestionado por Azure.

 

 

 

 

0 Shares:
2 comments
  1. Buenos días,

    Pero cual seria el coste aproximado de esta solución mensualmente?. Es que en la calculadora de Azure puede dispararse mucho.

    Muchas gracias.

    Un saludo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

NOEXPAND y las vistas indizadas

Optimizar vistas indexes NOEXPAND. No siempre el optimizador de consultas de SQL tiene toda la información necesaria para generar el mejor plan de optimización y a veces hay que ayudarle, en este caso los desarrolladores de Navision han utilizado la siguiente opción para salvaguardarse.