Apache Airflow ha publicado su versión 3.2.0, la actualización más relevante del orquestador open source desde el lanzamiento de la rama 3.x. Dos funcionalidades marcan esta release: asset partitioning, que transforma radicalmente cómo los pipelines reaccionan a cambios en los datos, y el soporte multi-equipo, que permite a las organizaciones consolidar múltiples equipos en una sola instancia de Airflow sin perder aislamiento.
Asset partitioning (AIP-76) resuelve uno de los problemas más frustrantes del scheduling basado en datos: hasta ahora, cuando un DAG upstream actualizaba un asset, todos los DAGs downstream se disparaban independientemente de qué partición había cambiado. Con Airflow 3.2, los DAGs downstream solo se activan cuando se actualiza la partición específica que les interesa. El nuevo CronPartitionTimetable permite programar DAGs contra particiones con expresiones cron, y los Partition Key Fields permiten inspeccionar exactamente qué partición disparó la ejecución. El caso de uso más inmediato: tres DAGs de ingesta que escriben en assets distintos cada hora activan un DAG downstream solo cuando los tres actualizan la misma partición horaria, eliminando ejecuciones innecesarias y reduciendo costes de cómputo significativamente. Multi-asset partitions permiten además que un único DAG escuche particiones de múltiples assets con resolución flexible mediante mappers temporales y de rango.
El soporte multi-equipo (AIP-67, experimental) permite que múltiples equipos aislados compartan una sola instancia de Airflow, con DAGs, conexiones, variables, pools y ejecutores propios por equipo —incluyendo la posibilidad de usar Celery, Kubernetes o AWS ECS por separado para cada uno. Esto reduce drásticamente el coste operativo para organizaciones que hoy mantienen varias instancias de Airflow. En el plano del rendimiento, la limpieza de campos renderizados es ahora 42 veces más rápida, y el scheduler ya no carga todas las TaskInstances en memoria, mejorando el comportamiento a escala.
Para los data engineers, Airflow 3.2 es una actualización que justifica la migración desde la rama 2.x si se trabaja con pipelines data-aware complejos o si la organización crece en número de equipos usando el mismo orquestador. Asset partitioning, en particular, cambia el paradigma de “cuándo ejecutar” hacia “cuándo y sobre qué dato ejecutar”, acercando Airflow a modelos de streaming reactivo sin abandonar la orquestación batch que lo define.
Más en Dataprix: Herramientas y arquitecturas de integración de datos
Fuente: Apache Airflow Blog