Simplifiez la création et la maintenance de DAG (Directed Acyclic Graph) Airflow avec Hamilton en 8 minutes

Simplifiez la création et la maintenance de DAG Airflow avec Hamilton en 8 minutes.

Comment Hamilton peut vous aider à écrire des DAGs Airflow plus faciles à maintenir

Une représentation abstraite de la relation entre Airflow et Hamilton. Airflow contribue à tout rassembler, tandis que Hamilton rend les aspects internes gérables. Image de Pixabay .

Cet article est rédigé en collaboration avec Thierry Jean et est initialement paru ici .

Cet article vous guide à travers les avantages de deux projets open source, Hamilton et Airflow, ainsi que leur travail en tandem avec les graphes acycliques dirigés (DAGs). De manière générale, Airflow est responsable de l’orchestration (pensez macro) et Hamilton aide à créer des transformations de données propres et faciles à maintenir (pensez micro).

Pour ceux qui ne connaissent pas Hamilton, nous vous invitons à consulter une présentation interactive sur tryhamilton.dev, ou nos autres articles, comme celui-ci . Sinon, nous parlerons de Hamilton de manière générale et vous renverrons à la documentation de référence pour plus de détails. Pour référence, je suis l’un des co-créateurs de Hamilton.

Pour ceux qui essaient encore de comprendre mentalement comment les deux peuvent fonctionner ensemble, la raison pour laquelle vous pouvez exécuter Hamilton avec Airflow est que Hamilton est simplement une bibliothèque avec une empreinte de dépendance réduite, et il est donc possible d’ajouter Hamilton à votre configuration Airflow en un rien de temps !

Juste pour récapituler, Airflow est la norme de l’industrie pour orchestrer les pipelines de données. Il alimente toutes sortes d’initiatives de données, y compris l’ETL, les pipelines de ML et l’informatique décisionnelle. Depuis sa création en 2014, les utilisateurs d’Airflow ont rencontré certaines difficultés avec la rédaction et la maintenance des pipelines de données :

  1. Gérer de manière maintenable l’évolution des workflows ; ce qui commence de manière simple peut devenir invariablement complexe.
  2. Écrire du code modulaire, réutilisable et testable qui s’exécute dans une tâche Airflow.
  3. Suivre la lignée du code et des artefacts de données qu’un DAG Airflow produit.

C’est là que nous pensons que Hamilton peut aider ! Hamilton est un micro-framework Python pour écrire des transformations de données. En bref, on écrit des fonctions Python dans un style “déclaratif”, que Hamilton analyse et connecte dans un graphe en fonction de leurs noms, de leurs arguments et de leurs annotations de type. Des sorties spécifiques peuvent être demandées et Hamilton exécutera le chemin de fonction requis pour les produire. Parce qu’il ne fournit pas de capacités d’orchestration macro, il s’associe parfaitement à Airflow en aidant les professionnels des données à écrire un code plus propre et plus réutilisable pour les DAGs Airflow.

Le paradigme Hamilton en image. Cet exemple montre comment on pourrait mapper du code pandas procédural à des fonctions Hamilton qui définissent un DAG. Remarque : Hamilton peut être utilisé pour tous les types d'objets Python, pas seulement Pandas. Image de l'auteur.

Écrire des DAGs Airflow faciles à maintenir

Une utilisation courante d’Airflow est d’aider à la science des données et à l’apprentissage automatique. L’exécution de ces charges de travail en production nécessite souvent des workflows complexes. Une décision de conception nécessaire avec Airflow est de déterminer comment diviser le workflow en tâches Airflow. Si vous en créez trop, vous augmentez les frais généraux de planification et d’exécution (par exemple, le déplacement de grandes quantités de données), si vous en créez trop peu, vous obtenez des tâches monolithiques qui peuvent prendre du temps à s’exécuter, mais qui sont probablement plus efficaces à exécuter. Le compromis ici est la complexité du DAG Airflow par rapport à la complexité du code au sein de chaque tâche. Cela rend le débogage et la compréhension du workflow plus difficiles, surtout si vous n’êtes pas l’auteur initial du DAG Airflow. Le plus souvent, la structure initiale des tâches du DAG Airflow devient fixe, car la refonte du code des tâches devient prohibitif !

Alors que des DAGs plus simples tels que A->B->C sont souhaitables, il existe une tension inhérente entre la simplicité de la structure et la quantité de code par tâche. Plus il y a de code par tâche, plus il est difficile d’identifier les points de défaillance, au détriment des performances de calcul potentielles. Mais en cas d’échec, les nouvelles tentatives deviennent plus coûteuses avec la “taille” de la tâche.

Choix de structure de DAG Airflow : combien de tâches ? combien de code par tâche ? Image par l'auteur.

Et si vous pouviez gérer la complexité au sein d’une tâche Airflow, quelle que soit la taille du code qu’elle contient, et bénéficier de la flexibilité pour changer facilement la forme du DAG Airflow avec un effort minimal ? C’est là qu’intervient Hamilton.

