E140 - Airflow: Utilidad, elementos básicos y setup

Resumen

El episodio 140 de enCoders presenta Apache Airflow, una plataforma en Python para orquestar procesos batch (no streaming) mediante DAGs (grafos dirigidos acíclicos). Se explica por qué dividir un proyecto de datos en módulos con entradas y salidas encaja con este modelo. Se destacan sus ventajas: monitoreo por colores, reejecución de tareas fallidas, backfill, versionamiento, testing y extensibilidad con operadores. Se compara con cron, Kedro y Snakemake, y se discute que Airflow gana por popularidad en la industria. Se muestra la interfaz de Airflow 3.0, el setup manual (ambiente virtual, `AIRFLOW_HOME`, base de datos, servicios), el arranque automático con systemd y el uso de enlaces simbólicos para mantener los DAGs en los repositorios de cada proyecto. Conclusión: vale la pena para muchos procesos o procesos críticos, el setup inicial es engorroso, y el servidor de Airflow debe solo orquestar mientras otros servicios (Docker en ECS, Container Instances) ejecutan las tareas.

Capítulos

• 00:00
  IntroSe presenta el episodio 140 sobre Airflow, herramienta de orquestación de procesos batch. Se anuncia que se verá qué es, para qué sirve, la instalación manual y automática y los elementos básicos.
• 00:30
  Desglosando procesos en módulosUn proyecto se divide en "cajas negras" (preproceso, EDA, limpieza, separación train/test), cada una con datos de entrada y de salida. Los datos se entienden en sentido amplio: dataset, archivo o variable.
• 02:28
  Creando un flujo de datosLos scripts encadenados forman un flujo desde datos brutos hasta outputs finales (un modelo, una tabla de clientes con score, una tabla de stock por tienda). Esos outputs se integran luego a otros procesos.
• 03:27
  Introducción a los Grafos Dirigidos Acíclicos (DAGs)Un grafo es una colección de nodos conectados. Un workflow necesita dirección (para fijar el orden) y ausencia de ciclos (para que el flujo termine).
• 05:34
  Scope de este streamHoy se cubren setup, conceptos y código de configuración (Docker y otras opciones), no la ejecución del proyecto completo, que se rompió y queda para la siguiente sesión. Se comenta que Airflow está muy masificado en data science, ingeniería de datos y MLOps.
• 06:51
  Airflow en aplicaciones del mundo realEn la experiencia del presentador funciona de forma limpia y permite monitorear, recibir alertas y reejecutar desde donde falló. Un proyecto que debía correr a diario ahora se ejecuta solo, y si falla basta presionar un par de botones. También se discute si Airflow impide crear ciclos.
• 08:20
  Ventajas de usar AirflowSe define el procesamiento batch frente al stream (grupos de datos en periodos definidos) y se advierte que Airflow sería ineficiente para stream. La documentación destaca control de versiones, testing y extensibilidad con operadores para AWS, GCP y otros. La interfaz muestra tareas verdes (éxito) y rojas (falla), con dependencias que no se ejecutan tras un error.
• 16:07
  Comparando Airflow con otras herramientasCron sirve para casos simples, pero requiere el computador prendido y no da monitoreo ni reejecución. Se comparan Kedro y Snakemake, que se ajustan mejor al flujo input/output de ML pero son poco populares. Snakemake valida que existan los inputs. Airflow gana por moda e inversión, y se puede combinar con Snakemake ejecutando el pipeline como una sola tarea.
• 27:44
  Explorando la interfaz de Airflow y reiniciando setup de AirflowSe reinician procesos y base de datos (`migrate` al pasar a Airflow 3.0) y se levantan scheduler, API server, triggerer y DAG processor. En WSL el DAG processor queda en una terminal aparte. Se ven los DAGs propios y los de ejemplo.
• 31:58
  Ejecutando y monitoreando tareas en AirflowSe revisa el DAG "tutorial" (tres tareas: print date, sleep y otra) en vista de lista y de grafo, con pestañas de overview, runs, tasks, backfills, eventos, código y detalles. El código no se edita desde la interfaz y se ve la versión del DAG.
• 34:25
  Usando Backfill en AirflowEl backfill (novedad de Airflow 3.0) ejecuta un rango de fechas con tres opciones: solo las faltantes, faltantes y fallidas, o todas, hacia adelante o atrás. Las fechas están en UTC y se usa la fecha lógica, útil para generar un mes de ejecuciones diarias.
• 35:43
  Manejando fallos y re-ejecucionesSe puede disparar un trigger con fecha específica en opciones avanzadas. El scheduler se había caído en la instalación local y se discute que el setup se hace una vez en un servidor. Se conversa cuándo conviene Airflow frente a cron según la frecuencia y criticidad.
• 41:41
  Integrando Airflow con otras herramientasUna consulta sobre cómo integrar un flujo que prende una instancia de AWS lleva a la respuesta de que existen operadores para conectarse a AWS, que se verán después.
• 42:22
  MemesPausa de memes. Se explica que el servidor de Airflow debe ser pequeño y delegar la ejecución a contenedores Docker en servicios como ECS o Container Instances. Se menciona que el setup inicial es el punto más enredado.
• 45:21
  Usando Docker para configuración rápida de AirflowSe muestra Astronomer, que ofrece una utilidad para levantar Airflow rápido. El presentador instaló a mano para entender el funcionamiento interno. En empresa se necesita servidor y base de datos separada para los registros. Se comenta el modelo de negocio open source de Astronomer.
• 49:12
  Más memesSe enfatiza la importancia de documentar el código. Se habla de operadores custom (por ejemplo, para Container Instance de Oracle) y del servicio Amazon MWAA, caro y con una máquina que debe estar siempre encendida. Se sugiere una instancia EC2 con Airflow como alternativa.
• 54:41
  Operadores de AirflowSe explica el PythonOperator: se le da un task_id y una función (`python_callable`) con argumentos opcionales. Las tareas se encadenan con `>>`. Existen operadores de Bash y de servicios AWS, y se puede encapsular cualquier lógica en una función Python.
• 58:21
  Definiendo parámetros de un DAGUn DAG se define con `with DAG`, la función `DAG` o el decorador `@dag`. Los parámetros clave son `dag_id`, el intervalo de programación, descripción y argumentos por defecto. Un `dag_id` repetido sobrescribe a otro aunque el archivo sea distinto.
• 01:05:48
  Tips útiles para setear Airflow en un servidor (systemd y prendido automático)Se crea un ambiente virtual aislado para Airflow, distinto al de los proyectos, y se distingue `AIRFLOW_HOME` del venv. Con un archivo de servicio en `/etc/systemd/system` y `ExecStart` se inician API server, scheduler, triggerer y DAG processor al encender el equipo.
• 01:11:41
  Usando enlaces simbólicos para DAGs de mútiples proyectosPara mantener los DAGs en el repositorio de cada proyecto, se crean enlaces simbólicos (`ln`) desde la carpeta de DAGs de Airflow. Un script generado con un LLM los crea evitando bucles de enlaces. Se discuten permisos: la rama productiva solo debe cambiar por pull request revisada.
• 01:23:19
  Cierre: Reflexiones finales y preguntas y respuestasSe resumen el aprendizaje, el web server de Airflow 3.0 y el backfill. Los participantes comentan que el setup puede ser pesado para data scientists, que prefieren delegarlo a un perfil especializado. El stream termina con un pantallazo azul.

Palabras clave