6 réalités qui dérangent sur Apache Airflow (et comment y remédier)

Les équipes chargées des données qui travaillent sur des processus d'ingestion complexes adorent Apache Airflow.

Vous pouvez définir vos workflows en Python, le système est très extensible et propose un large éventail de plug-ins. Quatre-vingt-six pour cent de ses utilisateurs se disent satisfaits et prévoient de Continuer à l'utiliser plutôt que d'autres workflow. Un nombre égal déclare recommander le produit.

Mais, comme tous les logiciels, et en particulier les logiciels open source, Airflow souffre d'une série de lacunes et d'insuffisances que vous devrez compenser. Pour les développeurs qui ne font que s'y familiariser, cela signifie que les mises en route sont lentes et difficiles. Dans cet article, nous abordons ces problèmes et quelques solutions de contournement possibles.

Le flux d'air, c'est comme un cheval de bataille avec des œillères. Il ne sert à rien de corriger le cours si les choses tournent mal avec les données (uniquement avec le pipeline). Pratiquement tous les utilisateurs ont déjà vu une version d’Airflow leur indiquant qu’un travail a été terminé et vérifiant les données, pour découvrir qu’une colonne manquait et que tout est faux, ou qu’aucune donnée ne passe réellement dans les systèmes.

Cela est particulièrement vrai une fois que l'Entreprise des données mûrit et que l'on passe de 10 graphiques acycliques de données (DAG) à des milliers. Dans ce cas, vous utilisez probablement ces DAGs pour ingérer des données provenant de sources de données externes et d'APIs, ce qui rend le contrôle de la qualité des données dans Airflow encore plus difficile. Vous ne pouvez pas « nettoyer » le jeu de données source ni y mettre en œuvre vos politiques de gouvernance.

Bien que vous puissiez créer des alertes Slack pour vérifier chaque exécution manuellement, intégrer Airflow comme un élément utile de votre Entreprise d’ingénierie des données et atteindre vos SLA, vous voulez automatiser les contrôles de qualité. Et pour ce faire, vous devez savoir si un travail a été mené à bien, mais aussi s’il s’est déroulé correctement. et si le processus ne s’est pas déroulé correctement, pourquoi et d’où provient l’erreur. Sinon, vous vivrez sans fil.

Ce n'est pas un défi simple et, pour être franc, c'est la raison pour laquelle IBM® Databand® a été créé. La plupart des outils d'observabilité produit comme Datadog et New Relic n'ont pas été conçus pour analyser les pipelines et ne peuvent pas isoler où les problèmes ont pris naissance, regrouper les problèmes coexistant pour suggérer une cause racine, ou pour suggérer des correctifs.

Cependant, le besoin d'observabilité n'est pas encore totalement compris, même au sein de la communauté Airflow. Aujourd'hui, seuls 32 % disent avoir mis en place une mesure de la qualité des données, même si le fait que les rédacteurs de l'enquête posent la question est un signe d'amélioration. Ils n’ont pas posé cette question dans les enquêtes de 2019 ou 2020.

Comment contrôler la qualité des données dans Airflow ? En réalité, Airflow vous aide à y parvenir. Comme le soulignent ses responsables, « lorsque les flux de travail sont définis sous forme de code, ils deviennent plus faciles à gérer, à versionner, à tester et à collaborer. »

Airflow offre cette représentation formelle du code. Vous avez besoin d'un outil d'observabilité conçu spécifiquement pour surveiller les pipelines de données. Ceux qui sont conçus pour surveiller les produits sont à mi-chemin, mais font généralement partie du parcours, car ils disposent déjà de ces licences.

Nous constatons que les organisations d’ingénierie passent par plusieurs phases pour atteindre une maturité totale en matière d’observabilité :

• Pré-sensibilisation : Ne pas surveiller la qualité des données (68 % de la communauté Airflow).
• Bande tendue et bandage : empruntez les outils d'observabilité des produits et faites-les fonctionner, même si cela n'est pas l'idéal.
• Une solution adaptée : Adopter des outils d'observabilité de l'ensemble du pipeline comme Databand pour automatiser les alertes, isoler les causes profondes et résoudre les problèmes plus rapidement. Configurez machine learning autour des paramètres de données attendus, recevez des alertes Slack indiquant des données manquantes ou des changements de schéma dans Airflow Scheduler, remontez la lignée des problèmes, et faites un backtest à partir de données historiques.

