Orquestación con DAGs
Nodos y aristas
Cada tarea es un nodo; cada arista una dependencia que obliga a esperar. Acíclico significa que no hay bucles: el flujo avanza sin volver atrás, lo que garantiza que el grafo siempre se pueda ejecutar.
Programación
Los DAGs declaran su cadencia: horario tipo cron o ejecución tras la llegada de un archivo. La planificación separa cuándo debería correr de si de verdad puede, respetando dependencias y concurrencia.
Reintentos y alertas
Una tarea transientemente fallida se reintenta con política y espera configurables; una que agota reintentos alerta. Distinguir el error recuperable del de diseño es parte del oficio de orquestar.
Idempotencia requerida
- Reintentar obliga a que cada tarea pueda repetirse sin duplicar efectos.
- Marcar el progreso por lotes o particiones hace el reintento seguro.
- Sin idempotencia, un reintento a media carga corrompe el destino.
Dependencias entre DAGs
Cuando un flujo consume la salida de otro, se enlazan con sensores o detecciones de éxito. Bien hecho, evita leer datos incompletos; mal hecho, crea carreras entre flujos que se pisan.
Retprocesar el pasado
La orquestación permite volver sobre ejecuciones anteriores para corregir un dato, con cuidado de rehacer solo lo afectado y en orden. Reprocesar sin control puede duplicar trabajo y romper garantías.
Observabilidad
Un panel con el estado de cada nodo, duraciones y historial convierte un pipeline opaco en algo diagnosticable. Sin métricas de latencia y fallo, corregir es adivinar.
Errores frecuentes
- Diseñar tareas que no son idempotentes y corromper el destino al reintentar a media carga.
- Encadenar DAGs leyendo la salida del otro sin un sensor, y acabar consumiendo datos incompletos.
- Lanzar un backfill sin control y duplicar trabajo o romper garantías del histórico.
Ejemplo resuelto: rescatar un nodo que falla cada madrugada
Un nodo de ingesta agota sus reintentos cada noche porque el origen aún no tiene los datos. La corrección:
- Diagnosticar con el panel si el fallo es transitorio o de diseño, mirando duraciones e historial.
- Añadir un sensor previo que espere a que el origen esté disponible antes de lanzar la tarea.
- Garantizar que la escritura sea idempotente para que el reintento no duplique filas.
- Configurar alertas solo al agotar reintentos, no en cada intento fallido.
- Medir latencia y tasa de fallo para decidir si conviene separar la ingesta en su propio DAG.
¿Para qué sirve en la realidad?
Todo equipo con pipelines nocturnos, desde marketing hasta logística, necesita que las tareas salgan en orden y se recuperen solas. La orquestación convierte scripts frágiles en flujos observables y repetibles.
Una tarea de un DAG falla por un pico puntual del origen y el orquestador la reintenta con éxito a los pocos minutos. Para que ese reintento no duplique filas, la tarea debe ser:
Un DAG puede contener un ciclo siempre que el orquestador sea lo bastante avanzado.
DAG
Ordena la resolución de un DAG en ejecución:
Planificar
Esperar
Ejecutar
Registrar
Apache Airflow
Documentación del orquestador de referencia para definir DAGs, horarios y dependencias.
Une cada elemento del DAG con su función.
El orden deja de ser tácito
# Orquestación con DAGs ## Grafo ### nodos y aristas ### sin ciclos ## Plan ### cron o sensor ### dependencias y concurrencia ## Robustez ### reintentos ### idempotencia ### backfill ## Observar ### panel de estado ### métricas de fallo
Conceptos de DAGs en Airflow
Documentación sobre cómo declarar tareas, dependencias y programación en Airflow.
Un nodo crítico falla cada madrugada por el origen y consumes todos los reintentos. ¿Aumentas reintentos, añades un sensor previo o separas la ingesta? Razona con idempotencia y observabilidad.