Lección 7 de 20 · Lectura y práctica
Implementar Branching y Condicionales en DAGs
Tipo de lección: VideoConcepto claveEn Apache Airflow, el branching y los condicionales permiten crear flujos de trabajo dinámicos donde las tareas no siempre se ejecutan en secuencia lineal. Imagina que estás construyendo una.
Del concepto a la práctica
Taller de esta lección
El branching selecciona tareas según un dato de ejecución, pero una rama omitida no equivale a una rama fallida. La función de decisión debe devolver identificadores existentes y contemplar todos los valores de entrada. Después, una tarea de convergencia necesita una regla compatible con las ramas que no fueron seleccionadas.
Ejemplo resuelto
Un archivo trae formato=csv. La decisión devuelve procesar_csv; procesar_json queda omitida. Ambas ramas conducen a registrar_fin. Si la convergencia usa la regla predeterminada de éxito de todas las predecesoras, puede quedar omitida por la rama no elegida; una regla adecuada debe aceptar la rama seleccionada sin ocultar fallos reales.
Pruébalo
Prepara entradas con
csv,jsonydesconocido.Devuelve una tarea válida para cada formato admitido.
Define una ruta explícita de rechazo para el valor desconocido.
Observa estados de seleccionada, omitida y ejecutada.
Comprueba tu resultado
Error frecuente: devolver el nombre de una función en vez del task_id. Corrige usando cadenas que coincidan exactamente con las tareas. El resultado esperado es una sola rama de procesamiento por entrada, una ruta visible para desconocido y una convergencia que no se ejecute si la validación falla.
Selección, rechazo y unión
Para el ejemplo de formatos usa @task.branch desde airflow.sdk y devuelve procesar_csv, procesar_json o rechazar_formato, que deben ser hijas directas. Una unión con TriggerRule.NONE_FAILED_MIN_ONE_SUCCESS, importado del SDK, admite éxito más omisión y bloquea los fallos. Si rechazar_formato simplemente escribe un registro y termina bien, el DAG puede terminar bien con estado de negocio rechazado. Para exigir un fallo global por formato inválido, configura esa tarea con retries=0 y haz que lance un error después de conservar evidencia.
Las fixtures son {"formato":"csv"}, {"formato":"json"} y {"formato":"desconocido"} en tres ejecuciones independientes. La ruta seleccionada queda success o failed según la política; las otras quedan skipped. No uses una regla que oculte fallos para obtener una pantalla verde. Branching y trigger rules.