Avec Hamilton, vous pouvez remplacer le code de chaque tâche Airflow par un DAG Hamilton, où Hamilton gère l’orchestration “micro” du code au sein de la tâche. Note : Hamilton vous permet en réalité de modéliser logiquement tout ce que vous souhaitez que fasse un DAG Airflow. Plus d’informations à ce sujet ci-dessous.

Pour utiliser Hamilton, vous chargez un module Python contenant vos fonctions Hamilton, instanciez un pilote Hamilton et exécutez un DAG Hamilton dans une tâche Airflow en quelques lignes de code. En utilisant Hamilton, vous pouvez écrire votre transformation de données à une granularité arbitraire, vous permettant d’inspecter en détail ce que chaque tâche Airflow fait.

Plus précisément, le fonctionnement du code est le suivant :

  1. Importez vos modules de fonctions
  2. Passez-les au pilote Hamilton pour construire le DAG.
  3. Ensuite, appelez Driver.execute() avec les sorties que vous souhaitez exécuter à partir du DAG que vous avez défini.

Jetons un coup d’œil à un code qui crée un DAG Airflow à nœud unique mais utilise Hamilton pour entraîner et évaluer un modèle ML :

Maintenant, nous n’avons pas montré le code Hamilton ici, mais les avantages de cette approche sont les suivants :

  1. Tests unitaires et d’intégration. Hamilton, grâce à ses exigences de nommage et d’annotations de type, pousse les développeurs à écrire du code Python modulaire. Cela donne des modules Python bien adaptés aux tests unitaires. Une fois que votre code Python est testé unitairement, vous pouvez développer des tests d’intégration pour vous assurer qu’il se comporte correctement dans vos tâches Airflow. En revanche, tester le code contenu dans une tâche Airflow est moins trivial, surtout dans des environnements CI/CD, car cela nécessite l’accès à un environnement Airflow.
  2. Réutilisation des transformations de données. Cette approche permet de conserver le code de transformation des données dans des modules Python, séparés du fichier DAG Airflow. Cela signifie que ce code peut également être exécuté en dehors d’Airflow ! Si vous venez du monde de l’analyse, cela devrait vous sembler similaire au développement et au test de requêtes SQL dans un fichier .sql externe, puis à son chargement dans vos opérateurs Postgres Airflow.
  3. Réorganisez facilement votre DAG Airflow. L’effort requis pour modifier votre DAG Airflow est désormais beaucoup plus faible. Si vous modélisez logiquement tout dans Hamilton, par exemple, un pipeline d’apprentissage automatique de bout en bout, il suffit de déterminer quelle partie de ce DAG Hamilton doit être calculée dans chaque tâche Airflow. Par exemple, vous pouvez passer d’une tâche Airflow monolithique à une tâche avec quelques tâches ou beaucoup de tâches – tout ce qui doit changer, c’est ce que vous demandez à Hamilton, car votre DAG Hamilton n’a pas besoin de changer du tout !

Développement itératif avec Hamilton et Airflow

Dans la plupart des projets de science des données, il serait impossible d’écrire le DAG du système final dès le premier jour, car les exigences changeront. Par exemple, l’équipe de science des données pourrait vouloir essayer différents ensembles de fonctionnalités pour leur modèle. Jusqu’à ce que la liste soit établie et finalisée, il est probablement indésirable d’avoir l’ensemble de fonctionnalités dans votre code source et sous contrôle de version ; des fichiers de configuration seraient préférables.

Airflow prend en charge les configurations DAG par défaut et en temps d’exécution et enregistre ces paramètres pour rendre chaque exécution du DAG reproductible. Cependant, l’ajout de comportements configurables nécessitera l’ajout de déclarations conditionnelles et de complexité au code de votre tâche Airflow. Ce code pourrait devenir obsolète pendant le projet ou n’être utile que dans des scénarios particuliers, ce qui diminuerait finalement la lisibilité de vos DAG.

En revanche, Hamilton peut utiliser la configuration d’exécution d’Airflow pour exécuter différentes transformations de données à partir du graphe de fonctions à la volée. Cette approche en couches peut considérablement augmenter l’expressivité des DAG Airflow tout en maintenant une simplicité structurelle. Alternativement, Airflow peut générer dynamiquement de nouveaux DAG à partir de configurations, mais cela pourrait diminuer l’observabilité et certaines de ces fonctionnalités restent expérimentales.

Interface utilisateur Airflow pour la configuration de l'exécution du DAG. Image par l'auteur.

Si vous travaillez selon un modèle de transfert, cette approche favorise une séparation des responsabilités entre les ingénieurs de données chargés du système de production Airflow et les data scientists chargés de développer des solutions métier en écrivant du code Hamilton. Cette séparation peut également améliorer la cohérence des données et réduire la duplication de code. Par exemple, un seul DAG Airflow peut être réutilisé avec différents modules Hamilton pour créer différents modèles. De même, les mêmes transformations de données Hamilton peuvent être réutilisées dans différents DAG Airflow pour alimenter des tableaux de bord, des API, des applications, etc.

