#data factory

Azure Functions/Azure Automation:

Empezamos por los servicios más baratos de todos. Estos servicios nos permiten ejecutar código (de diferentes lenguajes) haciéndoles un llamado. Ambos permiten generar una URL que al recibir un request, empezara a ejecutar el código. Este código deberá ser capaz de autenticarse en Azure y ejecutar determinadas acciones. Normalmente, se utilizan para operaciones menores ya que están limitados en su poder de procesamiento y duración máxima de la ejecución.

¿Cómo los uso?

En el caso de Azure Functions, hay que crear una función HttpTrigger (viene como ejemplo en cualquier lenguaje), hacer el deploy desde VS Code (crea automáticamente los recursos en Azure) y esto nos generará la URL a la cual deberemos hacer el request. Para llamarlo desde Data Factory hay 2 opciones: podemos usar el activity dedicado a esto (Azure Function Activity) o usar el Web activity (recomiendo usar el activity porque ofrece mejor seguridad y control de errores). En Azure Automation es muy similar solo que funciona sin una función en particular (ejecuta todo lo que haya dentro) y no lleva deploy porque se edita directamente desde el portal. Acá debemos crear un Runbook con el código y luego dentro de ese mismo runbook, crear un Webhook. ¡Es importante aclarar que un runbook puede tener más de un webhook! Para llamarlo desde ADF tenemos la opción de usar un Web activity o usar Webhook activity. La diferencia es que webhook activity quedara esperando a que el runbook envíe una confirmación de que la ejecución se realizó con éxito. Un ejemplo de este tipo de llamada lo encontramos aquí: https://docs.microsoft.com/en-us/azure/analysis-services/analysis-services-refresh-azure-automation

Azure Databricks:

Databricks es un servicio que nos ofrece la posibilidad de crear clusters donde se va a ejecutar el código que necesitemos. Es decir, este servicio ya no es serverless como los anteriormente mencionados, sino que en este deberemos elegir el hardware y dispondremos del mismo de forma dedicada (o sea sin compartir con otros usuarios que estén utilizando Databricks).

La desventaja de ser dedicado es que tendremos una demora de unos pocos minutos al hacer el llamado ya que el clúster deberá encenderse antes de poder correr nuestro código. Compensa muy bien la desventaja con que ofrece el uso de spark, R, python y hasta SQL (SparkSQL) para hacer nuestras transformaciones, con todas las ventajas que trae ese lenguaje (paralelismo, manejo de grandes datasets que sean más grandes que la RAM disponible, la librería delta lake, optimizaciones, etc).

Usarlo es bastante simple, Data Factory tiene una categoría de actividades llamada Databricks, desde donde podremos llamar una notebook, un .jar (Java) o un Python script. También tenemos la posibilidad de hacer un llamado con Web Activity a databricks utilizando el API, pero teniendo opciones más simples de configurar es difícil que valga la pena el esfuerzo.

Stored Procedures:

Los procedimientos almacenados en bases de datos son buenas formas (aunque a veces un poco limitadas) de realizar todo tipo de operaciones sobre los datos. Las principales ventajas de este metodo es que casi todo el mundo que haya trabajado con datos sabe o conoce SQL, y que no tendremos un costo extra, ya que se ejecutara sobre el mismo hardware donde está la base. Las desventajas son: 

Los datos necesitan estar en una tabla de la base antes de que sea posible tomarlos para realizarles operaciones (con excepción de Polybase) 

Puede que este método no escale muy bien si los datos a procesar son cada vez más grandes, lo que congestionara la base y la dejara menos rápida para responder consultas mientras este procesando. Esta desventaja puede ser mitigada usando alguna tecnologia de procesamiento paralelo como la que ofrece SQL Pool de Synapse por ejemplo.

