En abril de 2025 se lanzó Apache Airflow 3.0 — el primer gran lanzamiento en cuatro años. Es la actualización más importante en la historia del proyecto y afecta prácticamente todos los aspectos del trabajo con la plataforma: desde la interfaz de usuario hasta la arquitectura interna.
Desde la salida de Airflow 2.0, el número de usuarios creció de 25.000 a 80.000 organizaciones, y las cargas mensuales aumentaron hasta 30 millones. Airflow hace tiempo dejó de ser solo una herramienta ETL: hoy el 30% de los usuarios lo utiliza para MLOps y el 10% para procesos de IA generativa. Precisamente estos nuevos casos de uso fueron el motor de los cambios radicales en la tercera versión.
¿Qué tiene de especial la tercera versión?
En pocas palabras: todo. Airflow 3.0 introduce una arquitectura orientada a servicios, una interfaz estable para crear DAGs, soporte ampliado para procesos orientados a eventos y tareas de ML, además de una UI completamente modernizada basada en React. Pero vayamos por partes: detrás de cada línea del resumen de cambios hay meses de trabajo de más de 300 desarrolladores.
La filosofía principal del lanzamiento es convertir Airflow de "solo un programador de tareas" en una plataforma completa para datos y IA modernos. No más parches para canalizaciones de aprendizaje automático, no más malabares para arquitecturas basadas en eventos. Ahora todo eso funciona de serie.
Versionado de DAGs: ¡por fin!
Comencemos con la novedad más esperada: el versionado de DAGs, que resultó ser la funcionalidad más solicitada según la encuesta anual de usuarios de Airflow. Si alguna vez trató de entender por qué su DAG falló tras un despliegue, o buscó los registros de una tarea que se eliminó del flujo una semana antes, ese problema por fin tiene solución.
¿Cómo funciona? Bastante simple. Un DAG se ejecutará hasta completarse con la versión que estaba activa en el momento del inicio, incluso si durante la ejecución se cargó una nueva versión. No más sorpresas desagradables cuando un cambio en el código afecta a procesos ya iniciados.
Pero lo más apreciable es la interfaz. Ahora la UI incluye un menú desplegable para ver versiones anteriores del DAG. ¿Quiere ver cómo estaba su canalización hace un mes? Aquí está. ¿Necesita saber qué versión del código generó un dataset concreto? Ahí la tiene, con todas las tareas, los registros y los metadatos.
Esto es especialmente útil para equipos encargados de cumplimiento y auditoría. Antes había que llevar documentación separada de cambios; ahora todo se hace automáticamente. La integración con Git incluso permite reiniciar versiones antiguas de DAGs, una función que seguramente agradecerán quienes realizan recálculos históricos de datos.
Nueva interfaz: React llega a Airflow
Si ha trabajado con Airflow en producción, sabe que la interfaz anterior dejaba mucho que desear, sobre todo cuando se tienen cientos de DAGs y las páginas cargan como en los primeros años de la web. Buenas noticias: Airflow 3.0 trae una UI totalmente rediseñada sobre React y FastAPI.
¿Qué significa esto en la práctica? Primero, velocidad. Las páginas cargan más rápido, los elementos de la interfaz son más intuitivos y la navegación se siente coherente y reactiva en todas las vistas. Esto se nota especialmente en entornos con cientos o miles de DAGs.
Entre las mejoras concretas destacan:
- Vista de cuadrícula — navegación mejorada en la línea temporal, búsqueda y filtrado. Ahora es mucho más fácil escanear el estado de ejecución de los DAGs y encontrar tareas problemáticas
- Vista de grafo — mejor escalado, paneo y exploración interactiva de metadatos de tareas. Las estructuras complejas de los DAGs se entienden de un vistazo
- Panel de recursos — nueva vista diseñada para procesos gestionados por recursos. Permite visualizar recursos, sus productores y consumidores
Por supuesto, como cualquier cambio importante de UI, requerirá cierto ajuste por parte de los usuarios veteranos de Airflow. Pero, sinceramente, la nueva interfaz se parece a lo que debería haber sido un orquestador de flujos de trabajo moderno en 2025.
Arquitectura orientada a servicios: las tareas pueden ejecutarse en cualquier parte
Quizá el cambio más fundamental de Airflow 3.0 es la nueva API de ejecución de tareas y el api-server de airflow, que permiten ejecutar tareas en entornos remotos con mejor aislamiento y flexibilidad. ¿Suena técnico? Sí. ¿Revolucionario? También.
Antes, todas las tareas de Airflow debían ejecutarse en el mismo entorno donde corría el programador. Ahora, la Task Execution Interface representa uno de los desplazamientos arquitectónicos más significativos en la historia de Airflow, permitiendo lanzar tareas prácticamente en cualquier lugar: en otras nubes, en dispositivos edge o en contenedores aislados.
¿Qué aporta esto? Imagine que tiene un modelo de ML que debe entrenarse en un clúster con GPU en una nube, los datos residen en otra nube y los resultados deben enviarse a un sistema local. Antes eso era problemático. Ahora es una situación habitual.
Especialmente interesante es el Edge Executor — el nuevo ejecutor que soporta cómputo distribuido, procesos orientados a eventos y computación en el borde. Esto abre posibilidades totalmente nuevas para IoT, procesamiento en tiempo real y arquitecturas híbridas nube-local.
Assets en lugar de Datasets: la reactividad se simplifica
Si intentó implementar una arquitectura orientada a eventos en Airflow 2.x, sabe que era posible pero requería mucha inventiva. En la tercera versión, la idea de Datasets se renombró como Assets con una reestructuración del modelo interno para mejorar el soporte de funciones futuras.
Assets en Airflow 3.0 no son solo un cambio de nombre. Es un sistema completo para construir canalizaciones reactivas. Los Assets admiten nombres, URIs, identificadores grupales y campos arbitrarios de metadatos, lo que permite crear una genealogía rica y un sistema de descubrimiento.
Pero lo más interesante son los observadores. Los Assets se pueden configurar con observadores que supervisan señales externas (actualmente AWS SQS) y disparan la ejecución de un DAG en respuesta. Esto transforma la planificación de DAGs de "ejecutar cada hora" a "ejecutar cuando los datos relevantes estén listos".
Imagine: un archivo llega a S3 → SQS recibe la notificación → el observador reacciona → el DAG se ejecuta automáticamente. No más cron ni sondeos. Simplemente una arquitectura reactiva.
Backfill: ahora se hace bien
Si alguna vez intentó hacer backfill en Airflow 2.x, recordará el dolor: comandos en la terminal que podían interrumpirse al perder la sesión, falta de visibilidad en la UI, imposibilidad de detener el proceso a mitad de camino. En Airflow 3, los backfills se han convertido en ciudadanos de pleno derecho, gestionados por el programador y ejecutables desde la UI o la API.
Ahora el backfill ya no es un comando separado, sino una parte integral del sistema. Los backfills son procesados por el programador principal, garantizando coherencia con las ejecuciones habituales de DAGs. Puede supervisarlos directamente en la UI, pausarlos e incluso cancelar tareas en medio del proceso.
Esto es especialmente importante para escenarios de ML, donde los backfills pueden durar horas o días. Ahora puede lanzar un backfill antes de un fin de semana y tener la tranquilidad de que no fallará por el cierre accidental de una terminal.
Soporte para varios lenguajes: no solo Python
Una de las novedades más ambiciosas es el soporte para tareas en distintos lenguajes de programación. Airflow 3 incluye Python TaskSDK, que mantiene compatibilidad hacia atrás para los DAGs existentes. Los SDKs de tareas para lenguajes adicionales, empezando por Golang, se publicarán en los próximos meses.
Importante aclaración: los DAGs siguen escribiéndose en Python. Pero ahora las tareas dentro de esos DAGs pueden estar escritas en Java, JavaScript, TypeScript, Go y otros lenguajes. Esto abre enormes posibilidades para integrar sistemas existentes y usar bibliotecas especializadas.
Imagine: puede escribir procesamiento de datos en Go para máxima velocidad, desplegar un modelo de ML en Python con TensorFlow e integrar sistemas heredados en Java. Todo dentro de un mismo DAG de Airflow.
Qué se eliminó en Airflow 3.0
Todo gran lanzamiento implica no solo añadir sino también retirar elementos obsoletos. SLA, SubDAGs, el pickling de DAG y XCom, así como varias variables contextuales internas, fueron eliminados. Si usa estas características, el equipo de Airflow proporcionó herramientas de migración para detectar usos obsoletos.
También cambió la estructura de la línea de comandos. airflow ahora se usa para comandos locales, mientras que airflowctl gestiona operaciones remotas, lo que mejora la separación entre desarrollo y despliegue.
No se asuste: el equipo de desarrollo preparó una guía detallada de migración y herramientas para verificar automáticamente la compatibilidad de sus DAGs.
¿Debería migrar ahora mismo?
La respuesta corta: depende de sus necesidades. Si tiene un sistema estable en Airflow 2.x y no necesita urgentemente las nuevas funciones, puede esperar. Airflow 2.x seguirá recibiendo soporte durante mucho tiempo.
Pero si usted:
- Sufre por la falta de versionado de DAGs
- Desea construir arquitecturas orientadas a eventos
- Planea despliegues multi-cloud o en edge
- Usa activamente flujos de trabajo de ML/IA
- Está cansado de una UI lenta
Entonces Airflow 3.0 merece una evaluación cuidadosa desde ahora.
Cómo empezar con Airflow 3.0
La forma más sencilla de familiarizarse con la nueva versión es usar Docker. La configuración oficial de Docker para Airflow ya se actualizó a 3.0; basta ejecutar el comando correspondiente para obtener el último archivo yaml para Composer.
Para producción se recomienda:
- Probar primero la migración en un entorno de staging
- Usar las herramientas oficiales de migración
- Actualizar Python a la versión 3.9-3.12 (si aún no lo ha hecho)
- Verificar la compatibilidad de sus operadores y sensores personalizados
Si utiliza servicios gestionados como AWS MWAA o Google Cloud Composer, espere a su soporte oficial para Airflow 3.0.
Mirando al futuro
Apache Airflow 3.0 no es solo otra actualización. Es la base para la próxima generación de orquestación de datos. La arquitectura orientada a servicios, el soporte para múltiples lenguajes y las capacidades orientadas a eventos preparan a Airflow para un mundo en el que los datos y la IA son aún más centrales para el negocio.
Es especialmente relevante que el equipo de desarrollo no solo añadió nuevas funciones, sino que reimaginó la arquitectura para atender las necesidades modernas. Computación en el borde, despliegues multi-cloud y analítica en tiempo real ya no son parches sobre Airflow; son capacidades nativas.
Claro, cualquier actualización importante trae sus retos. Hará falta tiempo para aprender las nuevas funciones, migrar DAGs existentes y adaptarse a la nueva interfaz. Pero, por los comentarios de los primeros usuarios, parece que vale la pena el esfuerzo.
Apache Airflow 3.0 no es solo una nueva versión del orquestador favorito: es un manifiesto de cómo debería ser la ingeniería de datos en la era de la IA. Y, al parecer, el futuro ya está aquí.
