Apache Airflow Explicado: Una Guía Para Principiantes

Introducción

Las empresas modernas basadas en datos dependen de tuberías de datos que buscan, transforman, enriquecen y trasladan información de un lugar a otro. Estas tuberías de datos pueden involucrar muchos pasos (extraer los datos en bruto, limpiarlos, entrenar modelos de aprendizaje automático, construir paneles de control, etc.). Además, deben ejecutarse en un orden muy específico. Las herramientas de orquestación de flujos de trabajo, como Apache Airflow, ayudan a garantizar que todos estos pasos se ejecuten en el momento adecuado y en el orden correcto. También facilitan la supervisión y gestión de las tuberías.

Airflow fue creado en Airbnb en 2014 y se ha convertido en una de las plataformas de orquestación de flujos de trabajo de código abierto más populares. Es utilizado por miles de organizaciones para automatizar y monitorear pipelines por lotes. En este artículo, explicamos Apache Airflow desde cero. Los temas que cubriremos incluyen:

• Qué es Airflow, qué hace y por qué los equipos de datos lo utilizan.
• Los conceptos y componentes fundamentales de Airflow, y cómo encajan entre sí.
• Cómo se definen las canalizaciones como Grafos Acíclicos Dirigidos (DAG) y una explicación paso a paso de un DAG simple en acción.
• Casos de uso comunes como ETL/ELT, MLOps y más.

Esperamos que esto sea una introducción práctica y basada en ejemplos a Apache Airflow para ingenieros, estudiantes y equipos que están comenzando con la orquestación de flujos de trabajo.

Puntos clave

• Apache Airflow es una plataforma de orquestación de flujos de trabajo basada en Python que gestiona, programa y supervisa complejas canalizaciones de datos utilizando DAGs (Grafos Acíclicos Dirigidos).
• Los DAGs definen tareas y sus dependencias, permitiendo que Airflow ejecute cada paso en el orden correcto con reintentos, registro y observabilidad integrados.
• La arquitectura de Airflow (Programador, Ejecutor, Trabajador, Base de datos de metadatos, Interfaz web) permite la ejecución escalable y distribuida y la monitorización en tiempo real de los pipelines.
• Airflow sobresale en flujos de trabajo por lotes como trabajos ETL/ELT, pipelines de entrenamiento de ML, verificaciones de calidad de datos y análisis programados — pero no es ideal para cargas de trabajo en tiempo real o de ultra alta frecuencia.
• Alternativas como Prefect, Dagster, Luigi, Argo Workflows y Mage AI pueden ser más adecuadas dependiendo de necesidades como flujos de trabajo impulsados por eventos, ejecución nativa en Kubernetes o interfaces modernas amigables para desarrolladores.

¿Qué es Apache Airflow?

Apache Airflow es un sistema de código abierto para crear, programar y supervisar flujos de trabajo. Un flujo de trabajo de Airflow es un DAG (un grafo acíclico dirigido), que es una serie de tareas con relaciones claramente definidas (dependencias) y sin ciclos (una tarea no puede repetirse corriente arriba). La filosofía central de Airflow es "configuración como código", por lo que en lugar de usar una interfaz gráfica con arrastrar y soltar, se crean scripts en Python para representar los flujos de trabajo. Este enfoque proporciona una flexibilidad significativa para los ingenieros: se puede conectar con casi cualquier tecnología mediante los operadores de Airflow y las bibliotecas de Python. También se pueden aplicar las mejores prácticas de ingeniería de software (control de versiones, pruebas, etc.) a la definición de los pipelines.

¿Por qué importa la orquestación de flujos de trabajo?

El punto clave es que a menudo tienes múltiples pasos en cualquier flujo de trabajo de datos que deben ejecutarse en secuencia. Un ejemplo simple es la canalización ETL (Extraer/Transformar/Cargar). Las canalizaciones pueden volverse rápidamente más complejas a medida que agregas más tareas, dependencias, ramificaciones, y así sucesivamente, y también necesitan ejecutarse de manera regular. La intervención manual o las herramientas de programación simples a menudo se vuelven insuficientes en estos casos. Airflow resuelve esto al actuar como un orquestador central. Tiene un grafo acíclico dirigido (DAG) de tareas (nodos) con dependencias (aristas). Sabe cuándo ejecutar cada tarea (esperando a que se completen las dependencias previas antes de ejecutarla), incluyendo programación (ejecución periódica), manejo de errores (reintentos automáticos, alertas) y registro de actividad.