Para llamar a un procedimiento almacenado desde Data Factory podemos usar el activity llamado “Stored procedure” para la mayoría de las bases de datos. Otro método más “rustico” para hacer el llamado es utilizando un Lookup activity, configurando en Settings Query y pasando el comando de base de datos para ejecutar un procedimiento almacenado (en Sql Server por ejemplo, seria “exec [NombreSP]”), esta opción nos permite llamar a procedimientos almacenados en bases de datos que no estén soportadas por el Store Procedure Activity (Oracle, IBM, etc).

Data Factory Data Flows:

Previamente mencione que es prácticamente otra herramienta, pero no por eso es menos valida que las otras opciones que hemos visto en este artículo. Tiene la facilidad de ser muy visual, muy “estilo Microsoft”. Está integrada a Data Factory por lo que podremos usarla desde la misma interfaz y es simple hacer llamados a los procesos que definamos en este servicio.

Este servicio utiliza la configuración que hayamos puesto en nuestro Azure Integration Runtime para levantar un clúster de spark (muy similar a Databricks) donde se ejecutaran las operaciones que definamos en el Flow. El costo también es parecido a Databricks, solo que en este nos ahorraremos los DBU, que es como la “licencia” por usar databricks. Otra ventaja fuerte que tiene es que nos permite ir paso a paso viendo como quedaran los datos para asegurarnos que estamos haciendo las operaciones correctas, y que permite el uso del formato Delta Lake (de nuevo, igual que databricks).

La desventaja que tienen es que solo permite hacer operaciones a nivel visual, o sea no admite código. Esto lo hace deseable para operaciones pequeñas, pero no para procesos complejos, ya que la falta de comentarios en el código y lo diverso de las interfaces de cada operación pueden hacer difícil el seguimiento de procesos largos. Además, tiene un delay de unos minutos hasta disponibilizar el clúster.

Para usarlo, hay que crear un Data Flow en Data Factory y llamarlo desde algún pipeline con la actividad homónima.

Power Query:

Otra de las opciones que tenemos es Power Query (previamente llamados Wrangling Dataflow en Data Factory), el querido lenguaje M que se usa en Power Bi al ingresar en su editor de consultas. Es una muy buena opción para cuando tenemos que migrar un pbix grande hacia Azure para hacerlo escalar, y también es buena opción si nos sentimos cómodos usando el lenguaje ya que es más versátil de lo que parece inicialmente.

Su uso es similar a Data Flow, ya que tiene una interfaz integrada al portal de Data Factory. Y se lo llama de manera similar también, usando Power Query activity. Lamentablemente al día de hoy, esta opción no está disponible en Synapse Pipelines (la versión de Data Factory integrada con Synapse)

Integration Services:

El viejo y confiable SSIS (Sql Server Integration Services) tambien puede ser ejecutado y orquestado por Data Factory. Si bien es un poco incomoda la forma de desarrollar procesos en este servicio, la realidad es que es super comodo si ya tenemos procesos muy grandes y que no podemos migrar por cualquier motivo (no hay tiempo, son procesos legacy, no se van a modificar, etc). Para modificar el proceso tendremos que tener una version de Visual Studio tradicional (no VS code), con el modulo de SSIS instalado, ademas del proyecto de SSIS. Si cumplimos con tener eso, es una herramienta bastante simple que cumple con lo que buscamos: conectamos a diversas fuentes de datos, hacemos transformaciones y guarda el resultado.

Para usar este metodo, hay que crear un Integration Runtime particular llamado "Azure-SSIS IR", el cual debera correr sobre una base de datos SQL Server Standard o Enterprise que deberemos crear para este fin. Una vez creada esta base de datos, deberemos abrir el proyecto de SSIS y hacer el deploy del proyecto sobre la misma. El ultimo paso para ejecutar el paquete de SSIS dentro de Data Factory, sera llamarlo desde un pipeline con el activity "Execute SSIS Package".

Las desventajas de este metodo son los costos, ya que al tener que usar una licencia de Sql Server, los costos seran altos de entrada. La dificultad para modificar y documentar proyectos existentes es otra contra, al ser una herramienta un poco vieja no esta adaptada al desarrollo en nube, y es mas incomoda que otras opciones.

