¿Cómo mover tus datos entre entornos híbridos con Azure Data Factory?

Una de las situaciones habituales a la que nos enfrentamos cuando queremos construir una plataforma unificada de acceso al dato dentro de nuestra organización es la necesidad de desplegar procesos de ingesta y transferencia de datos entre los diferentes sistemas de almacenamiento, que se pueden encontrar tanto en entornos On-premise como en entornos Cloud. Para la realización de este tipo de procesos se utilizan los denominados motores de ingesta que nos permiten transferir datos desde diferentes orígenes de manera ágil y escalable hacia un sistema de almacenamiento. En este post vamos a centrarnos en el motor de ingesta que permite desplegar este tipo de procesos en Azure mediante la utilización del Integration Runtime (IR) de Azure Data Factory.

¿Qué es un motor de ingesta de datos?

Un proceso de ingesta de datos consiste en cargar registros de información (datos) desde uno o varios orígenes hacia un sistema de almacenamiento de datos.

Un motor de ingesta es un componente que permite ejecutar los diferentes procesos de ingesta, orquestando los diferentes flujos de datos (movimiento, transformación, limpieza, etc.) y planificando la ejecución de cada uno de ellos en base a las necesidades de la plataforma de datos.

Desarrollar un buen proceso de ingesta nos permitirá:

• Gestionar de manera ágil grandes volúmenes de información.
• Recopilar de manera homogénea información de fuentes dispersas y de tipos de datos dispares.
• Disponibilizar y centralizar los datos de toda la organización en el menor tiempo posible.
• Disponibilizar una fuente de datos unificada que facilite el acceso a los datos en bruto de la compañía.

Existen 2 modalidades de procesos de ingestión de datos:

1. Ingesta de datos en streaming, donde los datos se van insertando en el repositorio de datos centralizado casi en tiempo real (near real-time), habitualmente mediante un sistema de eventos que permite procesar millones de eventos en casi tiempo real generados por diferentes aplicaciones productoras. Este modo de ingesta es utilizado para la ingesta de datos ligeros y con necesidades de consulta en “near real-time”.
2. Ingesta de datos en batch, donde los datos se van insertando por lotes en el repositorio de datos centralizado, habitualmente mediante procesos de carga incremental planificados periódicamente. Este modo de ingesta es utilizado para la ingesta de datos pesados donde es necesario un alto rendimiento.

En este post nos centraremos en la modalidad de ingesta en modo batch y el servicio dentro de Azure que nos ofrece estas capacidades: Azure Data Factory.

Ingesta de datos batch con Azure Data Factory

Los procesos de ingesta, en modo batch, mediante Azure Data Factory, se desarrollan mediante la construcción de canalizaciones (o pipelines). Las canalizaciones son agrupaciones lógicas de actividades que en su conjunto llevan a cabo una tarea específica, por ejemplo, ingestar todos los datos de clientes de un CRM en el repositorio central. Además, las actividades utilizan otros tipos de componentes que les permiten acceder a la información con el objetivo de completar su cometido. Estas relaciones entre componentes se pueden visualizar en el siguiente flujo:

• Linked Service (conector): son las conexiones que permiten vincular los datos de los Datasets con Data Factory. Actúan como cadenas de conexión donde se define la información necesaria para que el servicio se pueda conectar a almacenes de datos.
• Dataset (conjunto de datos materializados): son los conjuntos de datos que se utilizarán dentro de las actividades como entrada y/o salida de datos. Se suelen corresponder con una tabla o un subconjunto de los datos de una tabla o un fichero o un subconjunto de los datos de un fichero.
• Actividad (proceso): son las diferentes operaciones que componen una pipeline. Cada una de ellas define una acción a realizar sobre los conjuntos de datos (datasets).

El primer paso para comenzar a mover los datos desde entornos híbridos hacia el repositorio de datos central es comenzar a desarrollar las pipelines de ingesta de datos. Para poder ejecutar las diferentes actividades de movimiento de datos dentro de nuestra pipeline de Data Factory lo primero que necesitamos hacer es seleccionar el motor de ejecución que utilizarán los linked service de origen y destino para llevar a cabo la actividad.

Pero la gran pregunta es… ¿Qué es un motor de ejecución dentro de un motor de ingesta y cómo elegimos el adecuado para nuestros movimientos de datos?

¿Cómo elegir el motor de ejecución?

El motor de ejecución dentro de Data Factory se conoce como Integration Runtime. El Integration Runtime (IR) es el servicio que proporciona las capacidades de computación a las diferentes actividades dentro de Data Factory, proporcionando el puente entre las actividades y los linked services. Como es habitual en la mayoría de organizaciones, los datos de origen y destino se encuentran dispersos entre entornos On-premise y nuevos entornos Cloud. La localización del IR define dónde se realizará la computación y el movimiento de los datos.