Mapa de prácticaUn DAG expresa dependencias entre tareas, sin ciclos. Una transformación puede esperar a varias entradas y la publicación debe esperar a que la carga esté lista. El orden depende de los datos necesarios, no solo de una hora del reloj.
Ver la infografía en tamaño completo ↗Tipo de lección: Video
Concepto clave
En Apache Airflow, el branching y los condicionales permiten crear flujos de trabajo dinámicos donde las tareas no siempre se ejecutan en secuencia lineal. Imagina que estás construyendo una autopista con múltiples salidas: dependiendo del tráfico (condición), algunos carriles se dirigen a una ciudad, otros a otra, pero todos convergen eventualmente. En Airflow, esto significa que tu DAG puede tomar decisiones en tiempo de ejecución sobre qué rama de tareas ejecutar, basándose en datos, resultados previos o parámetros externos.
Esto es crucial para pipelines ETL complejos porque los datos rara vez son uniformes. Por ejemplo, al procesar datos de ventas, podrías necesitar rutas diferentes para transacciones normales versus devoluciones, o para datos de diferentes regiones. Los condicionales te permiten modelar esta lógica directamente en el DAG, haciendo que tu orquestación sea más inteligente y adaptable.
El branching no es solo sobre elegir una rama; es sobre crear pipelines que se adapten a la realidad de tus datos.
Cómo funciona en la práctica
Airflow implementa branching principalmente a través del operador BranchPythonOperator, que evalúa una función Python para decidir qué tarea(s) ejecutar a continuación. La función debe devolver el task_id de la siguiente tarea o una lista de task_ids. Aquí un ejemplo paso a paso:
- Define una función Python que tome el contexto de Airflow (por ejemplo, usando
**kwargs) y devuelva un task_id basado en una condición. - Crea un
BranchPythonOperatorque use esa función. - Configura las dependencias: el branching operator debe estar aguas arriba de las tareas que representan las ramas posibles.
- Las tareas no seleccionadas se marcan como
skippedautomáticamente.
Ejemplo básico con datos:
from airflow.operators.python import BranchPythonOperator
def decide_ruta(**kwargs):
ti = kwargs['ti']
# Supongamos que una tarea anterior pusó un valor en XCom
valor = ti.xcom_pull(task_ids='tarea_anterior', key='clave')
if valor > 100:
return 'procesar_grande'
else:
return 'procesar_pequeno'
branch_task = BranchPythonOperator(
task_id='decidir_ruta',
python_callable=decide_ruta,
dag=dag
)Caso de estudio
Imagina un pipeline ETL para procesar datos de sensores IoT en una fábrica. Los sensores envían lecturas de temperatura cada minuto. Tu objetivo es: si la temperatura supera un umbral crítico (ej., 80°C), activar una alerta inmediata y registrar en una base de datos de incidentes; si está en rango normal, simplemente agregar los datos para reportes diarios.
Estructura del DAG:
extraer_datos: Lee los datos del sensor desde un API.branch_temperatura: UsaBranchPythonOperatorpara evaluar si la temperatura > 80°C.- Rama A:
activar_alertayregistrar_incidente(si temperatura alta). - Rama B:
agregar_datos(si temperatura normal). generar_reporte: Tarea común que se ejecuta después de cualquiera de las ramas, usandotrigger_rule='none_failed'para asegurar ejecución.
Tabla de umbrales de ejemplo:
| Temperatura (°C) | Acción | Tarea Asignada |
|---|---|---|
| > 80 | Alerta crítica | activar_alerta |
| 50-80 | Advertencia | registrar_incidente |
| < 50 | Normal | agregar_datos |
Este caso muestra cómo el branching maneja escenarios del mundo real donde los datos dictan el flujo de trabajo.
Errores comunes
- Olvidar configurar trigger_rule en tareas aguas abajo: Si una rama se salta, las tareas comunes podrían no ejecutarse. Usa
trigger_rule='none_failed'o'dummy'para asegurar continuidad. - Devolver múltiples task_ids sin entender las consecuencias: El
BranchPythonOperatorpuede devolver una lista, pero esto ejecuta todas esas tareas en paralelo, no como ramas exclusivas. Asegúrate de que tu lógica coincida con la intención. - No manejar casos edge en la función de branching: Siempre incluye un caso por defecto o validación para evitar errores en tiempo de ejecución.
- Confundir branching con condicionales en tareas individuales: El branching decide entre tareas; para lógica dentro de una tarea, usa condicionales Python normales en el operador.
- Ignorar el estado skipped: Las tareas no seleccionadas se marcan como skipped, lo que puede afectar monitoreo. Planifica cómo manejar estos en tus dashboards.
Checklist de dominio
- Puedo explicar la diferencia entre
BranchPythonOperatory un operador condicional dentro de una tarea. - He implementado un DAG con al menos dos ramas basadas en datos dinámicos (ej., desde XCom).
- Sé cómo configurar
trigger_rulepara tareas que dependen de ramas skipped. - Puedo debuggear un DAG donde el branching no selecciona la rama esperada.
- He usado branching para manejar al menos un escenario real como errores de datos o umbrales.
- Entiendo cómo las tareas skipped afectan el flujo general y el reporting.
- Puedo documentar la lógica de branching para que otros ingenieros la entiendan.
Construye un DAG con Branching para Procesamiento de Pedidos E-commerce
En este ejercicio, crearás un DAG en Apache Airflow que simule un pipeline ETL para procesar pedidos en una plataforma de e-commerce. El DAG debe usar branching para manejar diferentes tipos de pedidos basados en su valor total.
- Configura el entorno: Asegúrate de tener Airflow instalado y funcionando. Crea un nuevo archivo Python para tu DAG en la carpeta
dags/. - Define las tareas: Crea las siguientes tareas usando operadores de Python:
extraer_pedidos: Simula extraer datos de pedidos (puedes usar una lista de diccionarios conorder_id,total_amount).branch_pedido: UsaBranchPythonOperatorpara decidir la ruta basada entotal_amount: si > 500, ir aprocesar_grande; si <= 500, ir aprocesar_pequeno.procesar_grande: Simula procesamiento especial para pedidos grandes (ej., log a consola).procesar_pequeno: Simula procesamiento estándar para pedidos pequeños.notificar_fin: Tarea común que se ejecute después de cualquier rama, notificando finalización.
- Implementa la lógica de branching: En la función para
branch_pedido, usa XCom para obtenertotal_amountdesdeextraer_pedidosy devuelve el task_id correspondiente. - Configura dependencias y trigger rules: Establece las dependencias entre tareas y asegúrate de que
notificar_finusetrigger_rule='none_failed'. - Prueba el DAG: Ejecuta el DAG en Airflow y verifica que las ramas se seleccionen correctamente basadas en los datos. Prueba con al menos dos pedidos: uno con total 600 y otro con total 300.
- Documenta: Agrega comentarios en el código explicando tu lógica de branching.
Pistas
- Usa
ti.xcom_pullen la función de branching para acceder a datos de tareas anteriores. - Recuerda que
BranchPythonOperatordevuelve un string con el task_id, no el objeto de la tarea. - Si
notificar_finno se ejecuta, revisa la configuración detrigger_rule.
Evalua tu comprension
Completa el quiz interactivo de arriba para ganar XP.
Sigue con Apache Airflow para ETL: Integraciones y Pipelines en Tiempo Real
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.