Azure Batch:

El último servicio que veremos aquí es Azure Batch, que es el más “viejo” de todos, se usaba en los inicios de Data Factory v2 para ejecutar el “Custom Activity”. Este servicio básicamente nos permite disponibilizar una máquina virtual donde se ejecutará un script con las operaciones que necesitemos. Es bastante más complicado de configurar que el resto de los servicios, y en mi opinión ofrece poco para compensar. Aquí seremos responsables de crear la máquina virtual, instalar el lenguaje necesario, sus librerías, almacenar certificados con credenciales de acceso, además de codear el script que realice las operaciones. Solo consideraría esta opción si la empresa donde estamos trabajando ya dispone de pools de VMs listas para usar en Batch (ya que se puede usar este servicio con muchos fines distintos a solo procesamiento de datos).

Por supuesto que esta no es una lista exhaustiva de las opciones que tenemos, pero seguro que son las más populares que consideraremos al momento de tener que hacer operaciones con datos desde Data Factory.

Ojalá les haya sido de ayuda este repaso, o les despierte la curiosidad por estudiar un poco más en profundidad alguno de estos servicios, ¡hasta la próxima!

¿Que es?

Empecemos por mencionar que es Data Factory, y porque es una herramienta casi imprescindible:

Pipelines!! Es simple agregar actividades (y dependencias entre ellas) como llevar datos de un storage a otro, buscar datos en bases de datos, condicionales, y todo tipo de estructuras de control.

Interfaz gráfica simple de entender, cualquiera que le dedique 10 minutos a ver la interfaz podrá entender y hacer algún pipeline básico para orquestar algún proceso.

Múltiples opciones de calendarización de pipelines gracias a los Triggers (disparadores), en función a eventos, ventanas de tiempo, según día, hora, numero de día. Por ej: el primer día de cada mes, todos los Miércoles, etc.

Parámetros: igual que en cualquier lenguaje de programación, podemos usar parámetros para alterar el funcionamiento de algunos componentes como Pipelines, Actividades, Datasets, etc. Pueden usarse básicamente en cualquier lugar donde haya un string, para evitar errores lo mejor es encapsular el llamado a parámetros en @{nombreParametro}. Nos permiten recorrer bases de datos enteras con 1 o 2 actividades.

Variables: podemos almacenar valores en variables para utilizarlos después, se asignan con la actividad de asignar variables y se llaman del mismo modo que los parámetros.

Modularidad en diseño: podemos "encapsular" ciertos procesos que vamos a repetir frecuentemente en un pipeline y después llamarlo desde otro pipe, mediante la actividad "Ejecutar pipeline", esto brinda mucha flexibilidad a la herramienta si agregamos el uso de parámetros y variables.

Serverless!! Nunca sabemos (ni nos importa) donde están los servidores que ejecutan los trabajos. Solo darle play al pipeline y Azure se encargara de manejar por nosotros la memoria, ancho de banda, procesador, etc. Hay algunas excepciones, como en el caso del Integration Runtime (que sera instalado en una pc/vm on premise) o los Mapping Dataflow (en los cuales elegimos el tamaño del cluster que sera provisto).

Alertas configurables para enterarnos inmediatamente cuando algo anda mal, con la opción de ser informados mediante Email, SMS, Push (notificación en el celular), o con un mensaje de voz. Esto se logra gracias a la integración con Azure Monitor.

Soporte para utilizar Polybase al mover datos entre un Data Lake o Blob Storage y Synapse, aprovechando la mejora en performance de esta tecnología.

Conexión con muchos servicios!! Mas de 80 conectores, literalmente se conecta a todo lo que este dentro de Azure, pero ademas puede interactuar con varios servicios de otras nubes como AWS (S3, Redshift, etc), recursos que se encuentren en redes on premise (requiere la instalación de un Integration Runtime) e incluso soporta Rest apis o conexiones ODBC, así que si un servicio no esta en el listado pero soporta esas formas de conexión, también sera posible conectarnos.

