Si trabajas a diario con orquestación de datos en Azure, tarde o temprano acabas hablando el mismo idioma: pipelines, activities y triggers. Son las tres piezas con las que Azure Data Factory construye cualquier flujo de ingesta o transformación, desde mover un fichero de un contenedor a otro hasta orquestar toda una cadena de procesos.
Qué es un pipeline
Un pipeline en Azure Data Factory es una agrupación lógica de activities que juntas realizan una tarea. En vez de gestionar cada paso por separado, defines el pipeline entero y lo despliegas y programas como una unidad. Un ejemplo típico: un pipeline que primero copia datos de log desde un origen, los limpia y después lanza un flujo de transformación para analizarlos.
Un mismo Data Factory puede alojar tantos pipelines como haga falta, cada uno pensado para un caso de uso concreto: cargar una tabla de dimensiones, sincronizar un origen externo, disparar un proceso de Databricks, etc.
Qué son las activities
Las activities son las acciones concretas que se ejecutan dentro de un pipeline: pueden tomar cero o más datasets de entrada y producir uno o más de salida. Según la documentación oficial, se agrupan en tres categorías:
Movimiento de datos. Es la Copy Activity, el caballo de batalla para mover datos entre almacenes de origen y destino, con soporte para más de cien conectores: Blob Storage, SQL Database, Data Lake Storage, Oracle, PostgreSQL, Salesforce y muchos más.
Transformación de datos. Aquí entran los Mapping Data Flows (que se ejecutan sobre clústeres Spark), las Databricks Notebook Activity, los Stored Procedure Activity contra Azure SQL o Synapse, o actividades sobre HDInsight como Hive, Pig o Spark.
Control de flujo. Actividades como If Condition, ForEach, Until, Lookup, Set Variable, Execute Pipeline o Wait, que permiten construir lógica condicional, bucles y dependencias entre pasos, en vez de limitarse a una secuencia lineal.
Un detalle práctico que conviene tener en cuenta: por defecto hay un límite recomendado de 120 activities por pipeline, contando también las que van anidadas dentro de contenedores como ForEach o If Condition.
Qué son los triggers
Un pipeline no se ejecuta solo: necesita un trigger que lo dispare. Azure Data Factory ofrece tres tipos principales.
| Tipo de trigger | Cómo funciona | Cuándo usarlo |
|---|---|---|
| Schedule | Lanza el pipeline según un calendario (cada hora, cada día, días concretos de la semana). Funciona en modo «fire and forget»: se marca como correcto en cuanto arranca la ejecución, sin esperar a que termine. | Cargas recurrentes con horario fijo, por ejemplo una extracción nocturna de un ERP. |
| Tumbling window | Se dispara sobre ventanas de tiempo fijas, contiguas y sin solape, manteniendo estado. Espera a que termine la ejecución anterior, soporta reintentos configurables y permite hacer backfill de ventanas pasadas. | Procesos incrementales donde importa no perder ni duplicar ninguna ventana temporal, como agregados por hora. |
| Basado en eventos | Reacciona a eventos de Azure Storage (llegada o borrado de un blob) o a eventos personalizados vía Event Grid, en lugar de a un calendario. | Pipelines reactivos: procesar un fichero en cuanto aterriza en un contenedor. |
Una diferencia que se pasa por alto a menudo: el trigger de tipo Schedule tiene una relación de muchos a muchos con los pipelines (varios triggers pueden lanzar el mismo pipeline y viceversa), mientras que un Tumbling Window trigger mantiene una relación de uno a uno con su pipeline.
Data Factory frente a Synapse Pipelines
Vale la pena aclarar que Azure Synapse Analytics incluye su propio motor de pipelines, con el mismo modelo de pipelines, activities y triggers que Azure Data Factory, ya que comparten motor de orquestación subyacente. La diferencia principal es el contexto: en Synapse los pipelines conviven en el mismo workspace que los pools SQL y los notebooks Spark, mientras que Data Factory es un servicio independiente pensado como hub de integración de datos.
- Usa Schedule trigger para cargas periódicas simples sin necesidad de reintentos automáticos.
- Recurre a Tumbling Window cuando necesites reprocesar ventanas pasadas (backfill) con garantías.
- Los triggers basados en eventos evitan el polling: procesan el dato en cuanto llega, no en el siguiente ciclo programado.
- Si borras y vuelves a crear un trigger de eventos, hazlo desde cero: reanudarlo puede disparar ejecuciones no deseadas sobre eventos ya procesados.
- Agrupa activities relacionadas en pipelines pequeños y usa Execute Pipeline para encadenarlos, en vez de construir un único pipeline gigante.
Una vez orquestados, ¿dónde aterrizan esos datos y cómo se organizan antes de llegar a negocio?
Leer el artículo sobre la arquitectura Medallion en Azure Databricks