Introducción

En el siguiente post, veremos el procedimiento con el cual podremos realizar la puesta a punto de una arquitectura hibrida, 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.

 

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.

 

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.

 

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.

Azure Storage Account

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.

 

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.

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.

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

Tras finalizar la configuración anterior,en

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.

 

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.

 

 

 

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

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.

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.

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

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).

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.

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.

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.

 

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.

 

 

 

 

Cristian Tomás Sáez

Data Platform Engineer at SolidQ
I am working for SolidQ as "Data Platform Specialist". I studied Telecommunications Engineering at University of Alicante. Linked to the technological world, I started my career creating applications for different platforms (Android / IOS).

I have started at SolidQ through the HackForGood 2016 contest organized by Telefónica, being a member of the HackForLife team.

http://2016.hackforgood.net/otros-premios-globales/
Cristian Tomás Sáez

Latest posts by Cristian Tomás Sáez (see all)