Seis verdades incómodas sobre Apache Airflow (y qué hacer al respecto)

Los equipos de datos que trabajan con procesos de ingesta complejos adoran Apache Airflow.

Puede definir sus flujos de trabajo en Python, el sistema tiene una amplia capacidad de extensión y ofrece una gran variedad de complementos. El ochenta y seis por ciento de sus usuarios dicen que están contentos y planean seguir usándolo en lugar de otros motores de flujo de trabajo. Un número igual dice que recomienda el producto.

Pero, como todo software, y especialmente el de código abierto, Airflow está plagado de una serie de lagunas y deficiencias que deberá compensar. Para los desarrolladores que acaban de familiarizarse con él, eso significa que el comienzo es lento y el avance es difícil. En este artículo, analizamos esos problemas y algunas posibles soluciones.

Airflow es un caballo de batalla con persianas. No hace nada para corregir el rumbo si las cosas van mal con los datos, solo con el pipeline. Prácticamente todos los usuarios han experimentado alguna versión de Airflow que les indica que se completó un trabajo y verifican los datos solo para descubrir que faltaba una columna y todo estaba mal, o que en realidad no pasaban datos a través de los sistemas.

Esto es especialmente cierto una vez que la organización de datos madura y se pasa de 10 gráficos acíclicos de datos (DAG) a miles. En esa situación, es probable que ahora esté utilizando esos DAG para Ingesta datos de fuentes de datos externas y API, lo que dificulta aún más el control de la calidad de los datos en Airflow. No puede "limpiar" el conjunto de datos de origen ni implementar sus políticas de gobernanza allí.

Si bien puede crear alertas de Slack para verificar cada ejecución manualmente, para incorporar Airflow como una pieza útil de su organización de ingeniería de datos y cumplir con sus SLA, desea automatizar los controles de calidad. Y para hacerlo, necesita visibilidad no solo de si un trabajo se ejecutó, sino también de si se ejecutó correctamente. Y si no funcionó correctamente, ¿por qué y dónde se originó el error? De lo contrario, estará viviendo el Día de la marmota.

No es un reto sencillo y, si somos sinceros, es la razón por la que se creó IBM® Databand. La mayoría de las herramientas de observabilidad del producto, como Datadog y New Relic, no fueron diseñadas para analizar pipelines y no pueden aislar dónde se originaron los problemas, agrupar problemas concurrentes para sugerir una causa principal o para sugerir arreglos.

Sin embargo, la necesidad de observabilidad aún no se comprende completamente, incluso dentro de la comunidad de Airflow. Hoy en día, solo el 32 % dice haber implementado la medición de la calidad de los datos, aunque el hecho de que los redactores de la encuesta pregunten es una indicación de mejora. No hicieron esta pregunta en las encuestas de 2019 ni de 2020.

¿Cómo se hace para monitorear la calidad de los datos en Airflow? En verdad, Airflow lo lleva a la mitad del camino. Como señalan sus responsables, "Cuando los flujos de trabajo se definen como código, se vuelven más mantenibles, versionables, comprobables y colaborativos".

Airflow ofrece esa representación formal del código. Lo que necesita es una herramienta de observabilidad creada específicamente para monitorear pipelines de datos. Las creados para monitorear productos son una medida intermedia, pero generalmente parte del recorrido porque ya tienen esas licencias.

Encontramos que hay varias fases por las que las organizaciones de ingeniería pasan en su camino hacia la madurez total de la observabilidad:

• Preconcientización: no monitorear la calidad de los datos (68 % de la comunidad de Airflow).
• Cinta adhesiva y alambre para empacar: tomar prestadas herramientas de observabilidad del producto y hacer que funcionen, aunque puede no ser lo ideal.
• Solución diseñada específicamente: adoptar herramientas de observabilidad de canal completo, como Databand, para automatizar alertas, aislar la causa principal y realizar arreglos más rápido. Establezca machine learning alrededor de los parámetros de datos esperados, obtenga alertas de Slack que indiquen datos faltantes o cambios de esquema en Airflow Scheduler, rastree el linaje de problemas y realice pruebas retrospectivas a través de datos históricos.

Aprender Airflow requiere una inversión de tiempo. Numerosos artículos y hilos de pila documentan las dificultades de los desarrolladores que se atascan en preguntas básicas, como "¿Por qué no comenzó el trabajo que programé?" (Una respuesta común: Airflow Scheduler comienza a programar al final del periodo de tiempo programado, no al principio. Más sobre eso más adelante).

Además, para ser competente con Airflow, deberá aprender Celery Executor y RabbitMQ o Redis, y no hay forma de evitarlo.

Esta fricción es suficiente para que algunas organizaciones, como la compañía de software CMS Bluecore, decidieran que era más fácil codificar esencialmente su propia interfaz Airflow.. De esa manera, cada nuevo desarrollador que contrataran o asignaran no tendría que aprender todos los nuevos operadores y, en cambio, podría confiar en los de Kubernetes con los que ya estaban familiarizados.

