Cas pratiques Apache Airflow

Contexte : Une tâche d’appel API échoue occasionnellement pour des raisons réseau temporaires. Le Problème : À la première erreur, le DAG s’arrête sans tentative de relance. Contraintes : Configurer retries et retry_delay dans default_args. Limiter le nombre de tentatives pour éviter les boucles infinies. Livrable attendu : Proposer une configuration de retry permettant d’améliorer la résilience du pipeline.

Contexte : Un DAG a été déployé mais aucune exécution ne se déclenche. Le Problème : Le start_date est défini dans le futur. Extrait actuel : start_date=datetime(2026, 1, 1) Nous sommes en 2025. Contraintes : Corriger la date pour permettre l’exécution immédiate. Respecter les bonnes pratiques Airflow (date fixe et non dynamique). Livrable attendu : Proposer une correction du start_date garantissant le déclenchement correct du DAG.

Contexte : Un nouveau DAG a été ajouté dans le dossier dags mais n’apparaît pas dans l’interface Airflow. Le Problème : Une erreur d’import Python empêche son chargement. Extrait actuel : from airflow.operators.python import PythonOperatorX L’opérateur PythonOperatorX n’existe pas. Contraintes : Corriger l’import. Vérifier la compatibilité avec la version Airflow utilisée. Livrable attendu : Identifier et corriger l’erreur empêchant l’affichage et le chargement du DAG.

Contexte : Un DAG complexe comporte plusieurs tâches interdépendantes. Le Problème : Une dépendance circulaire a été créée par erreur, empêchant l’exécution. Extrait logique actuelle : task_a >> task_b task_b >> task_a Contraintes : Identifier la boucle. Corriger la logique tout en conservant le flux métier. Livrable attendu : Proposer une structure de dépendances valide éliminant la circularité.

Contexte : Les exécutions planifiées ne correspondent pas aux horaires attendus. Le Problème : Le fuseau horaire par défaut d’Airflow diffère de celui de l’équipe métier. Contraintes : Vérifier la configuration timezone dans airflow.cfg ou utiliser pendulum dans le DAG. Assurer cohérence avec le cron. Livrable attendu : Proposer une configuration correcte du fuseau horaire garantissant des exécutions aux horaires attendus.

Contexte : Une tâche doit exécuter un script shell pour charger des données. Le Problème : La commande échoue car le chemin du script est incorrect. Extrait actuel : BashOperator( task_id="load_data", bash_command="/scripts/load.sh" ) Le fichier se trouve en réalité dans /opt/scripts/. Contraintes : Corriger le chemin sans modifier la logique globale du DAG. Livrable attendu : Proposer une correction permettant l’exécution correcte du script via BashOperator.

Contexte : Votre équipe data doit automatiser un traitement quotidien de génération de rapport. Le Problème : Le script Python est exécuté manuellement chaque jour, ce qui entraîne des oublis et des retards. Contraintes : Créer un DAG Airflow simple planifié quotidiennement. Utiliser un PythonOperator. Définir un start_date cohérent et un schedule_interval adapté. Éviter toute dépendance externe complexe. Livrable attendu : Écrire un DAG minimal fonctionnel permettant d’exécuter automatiquement un script Python chaque jour.

Contexte : Une équipe souhaite pouvoir lancer ponctuellement un DAG en dehors de sa planification normale. Le Problème : Les utilisateurs ne savent pas comment déclencher manuellement un run. Contraintes : Activer le DAG. Vérifier qu’il n’est pas en paused state. Permettre un trigger manuel sans modifier la planification. Livrable attendu : Décrire les étapes nécessaires pour permettre et effectuer un déclenchement manuel d’un DAG.

Contexte : Un pipeline ETL comporte trois étapes : extraction, transformation et chargement. Le Problème : Les tâches sont actuellement indépendantes et peuvent s’exécuter dans le désordre. Contraintes : Définir des dépendances explicites entre tâches dans le DAG. Utiliser l’opérateur >> ou set_upstream/set_downstream. Garantir l’ordre logique. Livrable attendu : Proposer un DAG structuré avec dépendances correctes entre les tâches extract, transform et load.

Contexte : Une tâche de nettoyage des données doit être exécutée chaque dimanche à 02h00 du matin. Le Problème : Aucun schedule_interval n’a encore été défini. Contraintes : Utiliser une expression cron adaptée. Vérifier la cohérence du fuseau horaire. Éviter un schedule dynamique. Livrable attendu : Proposer un DAG configuré avec une planification cron correcte pour une exécution hebdomadaire.

