Data Engineering — Módulo 6: orquestación — Airflow, Dagster y Prefect

Tenemos ingesta (módulo 3), casa (4) y transformación (5) — piezas que saben hacer su trabajo pero no saben cuándo ni en qué orden global, ni qué hacer cuando algo falla a las 3 AM. Ese es el trabajo del orquestador: el director de orquesta que convierte pasos sueltos en un pipeline operable. Es también la pieza donde “script que corre” se gradúa de “sistema que se opera” — la diferencia del módulo 1, materializada.

La tesis del módulo

Un orquestador aporta seis cosas que el cron no da: dependencias explícitas, reintentos con política, backfill como operación de rutina, visibilidad de qué corrió y qué falló, alertas cuando importa, y un solo lugar donde leer el estado del pipeline entero. Airflow es el estándar veterano que orquesta tareas; el giro de Dagster — orquestar assets, los datos que deben existir — calza especialmente bien con pipelines de IA, donde la pregunta operativa nunca es “¿corrió el paso 4?” sino “¿está fresco el dataset?”.

Qué hace un orquestador (y el cron no)

El cron dispara a una hora; el orquestador dirige: dependencias (“dbt corre cuando la ingesta termine, no a una hora estimada con dedos cruzados”), reintentos con espera y tope por tarea, backfill (re-correr enero tras el bug, con las fechas como parámetro — la promesa del módulo 2 hecha comando), observabilidad (el estado de cada corrida, sus logs, su duración — visible, no arqueológico) y alertas con criterio (la regla de la serie cloud: la alarma exige acción o es dashboard). El pipeline del curso, dirigido:

   EL PIPELINE DEL CURSO, ORQUESTADO

  02:00 ──► ┌──────────┐     ┌──────────┐
            │ ingesta  │ ──► │ dbt build│
            │ correos +│     │ (staging │
            │ CRM      │     │  → marts)│
            └──────────┘     └────┬─────┘
                     fallo:       │ ok
                     3 reintentos ▼
                     → alerta ┌──────────────┐
                              │ calidad      │
                              │ (módulo 7)   │
                              └────┬─────────┘
                                   │ ok · si falla:
                                   │ FRENA y avisa
              ┌────────────────────┴────┐
              ▼                         ▼
        ┌───────────┐      ┌────────────┐
        │ refrescar │      │ dataset de │
        │ índice RAG│      │ entrenam.  │
        │ (mód. 10) │      │ (mód. 8)   │
        └───────────┘      └────────────┘

Los tres nombres, en diferencial honesto

• Airflow: el estándar de facto, veterano y ubicuo. Los pipelines son DAGs de tareas en Python (con la TaskFlow API moderna: funciones decoradas cuyas dependencias salen de pasarse resultados). Su fuerza: ecosistema gigante de integraciones, todo el mundo lo conoce, administrado en cada nube (MWAA, Cloud Composer). Su naturaleza: piensa en tareas que corren, y el estado de los datos lo infieres tú del estado de las tareas.
• Dagster: el giro conceptual. Defines assets — “existe la tabla stg_correos, se construye así, depende de estos otros assets” — y el orquestador deriva las corridas de la pregunta qué está desactualizado. El catálogo de assets con su frescura y su linaje es la interfaz — no la lista de tareas. Integración de primera clase con dbt (cada modelo dbt es un asset visible en el mismo grafo).
• Prefect: el pragmático pythonista — flujos que son funciones Python con decoradores, mínimo ceremonial, muy cómodo para equipos que ven la orquestación como “mi código Python, pero confiable”. Menos opinión estructural que Dagster, menos peso histórico que Airflow.

Criterio	Airflow	Dagster	Prefect
Unidad mental	Tarea que corre	Asset que existe	Flujo/función
Pregunta que responde mejor	¿Corrió el job?	¿Está fresco el dato?	¿Corrió mi función?
Integración dbt	Correcta (operador)	Primera clase (modelo=asset)	Correcta
Ecosistema/madurez	El más grande	Creciendo fuerte	Sólido
Administrado en nubes	MWAA, Composer	Dagster+ (vendor)	Prefect Cloud
Cuándo elegirlo	Equipo/infra ya lo usa; ecosistema manda	Pipeline nuevo centrado en datos/IA	Equipo Python que quiere lo mínimo

