Dans cette section, nous détaillons le processus de création d’un tableau de bord de métriques dans Apache Airflow en utilisant un plugin personnalisé. Ce tableau de bord, intégrant des visualisations des exécutions de DAG (Directed Acyclic Graph), permet d’obtenir des informations précieuses sur les performances de l’environnement Airflow.

La première étape consiste à injecter la bibliothèque chart.js depuis un CDN open source. Cette bibliothèque est essentielle pour rendre les graphiques au sein des éléments de type canvas dans notre page web. Une fois la bibliothèque intégrée, nous définissons une variable de données qui contient un JSON dag_run_stats que nous avons préalablement créé dans le backend de la vue du tableau de bord. Cette donnée sera utilisée pour alimenter les graphiques.

L'étape suivante consiste à appeler la méthode new Chart(), qui prend en argument un élément de type canvas ainsi que la configuration du graphique. Ce processus permet de lier les données dynamiques aux visualisations graphiques en temps réel.

Vient ensuite l’implémentation du plugin proprement dite. Pour enregistrer le plugin dans Airflow, il est nécessaire de définir une classe MetricsPlugin qui dérive de AirflowPlugin et d’y inscrire un blueprint Flask et une vue associée au tableau de bord. Le blueprint Flask, défini sous le nom metrics_blueprint, contient les fichiers statiques et les modèles nécessaires à l’affichage du tableau de bord. La classe MetricsDashboardView est associée à une vue dans l’application Airflow, ce qui permet de présenter les graphiques interactifs.

Dans le fichier metrics_plugin/__init__.py, nous inscrivons le blueprint et la vue du tableau de bord comme suit :

python
from airflow.plugins_manager import AirflowPlugin
from flask import Blueprint from plugins.metrics_plugin.views.dashboard import MetricsDashboardView metrics_blueprint = Blueprint( "Metrics", __name__, template_folder="templates", static_folder="static", static_url_path="/static", ) class MetricsPlugin(AirflowPlugin): name = "Metrics Dashboard Plugin" flask_blueprints = [metrics_blueprint] appbuilder_views = [{ "name": "Dashboard", "category": "Metrics", "view": MetricsDashboardView() }]

Ce code permet de lier notre plugin au système de plugins d’Airflow, en le rendant disponible sous l’élément de menu “Metrics -> Dashboard” dans l’interface utilisateur d’Airflow.

Une fois le plugin enregistré, il faut placer le dossier metrics_plugin dans le répertoire plugins d’Airflow, puis redémarrer le serveur web pour vérifier que le tableau de bord fonctionne correctement. Dans le menu Airflow, sous la catégorie "Metrics", le menu "Dashboard" affichera notre vue de tableau de bord contenant les graphiques des exécutions des DAGs.

Le tableau de bord présente les exécutions de DAG réussies et échouées sur différentes périodes : 1 jour, 7 jours et 30 jours. Par exemple, le graphique des exécutions réussies (voir Figure 6.1) montre le nombre d'exécutions réussies au cours de ces périodes. En revanche, le graphique des exécutions échouées (voir Figure 6.2) fournit une visualisation similaire pour les DAGs ayant échoué.

Voici un aperçu des étapes clés pour créer ce tableau de bord :

  1. Structure du projet : Nous avons organisé notre projet dans le répertoire des plugins d'Airflow, en suivant un modèle qui peut être réutilisé pour d’autres plugins personnalisés dans l'environnement Airflow.

  2. Implémentation de la vue : La vue MetricsDashboardView gère la logique du backend du tableau de bord, interroge la base de données et récupère les données pour les graphiques.

  3. Template HTML du tableau de bord : Le template HTML génère l'interface utilisateur du tableau de bord et intègre le JavaScript nécessaire pour charger les graphiques avec les données récupérées par la vue.

  4. Implémentation du plugin : Le plugin est enregistré avec la classe MetricsPlugin qui lie le blueprint Flask et la vue du tableau de bord à l'environnement Airflow.

En suivant ces étapes, il devient possible de créer un tableau de bord personnalisé et visuellement attrayant qui offre une vision approfondie des performances de l’environnement Airflow. L'intégration de ce tableau de bord dans Airflow permet une surveillance accrue des flux de travail, offrant ainsi des insights précieux pour l’optimisation et la gestion des processus.

Il est important de noter que la personnalisation de ce tableau de bord ne se limite pas aux exécutions réussies ou échouées. En fonction des besoins spécifiques, il est possible d’ajouter d’autres visualisations ou de suivre d'autres métriques comme les durées d'exécution des tâches, le temps d’attente entre les tâches, ou l’utilisation des ressources. L'ajout de filtres interactifs permettrait également aux utilisateurs d'analyser les données de manière plus approfondie en fonction de critères spécifiques.

Il convient aussi de garder à l’esprit que, bien que ce tableau de bord soit utile pour visualiser les succès et échecs des DAGs, l'étape suivante consiste à intégrer des visualisations supplémentaires, telles que des graphiques de performance pour chaque tâche individuelle, afin d’identifier les goulots d’étranglement ou les tâches les plus lentes dans les DAGs. L’ajout de telles informations augmentera considérablement la valeur analytique du tableau de bord pour les utilisateurs.

Quels sont les avantages et défis de l'utilisation des fournisseurs de services pour déployer Airflow ?