Contexte : Votre pipeline doit traiter quotidiennement des fichiers provenant de plusieurs sources partenaires. Le Problème : Le DAG actuel duplique manuellement les tâches pour chaque source, rendant la maintenance complexe. Contraintes : Générer dynamiquement les tâches à partir d’une liste Python. Éviter la duplication de code. Maintenir des dépendances claires entre extraction et transformation. Livrable attendu : Proposer un DAG dynamique utilisant une boucle ou TaskFlow API permettant de créer automatiquement les tâches pour chaque source.

Contexte : Une tâche dépend d’une variable d’environnement définie sur certains environnements seulement. Le Problème : Le DAG échoue en production car la variable n’est pas définie. Extrait actuel : os.environ["API_KEY"] Contraintes : Utiliser les Variables Airflow ou Connections pour centraliser la configuration. Éviter les dépendances système directes. Livrable attendu : Proposer une solution robuste de gestion des paramètres sensibles via Airflow.

Contexte : Un DAG planifié quotidiennement a été activé avec plusieurs mois de retard. Le Problème : Airflow déclenche automatiquement des centaines d’exécutions passées (catchup activé), surchargeant le système. Extrait actuel : catchup=True Contraintes : Désactiver le catchup si non nécessaire. Limiter les exécutions simultanées via max_active_runs. Maintenir la cohérence des données. Livrable attendu : Proposer une configuration permettant d’éviter un backfill massif non désiré tout en conservant un contrôle sur les exécutions historiques.

Contexte : Plusieurs DAGs s’exécutent simultanément et saturent la capacité du worker. Le Problème : Aucune limite de parallélisme n’est définie au niveau du DAG ou globalement. Contraintes : Configurer concurrency, max_active_tasks ou pools. Équilibrer la charge entre DAGs critiques et secondaires. Livrable attendu : Proposer une configuration permettant de contrôler la concurrence et stabiliser l’exécution globale.

Contexte : Deux tâches doivent échanger des données intermédiaires dans un DAG. Le Problème : Les données échangées via XCom sont trop volumineuses, provoquant une surcharge de la base Airflow. Extrait logique actuelle : task_instance.xcom_push(key="data", value=large_dataframe) Contraintes : Limiter l’usage de XCom aux métadonnées légères. Stocker les données volumineuses dans un stockage externe. Livrable attendu : Proposer une correction garantissant un échange de données efficace sans surcharger la base Airflow.

Contexte : Selon un paramètre d’entrée, le pipeline doit exécuter un traitement standard ou un traitement avancé. Le Problème : Le DAG actuel exécute systématiquement les deux branches. Contraintes : Utiliser BranchPythonOperator ou TaskFlow API pour définir un branchement conditionnel. Garantir que seule la branche sélectionnée s’exécute. Livrable attendu : Proposer une implémentation permettant un contrôle conditionnel du flux d’exécution dans le DAG.

Contexte : Un pipeline secondaire doit démarrer uniquement après la réussite d’un pipeline principal. Le Problème : Les deux DAGs sont actuellement indépendants et peuvent s’exécuter dans le mauvais ordre. Contraintes : Utiliser TriggerDagRunOperator ou ExternalTaskSensor. Garantir que le second DAG démarre uniquement après succès du premier. Livrable attendu : Proposer une implémentation permettant la synchronisation correcte entre deux DAGs distincts.

Contexte : Un pipeline doit attendre l’arrivée d’un fichier dans un stockage externe avant de poursuivre le traitement. Le Problème : Le DAG démarre immédiatement et échoue si le fichier n’est pas encore disponible. Contraintes : Utiliser un FileSensor ou équivalent. Configurer un timeout et un poke_interval raisonnables. Éviter le blocage excessif des ressources. Livrable attendu : Proposer une implémentation utilisant un Sensor permettant d’attendre proprement la disponibilité du fichier.

Contexte : Certains pipelines critiques doivent respecter des délais stricts d’exécution. Le Problème : Aucune alerte n’est envoyée en cas de dépassement du temps prévu. Contraintes : Configurer un SLA sur certaines tâches. Mettre en place une notification en cas de dépassement. Éviter les faux positifs. Livrable attendu : Proposer une configuration SLA avec gestion des alertes adaptée aux exigences métier.

Contexte : Certaines tâches prennent plusieurs heures et bloquent les workers disponibles. Le Problème : Les ressources sont mal utilisées et les autres pipelines sont ralentis. Contraintes : Analyser la possibilité d’externaliser certaines tâches (KubernetesPodOperator, CeleryExecutor). Améliorer la scalabilité. Livrable attendu : Proposer une stratégie d’optimisation permettant d’améliorer l’utilisation des ressources et la scalabilité du système Airflow.