La lectura para IA — y la razón del subtítulo del módulo: los consumidores de este curso son datasets con SLA de frescura (el índice del RAG, el dataset de entrenamiento, las features). El modelo de assets habla ese idioma nativamente: “el corpus del RAG está desactualizado respecto de sus fuentes” es un estado del sistema, no una inferencia tuya sobre logs de tareas. No es que Airflow no pueda — es que Dagster hace natural lo que en Airflow es disciplina. Para pipeline nuevo centrado en IA, Dagster parte con ventaja; para organización con Airflow operando, la ventaja rara vez paga la migración.

Ojo — el orquestador no es el motor: dirige, no procesa. La transformación pesada corre en el almacén (módulo 5) o en el cómputo del cluster; el orquestador lanza y espera. El anti-patrón clásico: el DataFrame gigante procesándose dentro del worker de Airflow — el director cargando el piano. Si una “tarea” consume memoria seria, es un trabajo mal ubicado (la serie cloud dijo lo mismo de Workflows y Step Functions: coordinan, no procesan).

Dos hábitos operativos que separan pipelines adultos, cualquiera sea la herramienta: idempotencia por ventana (cada corrida procesa su partición de fechas parametrizada — por eso el backfill es “corre las ventanas de enero” y no un script especial) y alertar por SLA de frescura, no solo por fallo (el pipeline que “no falló” pero lleva 30 horas sin correr es un incidente que el chequeo de fallos no ve — el asset desactualizado, sí).

Errores comunes

• Cron + esperanza. Pasos encadenados por horario estimado (“dbt a las 3, la ingesta ya habrá terminado”) es la carrera de relevos sin testigo: el día que la ingesta tarde, todo lo demás procesa datos viejos sin avisar. Dependencias explícitas, siempre.
• Procesar en el orquestador. El worker como motor de cómputo: memoria reventada, corridas lentas, el director tocando todos los instrumentos. Lanzar y esperar; el trabajo pesado en el motor que corresponde.
• Reintentos sin política. Ni cero (todo fallo transitorio es incidente) ni infinitos (el mensaje venenoso de la serie cloud, versión batch). Tope, espera creciente, y alerta al agotarse.
• Backfill artesanal. El “script especial para cargar lo histórico” distinto del pipeline normal es dos códigos que divergen. Corridas parametrizadas por ventana: el backfill es el pipeline normal, apuntado al pasado.
• Alertar todo o nada. Cincuenta correos por corrida entrenan a ignorar; cero avisos convierten el dato viejo en descubrimiento del negocio. Alerta = fallo definitivo o SLA de frescura roto; lo demás, dashboard.
• Elegir orquestador por moda. La tabla se lee con el contexto: qué opera ya el equipo, qué tan central es dbt, cuánto pesa el modelo de assets para tus consumidores. La migración de orquestador es cirugía mayor; la decisión inicial, barata.

La frase para llevarse

“El orquestador convierte pasos en sistema: dependencias en vez de horarios con fe, reintentos con política, backfill de rutina y alertas por frescura. Y el giro que le habla a la IA: orquestar assets — el dataset que debe existir y estar fresco — porque esa es exactamente la pregunta que tus consumidores hacen.”

Qué viene

Módulo 7: calidad y contratos de datos. El pipeline corre solo; falta que corra bien: los tests de datos que frenan la basura antes de propagarse (Great Expectations y los tests de dbt), la diferencia entre validar sintaxis y vigilar distribuciones, y el contrato de datos — el acuerdo explícito con la fuente que convierte “cambiaron el campo sin avisar” de sorpresa mensual en incidente con responsable.

Material relacionado

• Módulo 5: ELT y dbt
• Módulo 7: calidad y contratos de datos
• MLOps — Módulo 5: pipelines de entrenamiento
• Curso de AWS — Módulo 11: operación autónoma
• Glosario de Data Engineering para IA