Estos obstáculos de aprendizaje son un problema recurrente suficiente para la comunidad que los "problemas de incorporación" justificaron su propia pregunta en la encuesta comunitaria de Airflow 2021 (en la foto a continuación).

Entre las principales quejas de los usuarios se encontraban "la falta de mejores prácticas para desarrollar DAG" y "no hay una opción fácil de lanzar". Este último problema se ha abordado parcialmente en la versión 2.0 de Airflow (que se lanzó después de la encuesta), pero esta versión se ejecuta en una base de datos SQLite donde no es posible la paralelización y todo ocurre secuencialmente.
Como señala la guía de inicio rápido de Airflow, “esto es muy limitante” y “debería superarlo muy rápidamente”.

El caso de uso principal de Airflow es para programar lotes periódicos, no para ejecuciones frecuentes, como incluso su propia documentación atestigua: "Se espera que los flujos de trabajo sean mayormente estáticos o que cambien lentamente." Esto significa que hay pocas capacidades para aquellos que necesitan muestrear o enviar datos de forma ad hoc y continua, y esto lo hace menos que ideal para algunos casos de uso de ETL y ciencia de datos.

Hay más. Ya lo hemos mencionado anteriormente, pero Airflow Scheduler ejecuta las tareas schedule_interval al final del intervalo de inicio del programador de Airflow, no al principio, lo que significa que tendrá que hacer más cálculos mentales de los que le gustaría y, en ocasiones, se llevará alguna sorpresa.

Y para ejecutar correctamente esos trabajos programados, deberá conocer los matices específicos de Airflow entre operadores y tareas, cómo funcionan los DAG, los argumentos predeterminados, la base de datos de metadatos de Airflow, el director de inicio para desplegar DAG, y la lista continúa.

¿Cómo lo solucionamos? Podría considerar uniste al 6 % de usuariosde Airflow que desarrollan su propia interfaz gráfica y renombran a los operadores en términos que les resulten más adecuados.

Encontrará muchas prácticas tradicionales de desarrollo de software y DevOps que faltan en Airflow, y una de ellas es la capacidad de mantener versiones de sus pipelines. No hay una manera fácil de documentar todo lo que ha creado y, si es necesario, volver a una versión anterior. Si, por ejemplo, elimina una tarea de su DAG y la vuelve a implementar, perderá los metadatos asociados en la instancia de tarea.

Esto hace que Airflow sea algo frágil y, a menos que haya escrito un script para capturarlo usted mismo, hace que los problemas de depuración sean mucho más difíciles. No es posible realizar pruebas de los posibles arreglos con los datos históricos para validarlos.

Nuevamente, Airflow proporciona la representación formal del código. Su desafío consiste en aplicar otras herramientas de desarrollo de software y DevOps para completar la funcionalidad que falta.

No hay mucho más que decir aquí. A menos que use archivos específicos de Docker compose que no forman parte del repositorio principal, no es posible.

¿Airflow Scheduler no funciona? Será mejor que rellene su taza de café. Es posible que tenga por delante algún trabajo de depuración que requiera mucho tiempo.

Esto se debe a que, en nuestra opinión, Airflow no distingue suficientemente entre los operadores que orquestan y los operadores que ejecutan. Muchos operadores hacen ambas cosas. Y si bien eso pudo haber ayudado con la programación inicial de la plataforma, es una inclusión fatal que hace que sea muy difícil de depurar. Si algo sale mal, sus desarrolladores tendrán que examinar primero sus parámetros de DataFlow y luego al propio operador, cada vez.

Por esta razón, herramientas como Databand pueden ser de gran ayuda. Databand se destaca por ayudarlo a comprender el estado de su infraestructura en todos los niveles: flujo de aire global, DAG, tareas y orientado al usuario. En lugar de dedicar tiempo de ingeniería de datos a aprender características muy específicas, Databand permite a los ingenieros de datos centrarse realmente en resolver problemas para el negocio.

Al igual que cualquier colaborador de código abierto que se toma el tiempo para proponer nuevos cambios, esperamos que este artículo se interprete como la nota de amor que es. Aquí en Databand somos colaboradores activos de la comunidad Airflow y estamos ansiosos por verlo crecer más allá de sus limitaciones existentes y servir mejor a más casos de uso de ETL y ciencia de datos.

Como dijimos antes, el 86 % de los usuarios planean seguir usándolo en lugar de otros motores de operaciones. Otro 86 % dice que lo recomendaría encarecidamente. Nos complace decir que pertenecemos a ambos grupos: es una gran herramienta. Y para aquellos de ustedes que recién se están familiarizando con Airflow, sepan que si tienen en mente los problemas mencionados anteriormente, Airflow Scheduler puede valer la pena. Vea cómo Databand reúne todas sus actividades de observabilidad de Airflow para simplificar y centralizar la observabilidad de Apache Airflow. Si está listo para profundizar, agende una demostración hoy mismo.