Contexte : Votre plateforme data exécute des pipelines critiques 24/7 via Apache Airflow en production. Le Problème : L’instance actuelle repose sur un seul scheduler et une base locale, créant un point unique de défaillance. Contraintes : Mettre en place une architecture distribuée avec plusieurs schedulers, une base PostgreSQL managée et un executor adapté (Celery ou Kubernetes). Garantir haute disponibilité et tolérance aux pannes. Livrable attendu : Proposer une architecture Airflow HA détaillant composants, base de données, executor et mécanismes de résilience.

Contexte : Les incidents sur les pipelines sont détectés tardivement et les causes sont difficiles à identifier. Le Problème : Aucun système centralisé d’observabilité n’est en place. Contraintes : Intégrer métriques Airflow (Prometheus ou équivalent). Centraliser logs. Mettre en place alertes proactives. Livrable attendu : Proposer une architecture complète de monitoring et d’observabilité permettant une supervision avancée d’Airflow en production.

Contexte : Des centaines de DAGs sont déployés et exécutés quotidiennement. Le Problème : Le scheduler devient lent et accumule du retard dans la planification des tâches. Symptôme : Temps élevé dans le parsing des DAGs et files d’attente saturées. Contraintes : Optimiser le parsing des DAGs. Réduire la complexité des imports. Ajuster dag_dir_list_interval et max_active_runs. Livrable attendu : Proposer une stratégie d’optimisation du scheduler permettant de gérer un grand nombre de DAGs efficacement.

Contexte : La base de données metadata Airflow devient volumineuse et ralentit l’interface web. Le Problème : Les logs et anciennes exécutions ne sont jamais purgés. Symptôme : Temps de réponse élevés et tables volumineuses. Contraintes : Mettre en place une stratégie de nettoyage automatisé. Optimiser les index. Maintenir l’intégrité des historiques nécessaires. Livrable attendu : Proposer une stratégie de maintenance et d’optimisation de la base metadata.

Contexte : Plusieurs DAGs utilisent ExternalTaskSensor pour dépendre les uns des autres. Le Problème : Une dépendance circulaire implicite provoque un blocage permanent des exécutions. Symptôme : Les DAGs restent en état waiting sans progression. Contraintes : Identifier la dépendance circulaire. Redéfinir le flux global. Maintenir la logique métier. Livrable attendu : Proposer une refonte des dépendances inter-DAG éliminant tout risque de deadlock.

Contexte : Certaines tâches restent en état running alors qu’elles ont échoué ou que le worker a crashé. Le Problème : Des tasks zombies perturbent la planification globale. Contraintes : Analyser les heartbeats. Ajuster les paramètres scheduler_zombie_task_threshold. Garantir la détection et le nettoyage automatique. Livrable attendu : Proposer une stratégie de gestion des tâches zombies assurant la stabilité du système.

Contexte : L’organisation dispose d’environnements dev, staging et prod avec des exigences de séparation stricte. Le Problème : Les variables, connexions et DAGs sont partagés de manière non contrôlée entre environnements. Contraintes : Séparer les environnements via configurations distinctes. Utiliser un backend sécurisé pour les secrets (Vault ou équivalent). Garantir isolation et conformité. Livrable attendu : Proposer une architecture multi-environnements sécurisée incluant gestion des secrets et isolation des configurations.

Contexte : Plusieurs équipes utilisent la même instance Airflow en production. Le Problème : Tous les utilisateurs ont accès à l’ensemble des DAGs et paramètres sensibles. Contraintes : Configurer RBAC avancé. Définir des rôles personnalisés par équipe. Restreindre l’accès aux DAGs et connexions. Livrable attendu : Proposer une configuration RBAC complète garantissant isolation et sécurité multi-équipes.

Contexte : Les pipelines nécessitent une scalabilité dynamique selon la charge. Le Problème : Les workers actuels sont fixes et limitent la capacité d’exécution. Contraintes : Migrer vers KubernetesExecutor. Définir des ressources CPU et mémoire adaptées par tâche. Maintenir la stabilité des exécutions critiques. Livrable attendu : Proposer une architecture KubernetesExecutor permettant scalabilité automatique et isolation des workloads.

Contexte : Plusieurs tâches consomment des ressources externes limitées (API, base de données). Le Problème : Des appels simultanés excessifs provoquent des erreurs côté système externe. Contraintes : Mettre en place des pools Airflow. Définir des limites précises par ressource. Éviter tout dépassement de capacité. Livrable attendu : Proposer une configuration avancée de pools permettant un contrôle fin des accès aux ressources externes.