Si consideramos que toda la canalización de datos es una receta, entonces cada tarea individual es un subpaso (cortar, hervir, emplatar, etc.). Airflow es como el jefe de cocina que conoce las recetas y supervisa todos los diferentes subpasos que ocurren en cada cocina, asegurándose de que todo suceda en el orden correcto y en el momento adecuado.

Sin la orquestación de flujos de trabajo, puedes tener todos los chefs e ingredientes, pero no están coordinados. Airflow proporciona esa coordinación, permitiendo la producción del "plato" deseado (ejecución del flujo de trabajo).

¿Por qué los equipos de datos usan Airflow?

Airflow se ha vuelto popular entre los ingenieros de datos, los ingenieros de ML y los equipos de DevOps porque satisface muchas necesidades de las complejas canalizaciones de datos. Aquí hay algunas razones importantes por las que los equipos eligen Airflow:

• Orquestando Flujos de Trabajo y Dependencias Complejas: Airflow fue diseñado para flujos de trabajo con un gran número de pasos interdependientes. Airflow facilita la declaración de los requisitos ascendentes y descendentes, asegurando que las tareas se ejecuten en el orden correcto. Si la tarea C depende de las tareas A y B, el programador de Airflow conoce estas relaciones y se asegurará de que A y B se ejecuten (posiblemente en paralelo) antes de ejecutar C. Airflow puede manejar dependencias complejas, lógica de ramificación, etc.
• Planificación Centralizada (Cron mejorado): Proporciona un planificador que te permite ejecutar tareas según un horario determinado. Podrías definir docenas o cientos de flujos de trabajo que activen tareas en diferentes momentos (cada hora, diariamente, mensualmente) utilizando el planificador de Airflow. Airflow entiende las relaciones entre tareas. Puede programar y activar tareas de manera inteligente para que se ejecuten. El planificador central te libera de tener que escribir diferentes scripts en distintos servidores.

• Escalabilidad y Ejecución Distribuida: Airflow también puede escalar con tus flujos de trabajo. Puede configurarse para ejecutar tareas en paralelo en múltiples procesos de trabajo o máquinas. También ofrece múltiples ejecutores (discutidos más adelante en este artículo) que pueden ejecutar tareas en sistemas distribuidos como Celery o Kubernetes a lo largo de un clúster de nodos. Esto significa que puedes paralelizar tareas pesadas (procesamiento de grandes cantidades de datos) y tener múltiples pipelines ejecutándose de manera concurrente.
• Monitoreo, Registro y Alertas: Viene con una rica interfaz web que proporciona visibilidad en tiempo real de tus flujos de trabajo. Puedes ver qué tareas han tenido éxito y cuáles han fallado, y consultar la salida de registro de cada tarea. Incluso puedes activar y/o reintentar tareas manualmente a través de la interfaz web.

Componentes Clave de Airflow

A continuación se ofrece una breve descripción de los elementos básicos de Apache Airflow. Utiliza esta tabla como referencia rápida para entender qué es cada componente y qué hace.

Cómo Funciona Airflow (Arquitectura)

Aquí tienes una descripción paso a paso de cómo Airflow procesa un flujo de trabajo (DAG):

• Creación del DAG: El autor del DAG escribe un script en Python que define un DAG. Este script incluye cosas como el cronograma (por ejemplo, “ejectuar diariamente a las 9 AM”) o configuraciones de activación manual. También contiene las definiciones de las tareas (a través de operadores o funciones @task), así como las dependencias entre tareas (por ejemplo, task1 >> task2 (task2 espera a que task1 termine)). El archivo Python se guarda en la carpeta de DAGs de Airflow para que pueda ser encontrado por Airflow. Airflow leerá (analizará) este archivo periódicamente para cargar la definición del DAG.
• Programación y Análisis de DAG: El Programador de Airflow es un proceso que se ejecuta continuamente en segundo plano. Verifica si cada DAG debe ejecutarse según su programación o activadores. Por ejemplo, un DAG con una programación de “diaria” puede ser detectado por el programador, y notar que debe programarse una nueva ejecución a medianoche. El Programador de Airflow también verifica si las tareas dentro de los DAG están listas para ejecutarse, lo que significa que todas sus dependencias ascendentes están completas y que ha llegado el momento programado (fecha lógica).
• Ejecutando Tareas: Cada tarea que se va a ejecutar es entregada al Ejecutor por el Programador. El ejecutor decide dónde y cómo ejecutar la tarea. Podría ejecutarse de manera local o enviarse a una cola de trabajadores. Para una arquitectura distribuida, la tarea se añadirá a una cola y luego será seleccionada por procesos de Trabajador que ejecuten las tareas.
• Actualización del estado y manejo de errores: Cada instancia de tarea informa su estado (éxito, fallo, etc.) de regreso al planificador a medida que se completa, y el planificador actualiza su base de datos de metadatos con el estado de la tarea.
  El seguimiento del estado es lo que permite al planificador saber qué hacer a continuación; por ejemplo, si la Tarea A se ha completado con éxito, sabe que ahora puede programar la Tarea B, o si la Tarea A ha fallado y aún tiene reintentos disponibles, programa un reintento, o si ha fallado sin reintentos restantes, marca la ejecución del DAG como fallida. Si una tarea falla, Airflow tiene lógica para reintentar automáticamente la tarea si está configurada para reintentos. Si sigue fallando después de los reintentos, Airflow puede alertar sobre los fallos (enviar un correo electrónico o un mensaje de Slack, etc.). Todo esto se puede configurar como parte de los parámetros del DAG o de la tarea (por ejemplo, número de reintentos, demora entre reintentos, correo electrónico para enviar alertas).
