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

Los equipos de datos que trabajan con procesos complejos de ingestión adoran Apache Airflow.

Puede definir sus flujos de trabajo en Python, el sistema tiene una amplia extensibilidad y ofrece una saludable amplitud de plug-ins. El ochenta y seis por ciento de sus usuarios dicen que están contentos y planean seguir usándolo sobre otros motores de flujo de trabajo. Un número igual dice que recomienda el producto.

Pero, como todo el software, y especialmente el de código abierto, Airflow está plagado de lagunas y defectos que tendrá que compensar. Para los desarrolladores que recién se están familiarizando con él, eso significa que el comienzo es lento y el camino es difícil. En este artículo, analizamos esos problemas y algunas posibles soluciones.

Airflow es un caballo de batalla con anteojeras. No hace nada para corregir el rumbo si las cosas van mal con los datos, solo con la canalización. Prácticamente todos los usuarios han experimentado alguna versión de Airflow que les indica que se ha completado un trabajo y que comprueban los datos solo para descubrir que faltaba una columna y que todo estaba mal, o que realmente no pasaban datos por los sistemas.

Esto es especialmente cierto cuando la organización de datos madura y pasas de 10 gráficos acíclicos de datos (DAG) a miles. En esa situación, es probable que ahora esté utilizando esos DAG para consumir 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 gobierno allí.

Aunque puede crear alertas de Slack para comprobar cada ejecución manualmente, para incorporar Airflow como una pieza útil de su organización de ingeniería de datos y cumplir sus SLA, desea automatizar los controles de calidad. Para ello, no solo es necesario saber si una tarea se ha ejecutado, sino también si se ha ejecutado correctamente. Y si no funcionó correctamente, ¿por qué y dónde se originó el error? De lo contrario, vivirá el Día de la Marmota.

No es un desafío sencillo y, siendo 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 raíz o para sugerir correcciones.

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 que han implementado la medición de la calidad de los datos, aunque el hecho de que los redactores de la encuesta estén preguntando es un indicio de mejora. No hicieron esta pregunta en las encuestas de 2019 ni de 2020.

¿Cómo se monitoriza la calidad de los datos en Airflow? En realidad, Airflow le lleva hasta la mitad del camino. Como señalan sus mantenedores, "cuando los flujos de trabajo se definen como código, se vuelven más fáciles de mantener, versionar, probar y colaborar".

Airflow ofrece esa representación formal del código. Lo que necesita es una herramienta de observabilidad creada específicamente para monitorizar los pipelines de datos. Los construidos para monitorizar los productos son una medida a medio camino, aunque suelen formar parte del viaje porque ya disponen de esas licencias.

Descubrimos que hay varias fases por las que pasan las organizaciones de ingeniería en su viaje hacia la plena madurez de la observabilidad:

• Pre-conciencia: no monitorizar la calidad de los datos (68 % de la comunidad de Airflow).
• Cinta adhesiva y alambre de embalar: tomar prestadas herramientas de observabilidad del producto y hacer que funcionen, aunque puede que no sea lo ideal.
• Solución diseñada especialmente: adoptar herramientas de observabilidad de todo el proceso, como Databand, para automatizar las alertas, aislar la causa raíz y realizar correcciones más rápido. Establezca el machine learning en torno a los parámetros de datos esperados, reciba alertas de Slack que indiquen datos faltantes o cambios de esquema en Airflow Scheduler, rastree el linaje de los problemas y realice pruebas retrospectivas a través de datos históricos.

Aprender Airflow requiere una inversión de tiempo. En Stack Overflow hay numerosos artículos e hilos que documentan las dificultades de los desarrolladores que se quedan atascados en preguntas básicas, como: "¿Por qué no ha comenzado la tarea que programé?". (Una respuesta común: Airflow Scheduler comienza a programar al final del período de tiempo programado, no al principio. Hablaremos sobre eso más adelante).

Para dominar 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 empresa 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 su lugar, podría confiar en los de Kubernetes con los que ya estaba familiarizado.

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

Entre las principales quejas de los usuarios se encontraban "la falta de buenas 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ápido".

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 el programador de Airflow ejecuta las tareas schedule_interval al final del intervalo de inicio del programador, no al principio, por lo que deberá realizar más cálculos mentales de los que le gustaría y, en ocasiones, se llevará alguna sorpresa.

Para ejecutar correctamente esas tareas programadas, deberá aprender 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 y el directorio de inicio para implementar DAG, entre otros aspectos.

¿La solución? Podría considerar unirse al 6 % de los usuarios de Airflow que desarrollan su propia interfaz gráfica de usuario y renombran los operadores con términos más comprensibles para ellos.

Encontrará muchas prácticas tradicionales de desarrollo de software y DevOps ausentes en Airflow, y una de ellas importante es la capacidad de mantener versiones de sus pipelines. No hay una forma sencilla de documentar todo lo que ha construido y, si es necesario, volver a una versión anterior. Si, por ejemplo, elimina una tarea de tu 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 hacer pruebas retrospectivas de las posibles correcciones con los datos históricos para validarlas.

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

No hay mucho más que decir sobre esto. A menos que use archivos específicos de Docker Compose que no formen parte del repositorio principal, no es posible.

¿Airflow Scheduler no funciona? Sírvase otro café. Es posible que le espere una depuración bastante tediosa.

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

Por este motivo, herramientas como Databand pueden ser de gran ayuda. Databand destaca por ayudarle a comprender el estado de su infraestructura en todos los niveles: Airflow global, DAG, tareas y orientación al usuario. En lugar de dedicar tiempo a la ingeniería de datos a aprender características muy específicas, Databand permite a los ingenieros de datos centrarse realmente en resolver los problemas de la empresa.

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

Como dijimos antes, el 86 % de los usuarios planea quedarse con él 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 acaban de familiarizarse con Airflow, sepan que si entran con los problemas antes mencionados en mente, Airflow Scheduler puede valer la pena el esfuerzo. Descubra 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, solicite una demostración hoy mismo.