Múltiples tipos de archivos soportados: Json, Csv, Excel, ORC, Parquet, Avro, Binario (cualquier archivo, no sera interpretado el contenido).

Soporte para trabajar de forma cooperativa gracias a la integración con Git, se pueden usar repositorios en GitHub o Azure DevOps. Como todo su código son definiciones en Json, podemos enviar ese código a un repositorio y trabajarlo con una metodología similar a la de desarrollo convencional. Por ej: creamos nuestro propio branch, desarrollamos una feature, y una vez que esta todo testeado y funcionando, creamos un pull request a master.

Soporte para deploys automáticos, de modo que podemos tener entornos separados y asegurarnos que solo llegan a producción aquellas versiones de código que sabemos que funcionan bien.

Esas features mencionadas son excelentes! Ya podemos ver porque no imagino un proyecto de analítica ejecutado en Azure sin usar Data Factory.

¿Que NO es?

A pesar de todas las bondades del servicio, es notorio que cuando arrancamos a utilizarlo muchas personas esperan mas de el, y creo que es porque por todos lados lo muestran o publicitan como una "herramienta ETL", siendo que no lo es en un 100% (al menos en su versión básica). Por eso, para evitar malos entendidos y tener opciones para evaluar, acá va un listado de las cosas que NO es Data Factory (con sugerencias de solución):

NO es una herramienta de transformación de datos! Su principal objetivo es ser un orquestador, mantener servicios y procesos trabajando, moviendo los datos de un modo coordinado, con todas las ventajas nombradas anteriormente. Recientemente se añadió la posibilidad de hacer algunas transformaciones de datos gracias a sus dataflows (Wrangling y Mapping), pero aun así es una opción con mucho tiempo de startup, bastante costosa y mi recomendación es siempre utilizar algún servicio externo para hacer las transformaciones (puede ser Databricks, T-SQL en una base de datos o en Synapse, para algo sencillo Azure Functions o Automation).

NO maneja de forma automática las cargas incrementales! Esta es una consulta habitual que tengo entre los clientes. No es complicado de hacer, pero tampoco es tan straight-forward como muchos esperan (sobretodo si tienen experiencia previa con alguna herramienta ETL como StreamSets, Pentaho, Talend, NiFi, etc).

Por si solo NO prende o apaga servicios tales como Synapse, o Analysis Services. Para esto sera necesario escribir un pequeño script en PowerShell para ejecutar en Azure Automation o en uno de los múltiples lenguajes que soporta Azure Functions. Por supuesto que Data Factory si tiene capacidades para llamar a esos servicios y ejecutar el encendido o apagado de estos servicios. Cuando nos conectamos a Databricks, si tiene la capacidad de encender un job cluster, ejecutar un código y apagarlo.

Lo mismo sucede con el refresh de modelos en Azure Analysis Services, para estos sera necesario un script en alguno de los servicios mencionados previamente. Otra opción es disparar el refresco mediante la REST api del servicio.

Data Factory NO almacena datos (solo metadatos), de modo que si creamos un dataset para una tabla en una base de datos que tiene 1 millón de registros, ese dataset solo tendrá la forma de acceder a la base de datos (mediante su linked service), el nombre de la tabla, tipo de dato de cada columna, pero bajo ningún escenario contendrá todos los registros en Data Factory.

Entre actividades SOLO podemos intercambiar Metadata! Con la excepción de Lookup activity, que nos devolverá el resultado de una consulta como output de la actividad, que podremos consultar desde otras actividades o asignarlas a variables.

Seguro estoy olvidando algunas limitaciones o beneficios, pero a modo introductorio creo que estos son los puntos principales a tener en cuenta al momento de crearnos expectativas respecto a las capacidades del servicio.