• Monitoreo e Intervención: La interfaz web de Airflow proporciona una visualización en tiempo real del proceso mencionado. Puedes ver aparecer una ejecución de DAG (por ejemplo, una nueva línea en la vista de árbol para una ejecución de hoy) y observar cómo cambian los estados de las tareas a medida que avanzan. La vista de gráfico visualiza las tareas del DAG y muestra cuáles se han completado o han tenido errores.
• Limpieza y próxima ejecución: Cuando se completa una ejecución de DAG (todas las tareas han tenido éxito o han sido omitidas/fallidas), Airflow pasa a la siguiente ejecución programada. Todos los metadatos sobre ejecuciones pasadas se mantienen en la base de datos, y siempre puedes consultar el historial. El planificador continuará activando nuevas ejecuciones según el horario programado o mediante activación manual. Este proceso se repite hasta que el proceso de Airflow sea finalizado.

Comprendiendo los DAGs en Airflow

Un DAG en Airflow define el horario, así como las tareas y dependencias necesarias para ejecutar un flujo de trabajo. Un DAG no necesita saber qué hay dentro de cada tarea; solo necesita definir cuándo y en qué orden deben ejecutarse.

Tareas, operadores y sensores

Las tareas son las unidades básicas de trabajo en Airflow. En Airflow, las tareas son instancias de operadores, que son plantillas para acciones predefinidas. Airflow viene con una variedad de operadores básicos. El BashOperator te permite ejecutar comandos de shell, y el PythonOperator te permite llamar a funciones de Python. Airflow también proporciona un decorador @task, que te permite convertir una función de Python normal en una tarea.

Además de los operadores, Airflow proporciona sensores. Los sensores son tareas que esperan a que se cumpla una condición o evento antes de completarse con éxito. Pueden usarse para cosas como esperar a que aparezca un archivo o que se llene una tabla.

Dependencias de tareas

Para declarar dependencias entre tareas, se utilizan los operadores >> y << (recomendado) o métodos como set_upstream y set_downstream. También es posible encadenar tareas, crear dependencias cruzadas hacia abajo e incluso construir dinámicamente listas de tareas. Un DAG sin ninguna dependencia sería simplemente un conjunto independiente de tareas.

Mejores prácticas para el diseño de DAG

La tabla a continuación presenta algunas pautas a tener en cuenta al diseñar DAGs.

Ejemplo: Un DAG sencillo de Airflow

Nada solidifica los conceptos mejor que un ejemplo. Vamos a recorrer un código sencillo de DAG en Airflow y explicar sus partes. Este ejemplo creará un pequeño flujo de trabajo con dos tareas en secuencia:

from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

# Define the DAG and its schedule
with DAG(
    dag_id="example_dag",
    description="A simple example DAG",
    start_date=datetime(2025, 1, 1),
    schedule_interval="@daily",  # runs daily
    catchup=False
) as dag:
    # Task 1: Print current date
    task1 = BashOperator(
        task_id="print_date",
        bash_command="date"
    )
    # Task 2: Echo a message
    task2 = BashOperator(
        task_id="echo_hello",
        bash_command="echo 'Hello, Airflow!'"
    )
    # Define dependency: task1 must run before task2
    task1 >> task2

Analicemos lo que está sucediendo aquí:

• importar las clases necesarias DAG (para definir el DAG) y BashOperator (para ejecutar comandos de shell/bash en las tareas). También importamos datetime para especificar la fecha de inicio del DAG.
• Creamos un objeto DAG con un administrador de contexto (with DAG(…) as dag:). Proporcione al DAG un ID único “example_dag” (debe ser único en un entorno de Airflow), una descripción (opcional, para ayudar a los humanos a leer), una start_date y un schedule_interval. Aquí, establecemos un schedule_interval predefinido (@daily), y start_date=datetime(2025,1,1). También hemos configurado catchup=False para evitar la ejecución retroactiva de cualquier corrida perdida entre la start_date y hoy (solo queremos que se ejecute a diario a partir de ahora). Este bloque completo crea un DAG del que Airflow se dará cuenta y que se ejecutará diariamente al comienzo del día.
• Luego definimos dos tareas en el contexto del DAG:
• task1 se define usando BashOperator para ejecutar un comando bash (date). task_id es “print_date” y se usará para identificar esta tarea en la interfaz de usuario y en los registros. Cuando se ejecute, esta tarea simplemente imprimirá la fecha/hora actual (en el registro de la tarea).
• task2 también utiliza un BashOperator con task_id=“echo_hello ”, y command=echo ‘¡Hola, Airflow!’. Esto imprimirá un mensaje agradable. Estas tareas por ahora solo están definidas, aún no están vinculadas.
• La última línea (task1 >> task2) especifica una dependencia (flujo): task1 fluye hacia task2. Esto significa que la tarea 1 se ejecutará y completará con éxito antes de que la tarea 2 pueda considerarse para su programación. Gráficamente, en el grafo DAG, habrá una flecha que apunta de task1 a task2.

Algunas cosas a tener en cuenta en este ejemplo:

• Solo usamos BashOperator por simplicidad, pero podríamos haber utilizado un DAG con tipos de operadores mezclados. Podríamos tener un PythonOperator para llamar a una función de Python, o un SimpleHttpOperator para hacer ping a una API, y así sucesivamente.
• El patrón with DAG(…) as dag: es un modismo común para crear una instancia de DAG. Todas las tareas que se crean dentro de él se asocian automáticamente con ese DAG.
• catchup=False es un parámetro que se usa en muchos DAGs con una start_date en el pasado, cuando no quieres que se ejecute para todas las fechas pasadas. Si dejáramos catchup=True (el valor por defecto) y hoy fuera 10 de enero de 2025, Airflow intentaría ejecutar el DAG para el 1, 2, 3 de enero, … hasta el 10 de enero, poniéndose al día con esos días perdidos en un atraso. Lo desactivamos aquí para mayor simplicidad.
• Este ejemplo usa la ruta de importación relativa para BashOperator. En Airflow 2, muchos de los operadores se movieron bajo airflow.providers. Este ejemplo está escrito bajo la suposición de que esos proveedores están instalados (BashOperator está en el núcleo de Airflow).

Este ejemplo simple se puede ampliar fácilmente: podrías añadir tareas adicionales (tal vez hacer una llamada a una API, luego cargar los resultados en una base de datos y después enviar una notificación). También puedes añadir lógica más compleja (como bifurcaciones: Airflow admite bifurcaciones estilo if/else usando, por ejemplo, el BranchOperator).

A medida que tus DAGs se vuelven más grandes, la interfaz de Airflow y los registros se vuelven invaluables para entender lo que está sucediendo. En este ejemplo, el registro de print_date contendría la fecha del sistema que se imprimió, y el registro de echo_hello contendría "¡Hola, Airflow!". Si print_date fallara (tal vez no pudiera encontrar el comando date, en un escenario hipotético), entonces echo_hello nunca se ejecutaría (debido a la dependencia), y la ejecución del DAG se marcaría como fallida. Luego podrías inspeccionar el registro, solucionar el problema y volver a ejecutar esa tarea o todo el DAG.

Casos de Uso Comunes de Airflow

A continuación se presenta un resumen estructurado de los casos de uso comunes de Apache Airflow. La tabla destaca en qué consiste cada caso de uso y cómo Airflow aporta valor en ese contexto.

Cuándo NO usar Airflow

Aunque Airflow es potente, no es la herramienta adecuada para todas las situaciones. Comprender sus limitaciones te ayuda a elegir el enfoque de orquestación correcto:

• Cargas de Trabajo en Tiempo Real o en Streaming: Airflow está orientado a procesos por lotes con un inicio y fin bien definidos. No es adecuado para cargas de trabajo de larga duración, impulsadas por eventos o en streaming. Si estás ingiriendo flujos continuos de eventos (clics de usuarios, sensores IoT, etc.) y necesitas procesarlos con muy baja latencia en tiempo real, Airflow no es la mejor opción.
• Tareas de Alta Frecuencia o Muchas Tareas Cortas: Este es otro caso en el que Airflow puede no funcionar, o al menos no de manera eficiente. Las tareas de Airflow tienen cierta sobrecarga (en el seguimiento de la base de datos, etc.), por lo que si necesitas activar algo cada pocos segundos o tienes miles de tareas pequeñas, Airflow puede no escalar bien.
• Flujos de trabajo puramente basados en eventos: Esto es similar al caso de uso de streaming, pero para algo que debe ser activado por un evento. “Siempre que ocurra el evento X, haz Y” es un caso de uso perfectamente válido para Airflow, pero si lo único que debería activar eso es un evento (por ejemplo, “siempre que llegue un archivo a un bucket de S3, haz X”), entonces Airflow no es la solución más ligera aquí. Airflow generalmente usa sensores (como S3KeySensor, por ejemplo) para “detectar” la presencia de archivos/eventos. Los sensores tienen desventajas ya que dependen del sondeo. Los problemas con los sensores incluyen activarse con archivos existentes y no necesariamente responder a los eventos de manera inmediata (por ejemplo, hacen sondeos a intervalos).

En resumen, Airflow es adecuado para flujos de trabajo que son periódicos, por lotes o complejos de definir y gestionar. Podría no ser una buena opción si tu caso de uso requiere procesamiento en tiempo real o continuo, trabajos extremadamente frecuentes, o flujos de trabajo muy simples que no necesitan la sobrecarga de Airflow. Si es así, podrías considerar explorar otras opciones o simplificar tu solución.

Alternativas a Airflow

El espacio de orquestación de flujos de trabajo ha explotado en los últimos años, y aunque Airflow es un líder, hay varias herramientas alternativas que vale la pena conocer:

Airflow no es la única opción disponible, y la mejor elección depende de tu caso de uso. Luigi, Prefect y Dagster se mencionan comúnmente como las principales otras opciones de código abierto en el mismo ámbito (orquestadores de flujo de trabajo basados en Python). Si encuentras que la interfaz anticuada de Airflow u otras limitaciones son engorrosas, deberías considerar evaluar estas alternativas. Prefect intenta ser un Airflow "mejor" o "más simple", Dagster busca ser un orquestador más "estructurado" con énfasis en los activos de datos, y Luigi es un predecesor más sencillo de Airflow. Por otro lado, si tu caso de uso se desvía significativamente (transmisión en tiempo real o completamente en la nube, por ejemplo), podrías no usar Airflow en absoluto y podrías considerar directamente plataformas de streaming o servicios de orquestación gestionados.

Reflexiones finales

Apache Airflow es una plataforma de código abierto para orquestar flujos de trabajo computacionales complejos y pipelines de procesamiento de datos. Originalmente desarrollado en Airbnb, ha ganado una gran popularidad en las comunidades de ingeniería de datos y aprendizaje automático. Los componentes de Airflow incluyen un programador, un ejecutor, trabajadores, una base de datos de metadatos y una interfaz web. Esto permite a los equipos ejecutar y mantener fácilmente pipelines listos para producción en ETL, MLOps e infraestructura. La abstracción DAG (Grafo Acíclico Dirigido) de Airflow permite mantener los flujos de trabajo explícitos, comprobables y mantenibles a lo largo del tiempo. El ecosistema de operadores y proveedores creados por la comunidad de la plataforma también simplifica la orquestación de flujos de trabajo que dependen de cualquier tecnología o herramienta.

Sin embargo, no es una solución única para todos. Funciona mejor con pipelines por lotes o micro-lotes, y los usuarios deben sentirse cómodos con Python. Para flujos de trabajo en tiempo real o de alta frecuencia, existen otras soluciones más adecuadas que Airflow. Para científicos de datos o equipos que prefieren escribir pipelines declarativos, podría ser interesante considerar herramientas alternativas a Airflow.

Airflow sigue siendo desarrollado activamente, y se añaden nuevas funcionalidades con el tiempo, como la programación basada en eventos, conjuntos de datos y activos. Los conceptos y las mejores prácticas presentados en esta guía deberían ayudarte, sin importar tu experiencia, a entender cómo funciona la orquestación de flujos de trabajo y cuándo se debería (o no) usar Airflow. Esperamos que esto sirva como un punto de partida para explorar más a fondo este rico universo.

Referencias

• Apache Airflow
• ¿Qué es Airflow?
• Apache Airflow: Casos de uso, arquitectura y 6 consejos para el éxito
• Introducción para principiantes a Airflow con Docker — Canalizaciones de datos en la nube (I)
• 8 alternativas a Airflow - Casos de uso
• Resumen de Arquitectura
• Programador

Gracias por aprender con la comunidad de Linux-Console.net.