Lorsqu'il s'agit de déployer Airflow, une solution souvent envisagée est de recourir à des fournisseurs de services spécialisés. Cela peut offrir une alternative séduisante pour les équipes qui souhaitent se concentrer davantage sur le développement sans avoir à gérer la complexité de l'infrastructure sous-jacente. Cependant, il est essentiel de bien comprendre les implications de ce choix.

Les fournisseurs de services peuvent réduire de manière significative les coûts d’acquisition et la charge de maintenance associée à l’utilisation d'Airflow. En prenant en charge la gestion de l'infrastructure et des opérations nécessaires, ces fournisseurs offrent une tranquillité d’esprit, libérant les équipes des soucis d’administration des serveurs et de mise à jour des logiciels. Mais tout n'est pas si simple. Si vous n’avez pas déjà d’infrastructure en place, il peut être plus avantageux financièrement de recourir à un fournisseur externe plutôt que de mettre en place votre propre infrastructure physique, notamment dans un environnement de calcul "bare metal".

Cela dit, faire appel à un fournisseur de services impose certaines restrictions. En effet, chaque fournisseur prend des décisions fermes sur la manière dont il souhaite que Airflow soit configuré et déployé. Ces choix peuvent limiter la flexibilité de votre équipe de développement et affecter la manière dont vous pouvez évoluer. Par exemple, vous pourriez vous retrouver dans l’impossibilité d’adopter certaines fonctionnalités récentes d'Airflow, de mettre à jour des packages Python spécifiques ou encore d’utiliser des intégrations tierces. Par conséquent, il est crucial d’évaluer minutieusement les meilleures pratiques proposées par ces fournisseurs et de bien comprendre leurs outils avant de vous engager. Ne sous-estimez pas l'importance de cette étape d’analyse afin d’éviter des blocages futurs.

Une fois ces questions relatives au choix du fournisseur traitées, la mise en œuvre de votre déploiement Airflow peut avancer. Cependant, il existe des étapes qui nécessitent encore beaucoup de réflexion et d’investissement, notamment en matière de développement local et de tests. En effet, la mise en place d'un environnement de développement local efficace est essentielle pour garantir la stabilité du déploiement et la qualité des DAGs. Le développement local dans un environnement contrôlé permet aux développeurs de tester rapidement leurs codes et de déceler les erreurs avant de passer à des workflows plus coûteux dans le cadre du processus de promotion.

Les environnements de développement local pour Airflow peuvent adopter deux configurations principales : l’utilisation d’environnements virtuels Python ou de Docker Compose. Un environnement virtuel Python, par exemple, permet de créer un espace isolé avec toutes les dépendances nécessaires pour exécuter Airflow, mais il peut être contraignant lorsqu’il y a des conflits avec les bibliothèques système locales. En revanche, Docker Compose permet de gérer des services dans des conteneurs et offre une plus grande flexibilité, bien que cela entraîne une complexité accrue lors de la mise en place initiale.

Dans un cadre plus avancé, les environnements de développement dans le cloud offrent une expérience optimale. Ces solutions permettent de provisionner des piles de services dans le cloud et de les personnaliser en fonction des besoins spécifiques du projet. Elles présentent l’avantage d’une grande élasticité, mais exigent également plus d'investissement, tant en termes de coût que de configuration, ce qui peut ne pas convenir à toutes les équipes.

Une fois l’environnement de développement mis en place, il convient de se pencher sur les pratiques de test. Le testing est un aspect souvent négligé ou mal compris dans le cadre d’Airflow. Cependant, il s’agit d’une phase cruciale qui vise à garantir la fiabilité du système et à prévenir toute erreur dans la production. Un bon plan de test doit évoluer en fonction des retours d’expérience et des défis rencontrés au fur et à mesure du déploiement. Les tests doivent viser à promouvoir la confiance dans le bon fonctionnement de votre déploiement.

Les tests dans Airflow peuvent être catégorisés en plusieurs niveaux : tests de validation, tests unitaires, tests fonctionnels et tests de performance. Les tests de validation, dits "smoke tests", vérifient que les DAGs sont bien définis et que le code Python est valide. Les tests unitaires se concentrent sur les méthodes spécifiques aux DAGs, tandis que les tests fonctionnels vérifient l'intégration de l'ensemble du système dans un contexte défini, en assurant que l'exécution d'un DAG produit les résultats attendus. Les tests de performance, quant à eux, sont essentiels pour s'assurer que le système peut gérer les charges de travail sans rencontrer de problèmes de performance, comme un temps de traitement trop long ou une consommation excessive de ressources.

Bien entendu, il est recommandé d’exécuter ces tests de manière progressive, en commençant par les tests les plus simples avant de s’attaquer aux tests plus complexes. Un environnement de test isolé est essentiel, en particulier lorsqu'il s'agit de valider les changements avant de les déployer dans un environnement de production.

Enfin, même si de nombreux outils et pratiques existent pour tester un déploiement Airflow, il est important de se rappeler qu'aucun système n'est à l'abri des erreurs. Les pannes et les incidents feront partie du processus, et il est donc fondamental d’intégrer des tests supplémentaires à chaque fois qu’un problème se présente, afin de prévenir sa récurrence. Avec le temps, votre stratégie de test deviendra plus mature et mieux adaptée à la spécificité de vos environnements de production.