En este artículo vamos a ver las formas más comunes de llamar a servicios de procesamiento externos.
Muchas veces se confunde a Data Factory con una herramienta ETL, cuando en realidad es un servicio de integración de datos y orquestación de procesos. La actividad estrella en Data Factory es el "Copy Activity" que permite tomar datos de una fuente de datos origen, y los deposita en algún almacenamiento destino, y ¡es muy buena haciéndolo! Soporta multitud de orígenes y destinos, permite conectar con datos on premise (incluso ODBC), consultar APIs, etc. Todo el resto de las actividades de Data Factory están hechas alrededor de Copy Activity y dan soporte a esta, ya sea consultando marcas de agua, haciendo validaciones o consultando metadata, entre otras. Lo que no hace Data Factory por sí solo (dejando afuera el nuevo Data Flow que prácticamente es otra herramienta), es realizar tareas típicas de ETL tales como filtrar filas, crear columnas derivadas de otras, controlar la limpieza de los datos, existencia de datos, agregaciones, etc, y para llevar a cabo estas tareas podemos utilizar servicios de procesamiento fuera de lo que es Data Factory. A continuación, vamos a ver algunos de los más comunes, y sus ventajas:
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!
Escrito por Martin Zurita