Voici deux images. La première illustre le DAG Airflow de haut niveau contenant deux nœuds. La seconde affiche le DAG Hamilton de bas niveau du module Python evaluate_model importé dans la tâche Airflow train_and_evaluate_model.

1. Interface utilisateur Airflow : DAG Airflow sur l'absentéisme
2. Visualisation du pilote Hamilton : graphe de fonction pour evaluate_model.py

Gestion des artefacts de données

Les projets de data science produisent un grand nombre d’artefacts de données provenant de jeux de données, d’évaluations de performances, de figures, de modèles entraînés, etc. Les artefacts nécessaires changeront tout au long du cycle de vie du projet (exploration des données, optimisation du modèle, débogage en production, etc.). C’est un problème pour Airflow, car la suppression d’une tâche d’un DAG supprimera son historique de métadonnées et rompra la généalogie des artefacts. Dans certains scénarios, la production d’artefacts de données inutiles ou redondants peut entraîner des coûts de calcul et de stockage significatifs.

Hamilton peut fournir la flexibilité nécessaire pour la génération d’artefacts de données grâce à son API de sauvegarde de données. Les fonctions décorées avec @save_to.* ajoutent la possibilité de stocker leur sortie, il suffit de demander cette fonctionnalité via Driver.execute(). Dans le code ci-dessous, l’appel à validation_predictions_table renverra le tableau, tandis que l’appel à la valeur output_name_ de save_validation_predictions renverra le tableau et l’enregistrera au format .csv

Cette flexibilité ajoutée permet aux utilisateurs de basculer facilement entre les artefacts générés, et cela peut être fait directement via la configuration d’exécution d’Airflow, sans modifier le DAG Airflow ou les modules Hamilton.

De plus, le graphe de fonctions Hamilton à grain fin permet une généalogie et une provenance des données précises. Les fonctions utilitaires what_is_downstream_of() et what_is_upstream_of() permettent de visualiser et d’explorer de manière programmatique les dépendances des données. Nous orientons les lecteurs intéressés vers plus de détails ici.

Pour finir et un exemple pour commencer

J’espère qu’à présent nous vous avons convaincu que l’association de Hamilton avec Airflow vous aidera à relever les défis de création et de maintenance des DAG d’Airflow. Comme il s’agit d’un court article, pour conclure, passons au code que nous avons dans le référentiel Hamilton pour vous.

Pour vous aider à démarrer, nous avons un exemple sur la façon d’utiliser Hamilton avec Airflow. Il devrait couvrir toutes les bases dont vous avez besoin pour commencer. Le fichier README explique comment configurer Airflow avec Docker, de sorte que vous n’avez pas besoin de vous soucier de l’installation des dépendances juste pour jouer avec l’exemple.

Quant au code de l’exemple, il contient deux DAG Airflow, l’un présentant un exemple basique de Hamilton pour créer des “features” destinées à l’entraînement d’un modèle, et l’autre un exemple de projet d’apprentissage automatique plus complet, qui réalise un pipeline complet de création de “features”, puis d’ajustement et d’évaluation d’un modèle. Pour les deux exemples, vous trouverez le code Hamilton dans le dossier des plugins.

Ce à quoi vous devriez vous attendre à voir dans l'exemple Airflow. Image de l'auteur.

Si vous avez des questions ou besoin d’aide, veuillez rejoindre notre Slack. Sinon, pour en savoir plus sur les fonctionnalités et la fonctionnalité de Hamilton, nous vous renvoyons à la documentation de Hamilton.

Références et lectures complémentaires

Merci d’avoir consulté cet article. Si vous souhaitez approfondir ou en apprendre davantage sur Hamilton, nous avons les liens suivants à vous proposer :

  • Exemple de code Hamilton + Airflow
  • Documentation Hamilton
  • tryhamilton.dev – une façon interactive d’en savoir plus sur Hamilton.
  • Pour un autre système d’orchestration intégrant Hamilton, vous pouvez consulter Hamilton + Metaflow.
  • Communauté Slack Hamilton
  • Lignée + Hamilton en 10 minutes
  • Présentation de Hamilton (histoire et introduction)
  • Hamilton + Pandas en 5 minutes
  • Comment utiliser Hamilton dans un environnement de Notebook

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

AI

LNS Investit 10,9 millions de dollars dans le développement de technologies d'IA sûres

La National Science Foundation a déclaré qu'elle investira 10,9 millions de dollars dans la recherche pour le dévelop...

Science des données

Les drones naviguent dans des environnements invisibles avec des réseaux neuronaux liquides.

Les chercheurs du MIT présentent une avancée nouvelle dans la navigation autonome des drones, en utilisant des réseau...

AI

La queue (longue) remue le chien les conséquences imprévues de l'art personnalisé de l'IA

La récente présentation par Meta d’Emu dans le monde des films génératifs marque un tournant, un moment où la t...

AI

Exploration du NLP - Lancement du NLP (Étape n°3)

Voici quelques concepts sur lesquels j'ai travaillé cette semaine, en particulier sur les embeddings de mots. J'ai ég...