Apache Airflow 3.4.0 añade bucles de tareas, DAGs escritos en TypeScript, Java y Go, y un proveedor de IA con límite de gasto por ejecución

Orquestacion de tuberias de datos con Apache Airflow

El proyecto Apache Airflow publicó el 6 de noviembre la versión 3.4.0 del orquestador. La entrega trae tres novedades de peso: bucles nativos de tareas, la posibilidad de escribir grafos completos en lenguajes distintos de Python y la disponibilidad general del proveedor común de inteligencia artificial.

Los bucles de tareas llegan con la propuesta de mejora AIP-111 y resuelven un patrón que hasta ahora obligaba a trucos: repetir un grupo de tareas en tiempo de ejecución hasta que se cumpla una condición. El diseño es deliberadamente conservador. Exige declarar un número máximo de iteraciones, admite un predicado opcional de convergencia, expone un objeto de contexto con el índice, los resultados anteriores y los metadatos de la iteración, y materializa las iteraciones de forma diferida para no crear las que no van a ejecutarse. Se combina además con los mecanismos ya conocidos de parámetros parciales, sobrescritura y expansión dinámica.

El segundo cambio, bajo la propuesta AIP-85, amplía la autoría de grafos a TypeScript, Java y Go, y no solo para tareas sueltas: el grafo entero, con su planificación y sus dependencias, puede escribirse en esos lenguajes, cuyos tres kits de desarrollo quedan en disponibilidad general con herramientas de construcción propias. El marco es conectable y admite también definiciones en YAML, con marcadores explícitos de plantilla para que quede claro qué se evalúa y cuándo.

La tercera pieza es la que más cambia el día a día de quien ya orquesta cargas con modelos. El proveedor común de inteligencia artificial pasa a general e incorpora un decorador y un operador para invocar modelos de lenguaje, un operador de agente con acceso a herramientas —consultas SQL, conexiones del propio Airflow, servidores de protocolo de contexto de modelo y entornos aislados—, límites de coste y de uso que acotan tokens, peticiones o gasto por ejecución, y un estado nativo de espera de entrada humana que permite aprobar un paso sin mantener ocupado un hueco de trabajador.

De las tres, la que merece más atención es la menos llamativa. Que el límite de gasto y la aprobación humana sean, respectivamente, un parámetro y un estado del planificador convierte dos problemas que hoy se resuelven con código propio y disciplina en algo declarado en el grafo y visible en la interfaz. Para un equipo que esté metiendo llamadas a modelos dentro de tuberías de producción, eso es control operativo real, no una comodidad.

Los grafos en otros lenguajes tienen la contrapartida previsible: abren la orquestación a equipos que no son de Python, a cambio de fragmentar el repositorio en varias cadenas de construcción. Como toda entrega de funcionalidad, lo sensato es probarla en un entorno de ensayo, revisar las notas de la versión antes de actualizar y adoptar los bucles con su cota máxima bien ajustada, que es justo la salvaguarda que el proyecto ha hecho obligatoria.

Más en Dataprix: guía de arquitectura de datos de Dataprix

Fuente: Apache Airflow (anuncio oficial)

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.

Cada semana, estas noticias y lo mejor de Dataprix en tu correo

Suscribirme al boletín