Data Factory ¿Que es? ¿Que NO es?

Hola a todos! En esta oportunidad quiero hablarles de mi servicio favorito (y probablemente de muchos otros Ingenieros de Datos) en Azure, que es Azure Data Factory. A modo de introducción, para hacer algo distinto se me ocurrió escribir sobre que es y que NO es Data Factory, ya que el servicio muchas veces es evaluado

Es un servicio que casi todo proyecto relacionado con analítica en Azure debería utilizar, salvando algunas muy raras excepciones. Provee muchísimas ventajas y simplifica un montón de aspectos clave para estos proyectos, como calendarización, orquestación, modularidad para procesos, entre otros. Pero también tiene (como todo servicio) sus limitaciones, que si bien son salvables de uno u otro modo, pueden llegar a dejar una mala impresión cuando recién nos iniciamos con la tecnología. El objetivo de este post es aclarar que ES Data Factory y que NO es, o que no hace por defecto (y posiblemente algún work-around para esas limitaciones).

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

Espero que les haya gustado, seguramente vendrán algunos artículos mas sobre el tema.