El origen y el destino de la información de estos procesos de transferencia de datos, junto con la configuración de las redes de comunicaciones entre el entorno Cloud y el entorno On-premise, son elementos determinantes a la hora de definir la configuración y el tipo de IR que debe ser desplegado dentro de la plataforma. De entre las posibles opciones:

• Azure IR: servicio totalmente gestionado por Azure. Da conectividad y servicios de computación con endpoints públicos de la red de Azure.
• Self-hosted IR: servicio autogestionado. Da conectividad y servicios de computación sobre orígenes de datos que no tienen acceso directo desde la red pública de Azure.
• Azure-SSIS IR: servicio que permite ejecutar de manera nativa paquetes desarrollados en entornos On-premise de SSIS (SQL Server Integration Services).

Para decidir entre las diferentes opciones qué IR desplegar y utilizar debemos responder a una serie de preguntas que se representan en el siguiente flujo de evaluación:

En este post partiremos de las consideraciones que representan una de las casuísticas más habituales dentro de las organizaciones:

• Vamos a comenzar a construir los procesos de ingestión de datos de la compañía, por lo que no existen procesos antiguos desarrollados en SSIS.
• Los orígenes de datos que se utilizarán en los procesos de ingestión de datos no son públicos a internet, sino que utilizaremos una red privada dentro de Azure.

Por lo tanto, la elección del motor de ejecución a desplegar y utilizar en nuestros procesos de ingesta será un Self-hosted IR.

Modelo de despliegue de los Self-Hosted IRs

Un Integration Runtime autogestionado puede ser desplegado en dos posibles ubicaciones, dependiendo de la naturaleza de los datos que se utilicen en los procesos de transferencia de información:

• En una máquina virtual desplegada en el entorno On-premise. Se recomienda su utilización para la ejecución de procesos de transferencia de datos donde los orígenes se encuentran localizados en un entorno On-premise.
• En una máquina virtual desplegada dentro de Azure. Se recomienda su utilización para la ejecución de procesos de transferencia de datos donde los orígenes se encuentran localizados en sistemas de almacenamiento de Azure (cloud).

En base a las diferentes necesidades de ingesta de información, se pueden presentar 3 posibles escenarios de despliegue dentro de una organización:

• Escenario 1: despliegue de un servicio Self-hosted IR en un entorno On-premise.
• Escenario 2: despliegue de un servicio Self-hosted IR en el entorno Azure.
• Escenario 3: despliegue de dos servicios Self-hosted IR, uno en el entorno On-premise y otro en el entorno Azure.

Teniendo en cuenta el caso de uso inicial del post de ingestar y mover datos entre entornos híbridos, el escenario idóneo para este tipo de situaciones es el Escenario 3, siendo la posible arquitectura la que se muestra en la siguiente imagen:

Modo de utilización de los Self-Hosted IRs

Es muy importante seleccionar de forma adecuada el motor de ejecución sobre el que correrán nuestros procesos de movimientos de datos. Cuándo utilizar uno u otro dependerá del origen y el destino de los procesos de transferencia de datos, tal y como se ilustra en la siguiente figura:

• Para aquellos procesos de transferencia donde la localización de los datos de origen o destino a ingestar sea el entorno On-premise, se utilice el Self-hosted IR desplegado en On-premise. Ejemplos de estos movimientos de transferencia serán todos aquellos cuyo origen de datos sea un sistema de almacenamiento dentro de la arquitectura On-premise de la compañía y el destino un Azure Datalake con toda la información centralizada.
• Para aquellos procesos de transferencia donde la localización de los datos de origen a ingestar o el movimiento de datos sea dentro del entorno Azure, se utilice el Self-hosted IR desplegado en Azure. Ejemplos de estos movimientos de transferencia serán todos aquellos cuyo origen de datos sea una capa de un Azure Datalake y el destino otra capa de un Azure Datalake u otro sistema de almacenamiento final desplegado en Azure.

Conclusiones

Tal y como acabamos de ver, el Integration Runtime es el corazón de los procesos de ingestión desarrollados en Azure Data Factory. Elegir el tipo de IR adecuado para desplegar y/o utilizar es una decisión muy importante que debemos tomar antes de comenzar a desarrollar nuestros procesos de movimientos de datos.

No hacerlo de la forma adecuada podría suponer:

• Aumento significativo de costes.
  • Transferencia de descarga de datos innecesaria de Azure al entorno On-premise.
  • Transferencia de descarga de datos innecesaria a través de la red privada o VPN.
• Aumento de latencia en los procesos de datos.
  • Tiempo de descarga de datos de Azure al entorno On-premise.
  • Tiempo de subida de datos del entorno On-premise a Azure.
• Incumplimiento de las políticas de seguridad de acceso al dato de la compañía.

En posts posteriores describiremos los pasos que son necesarios llevar a cabo para la instalación de un Self-Hosted Integration Runtime dentro de una máquina virtual y cómo conectarse a los orígenes de datos.