L'apprentissage d'Airflow demande un investissement en temps. De nombreux articles et discussions sur pile documentent les difficultés rencontrées par les développeurs qui se retrouvent bloqués sur des questions basiques, comme : « Pourquoi la tâche que j’ai planifiée n’a-t-elle pas commencé ? » (Réponse courante : Le programmateur de flux d'air commence la programmation à la fin de la période programmée, et non au début. (Nous y reviendrons ultérieurement.)

De plus, pour maîtriser Airflow, vous devrez apprendre Celery Executor et RabbitMQ ou Redis, et il n'y a aucun moyen de contourner cela.

Cette friction est suffisante pour que certaines entreprises, comme la société de logiciels CMS Bluecore, aient décidé qu'il était plus facile de coder leur propre interface Airflow. Ainsi, chaque nouveau développeur embauché ou affecté n'aurait pas à apprendre tous les nouveaux opérateurs, et pourrait au contraire s'appuyer sur ceux de Kubernetes qu'il connaissait déjà.

Ces obstacles d’apprentissage sont suffisamment récurrents pour la communauté et les « problèmes d’intégration » méritaient d’être interrogés dans le cadre de l’enquête communautaire d’Airflow pour 2021 (voir la photo ci-dessous).

Parmi les principales plaintes des utilisateurs figuraient « un manque de bonnes pratiques pour le développement des DAG » et « l’absence d’option facile à lancer ». Ce dernier problème a été partiellement traité dans Airflow Version 2.0 (sortie après le sondage), mais cette version fonctionne sur une base SQLite où aucune parallélisation n’est possible et où tout se déroule de manière séquentielle.
Comme le souligne le guide de démarrage rapide d'Airflow ( ), « c'est très limitatif » et « vous devriez vous en passer très rapidement ».

Le principal cas d’utilisation d'Airflow est la planification de lots périodiques, et non d'exécutions fréquentes, comme même sa propre documentation atteste: « Les workflows sont censés être principalement statiques ou changer lentement. » Cela signifie que peu de fonctionnalités sont disponibles pour ceux qui ont besoin d’échantillonner ou d’envoyer des données de manière ponctuelle et continue, ce qui la rend moins idéale pour certains cas d’utilisation que sont l’ETL et la science des données.

Mais ça ne s'arrête pas là. Nous y sommes déjà allés, mais l'Airflow Scheduler exécute des tâches Schedule_Interval à la fin de l'intervalle de début, et non au début, ce qui signifie que vous ferez plus de calculs de poche que vous ne le feriez et, parfois, vous serez surpris.

Et pour exécuter correctement ces tâches planifiées, vous devrez connaître les nuances spécifiques à Airflow entre les opérateurs et les tâches, le fonctionnement des DAG, les arguments par défaut, la base de données de métadonnées Airflow, le répertoire principal pour déployer les DAG, et la liste continue.

La solution ? Vous pourriez envisager de rejoindre les 6 % d'utilisateurs d'Airflow qui développent leur propre interface utilisateur graphique et renomment les opérateurs dans des termes qui leur semblent plus logiques.

Vous constaterez que de nombreuses pratiques traditionnelles de développement logiciel et DevOps manquent à Airflow, et l’une des principales est la capacité à maintenir des versions de vos pipelines. Il n’y a aucun moyen simple de documenter tout ce que vous avez créé et, si nécessaire, de revenir à une version antérieure. Si, par exemple, vous supprimez une tâche de votre DAG et la redéployez, vous perdrez les métadonnées associées sur l’instance de tâche.

Cela rend Airflow quelque peu fragile et, à moins que vous n'ayez écrit un script pour capturer cela vous-même, cela rend les problèmes de débogage beaucoup plus difficiles. Il n'est pas possible de tester d'éventuels correctifs par rapport à des données historiques pour les valider.

Encore une fois, Airflow fournit la représentation officielle du code. Le défi consiste à appliquer d’autres outils de développement logiciel et DevOps pour combler les fonctionnalités manquantes.

Je n’ai pas grand-chose à dire là-dessus. À moins que vous n’utilisiez des fichiers Docker Compose spécifiques qui ne font pas partie du référentiel principal, cela n’est pas possible.

Le planificateur de flux d'air ne fonctionne pas ? Mieux vaut vous resservir un café. Il se peut que vous ayez du temps à déboguer devant vous.

C'est parce que, selon nous, Airflow ne distingue pas suffisamment les opérateurs qui Orchestrate et ceux qui exécutent. De nombreux opérateurs font les deux. Et bien que cela ait pu aider avec le codage initial de la plateforme, il s’agit d’une inclusion inévitable qui rend très difficile le débogage. En cas de problème, vos développeurs devront d'abord examiner leurs paramètres DataFlow, puis l'opérateur lui-même, à chaque fois.

C’est pourquoi des outils comme Databand peuvent être d’une grande aide. Databand excelle lorsqu'il s'agit de vous aider à comprendre la santé de votre infrastructure à tous les niveaux : flux d'air mondial, DAG, tâches et interface utilisateur. Au lieu de consacrer du temps à l'apprentissage de fonctionnalités très spécifiques, Databand permet aux ingénieurs de données de se concentrer sur la résolution de problèmes pour l'entreprise.

Comme tout contributeur open source qui prend le temps de proposer de nouvelles modifications, nous espérons que cet article sera interprété comme une véritable note d'amour. Chez Databand, nous contribuons activement à la communauté Airflow et sommes impatients de la voir dépasser ses limites existantes et de mieux répondre à un plus grand nombre de cas d'utilisation de l'ETL et de la science des données.

Comme nous l’avons dit précédemment, 86 % des utilisateurs prévoient de s’en tenir à d’autres moteurs d’exploitation. 86 % disent qu'ils le recommanderaient vivement. Nous sommes heureux de pouvoir dire que nous appartenons aux deux groupes - c'est un outil formidable. Et pour ceux d'entre vous qui viennent de se familiariser avec Airflow, sachez simplement que si vous pensez aux problèmes mentionnés ci-dessus, Airflow Scheduler peut en valoir la peine. Voir comment Databand rassemble toutes vos activités d’observabilité d’Airflow pour simplifier et centraliser votre observabilité d’Apache Airflow. Si vous êtes prêt à aller plus loin, réservez une démo dès aujourd’hui.