Data Integration

Apache Airflow : Orchestrer et industrialiser ses traitements de données

À la suite d'un POC réalisé autour d'Apache Hop, nous avons souhaité aller plus loin en nous intéressant à l'orchestration et à la planification. Apache Hop permet de concevoir et d'exécuter des pipelines et des workflows, mais leur industrialisation nécessite aussi de pouvoir les déclencher automatiquement, gérer leur enchaînement et suivre leur exécution.

C'est dans cette continuité qu'Apache Airflow a été retenu afin d'étudier son utilisation comme ordonnanceur associé à Apache Hop. Un nouveau POC a ainsi été réalisé chez DeciVision pour tester concrètement la complémentarité entre les deux outils et évaluer la manière dont Airflow peut piloter, planifier et superviser les pipelines et workflows développés dans Apache Hop, dans le cadre de nos projets d'intégration de données.

Dans quels cas utiliser Apache Airflow ?

Apache Airflow est un outil open source dédié à l'orchestration de traitements. Son rôle principal est de définir quand les traitements doivent être exécutés, dans quel ordre et comment suivre leur déroulement.

Dans Airflow, les traitements sont organisés sous forme de DAG (Directed Acyclic Graph). Un DAG représente un ensemble de tâches et les dépendances qui existent entre elles. Il peut ensuite être exécuté manuellement ou selon une planification définie.

Airflow permet ainsi de planifier les exécutions, déclencher automatiquement les traitements, gérer leur ordre d'exécution, suivre leur statut depuis une interface Web et consulter l'historique ainsi que les logs associés.

Schéma des cas d'usage d'Apache Airflow : planification récurrente, enchaînement des traitements, gestion des dépendances, suivi centralisé et coordination multi-technologies
Apache Airflow devient pertinent dès que l'exécution des traitements doit être automatisée, enchaînée et supervisée.
Schéma des cas d'usage d'Apache Airflow : planification récurrente, enchaînement des traitements, gestion des dépendances, suivi centralisé et coordination multi-technologies
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Apache Hop et Apache Airflow : deux rôles complémentaires

Apache Hop et Apache Airflow interviennent à des niveaux différents dans la chaîne de traitement des données. Hop porte la logique de transformation, avec la création des pipelines et des workflows, tandis qu'Airflow intervient sur leur orchestration. Dans notre POC, les traitements restent donc entièrement définis dans Apache Hop. Airflow se charge ensuite de déclencher leur exécution via hop-run, selon une planification définie, puis d'en suivre le résultat. Cette séparation permet de conserver la logique métier et les transformations dans l'ETL, tout en confiant à Airflow la gestion de l'exécution et de la supervision.

Schéma d'architecture montrant Apache Airflow orchestrant l'exécution d'un workflow Apache Hop via hop-run, avec sources et destinations de données
Airflow orchestre l'exécution des traitements, Hop porte la logique de transformation.
Schéma d'architecture montrant Apache Airflow orchestrant l'exécution d'un workflow Apache Hop via hop-run, avec sources et destinations de données
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Mise en pratique : piloter un workflow Apache Hop avec Airflow

Pour tester cette complémentarité, nous avons construit dans Apache Hop un workflow composé de deux pipelines exécutés successivement. Le premier réalise un traitement sur les données, tandis que le second réutilise le résultat obtenu pour effectuer un enrichissement.

Une fois le workflow validé dans Hop, celui-ci est appelé depuis Airflow à l'aide de hop-run. Airflow déclenche ainsi une seule exécution, tandis qu'Apache Hop conserve la responsabilité de l'enchaînement des différents pipelines.

Capture d'écran de l'interface Apache Hop montrant le workflow du POC : Start, airflow_with_bdd.hpl, join_airflow.hpl, Success
Workflow Apache Hop utilisé dans le POC
Capture d'écran de l'interface Apache Hop montrant le workflow du POC : Start, airflow_with_bdd.hpl, join_airflow.hpl, Success
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Du déclenchement manuel à la planification automatique

Dans un premier temps, le workflow a été lancé manuellement depuis l'interface Airflow afin de vérifier que l'appel à Apache Hop fonctionnait correctement. Airflow récupère le résultat de l'exécution et considère la tâche comme réussie lorsque hop-run retourne un code 0.

Une planification automatique a ensuite été ajoutée. Pour le POC, le workflow était exécuté toutes les cinq minutes, avec une seule exécution active à la fois afin d'éviter le lancement simultané de plusieurs instances du même traitement.

Superviser les traitements et centraliser les logs

L'un des intérêts d'Apache Airflow est de pouvoir suivre l'exécution des traitements depuis une interface unique. Chaque lancement conserve son statut, son historique ainsi que les logs générés pendant l'exécution.

Capture d'écran de l'interface Apache Airflow affichant le suivi des dernières exécutions du DAG apache_hop_workflow, avec durées et statuts
Suivi des exécutions du workflow Apache Hop depuis l'interface Apache Airflow

Capture d'écran de l'interface Apache Airflow affichant le suivi des dernières exécutions du DAG apache_hop_workflow, avec durées et statuts
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Dans notre POC, les logs produits par hop-run et Apache Hop remontent directement dans Airflow. Il devient ainsi possible de suivre le démarrage du workflow, l'exécution des différents pipelines, le nombre de lignes traitées ou encore les éventuelles erreurs, sans avoir à ouvrir Apache Hop.

Cette centralisation facilite notamment l'identification de l'étape concernée lorsqu'un traitement échoue et apporte une meilleure visibilité sur les différentes exécutions.

Capture d'écran des journaux d'exécution Apache Hop consultés directement dans l'interface Apache Airflow
Consultation des logs Apache Hop directement depuis Apache Airflow
Capture d'écran des journaux d'exécution Apache Hop consultés directement dans l'interface Apache Airflow
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Une orchestration qui ne se limite pas à Apache Hop

Même si notre POC s'est concentré sur l'association entre Apache Airflow et Apache Hop, Airflow n'est pas dépendant d'un ETL en particulier. Son rôle est avant tout de piloter l'exécution de traitements, quel que soit l'outil qui les réalise.

Il peut ainsi orchestrer des scripts Python, des traitements SQL, des commandes système, des conteneurs ou encore des traitements exécutés par d'autres plateformes data. Cette souplesse permet d'utiliser Airflow comme point central d'orchestration dans des architectures data modernisées, composées de plusieurs technologies.

Dans notre cas, Apache Hop constitue donc un exemple d'intégration parmi d'autres, et non une dépendance nécessaire au fonctionnement d'Airflow.

Schéma montrant Apache Airflow orchestrant plusieurs types de traitements : Apache Hop, scripts Python, requêtes SQL, applications cloud, Big Data, API, commandes système et conteneurs
Apache Airflow sert de couche d'orchestration centrale dans une architecture composée de plusieurs technologies.
Schéma montrant Apache Airflow orchestrant plusieurs types de traitements : Apache Hop, scripts Python, requêtes SQL, applications cloud, Big Data, API, commandes système et conteneurs
Molette / pincement pour zoomer · Glisser pour déplacer · Double-clic pour réinitialiser Pincez pour zoomer · Glissez pour déplacer

Point de vigilance

L'utilisation d'Apache Airflow apporte une véritable couche d'orchestration, mais elle implique également un outil supplémentaire à administrer. L'environnement d'exécution d'Airflow doit donc être installé, configuré et maintenu en parallèle des outils qu'il pilote. Dans notre POC, Airflow était par exemple exécuté sous WSL, tandis qu'Apache Hop était installé sous Windows.

La définition et la maintenance des DAG constituent également un point à prendre en compte. Dans notre cas, le déclenchement de Hop repose sur un BashOperator appelant hop-run avec les paramètres du projet, de l'environnement et du workflow à exécuter.

Enfin, la gestion des erreurs et des exécutions concurrentes doit être correctement configurée. Le POC s'appuie notamment sur le code retour de hop-run pour déterminer le statut de la tâche dans Airflow, et sur max_active_runs=1 pour éviter plusieurs exécutions simultanées du même workflow.

À retenir

  • Apache Hop porte la logique de transformation des données, Apache Airflow orchestre, planifie et supervise son exécution
  • Le déclenchement d'un workflow Hop depuis Airflow passe par hop-run : son code retour détermine le statut de la tâche
  • Airflow n'est pas dépendant de Hop : il peut aussi piloter des scripts Python, des requêtes SQL, des conteneurs ou d'autres outils data
  • Ajouter Airflow, c'est ajouter un environnement supplémentaire à installer, configurer et maintenir : à budgéter dans le projet

Conclusion de l'expert DeciVision

Apache Airflow apporte une réponse intéressante aux besoins de planification, d'orchestration et de supervision des traitements de données. Son intérêt réside surtout dans sa capacité à piloter des traitements existants sans avoir à déplacer leur logique dans l'outil d'orchestration.

Le POC réalisé avec Apache Hop a permis de valider cette complémentarité : Hop conserve la logique des pipelines et des workflows, tandis qu'Airflow prend en charge leur déclenchement, leur planification et leur suivi. Cette séparation des rôles permet de conserver une architecture lisible et de faire évoluer plus facilement l'industrialisation des traitements.

Airflow se positionne ainsi comme une couche d'orchestration pertinente dès lors que les traitements doivent être automatisés, enchaînés et supervisés de manière centralisée, à condition d'intégrer dans l'architecture la gestion de son propre environnement d'exécution.

Un projet d'orchestration ou d'industrialisation de vos traitements data ?

Nos consultants Data Integration vous aident à cadrer l'architecture ETL et orchestration adaptée à votre contexte.

Parlons de votre projet

Questions fréquentes

Qu'est-ce qu'Apache Airflow ?

Apache Airflow est un outil open source dédié à l'orchestration de traitements. Il permet de planifier des exécutions, de déclencher automatiquement des traitements, de gérer leur ordre d'exécution et de suivre leur statut et leurs logs depuis une interface Web, via des DAG (Directed Acyclic Graph).

Quelle est la différence entre Apache Hop et Apache Airflow ?

Apache Hop porte la logique de transformation des données : il sert à créer et exécuter des pipelines et des workflows. Apache Airflow, lui, orchestre ces traitements : il les déclenche, les planifie et en suit l'exécution, sans prendre en charge la transformation elle-même.

Comment Apache Airflow déclenche-t-il un workflow Apache Hop ?

Dans le POC réalisé par DeciVision, le déclenchement s'appuie sur un BashOperator Airflow qui appelle la commande hop-run avec les paramètres du projet, de l'environnement et du workflow à exécuter. Airflow considère la tâche réussie lorsque hop-run retourne un code 0.

Apache Airflow peut-il orchestrer autre chose qu'Apache Hop ?

Oui. Airflow n'est pas dépendant d'un ETL en particulier : il peut orchestrer des scripts Python, des traitements SQL, des commandes système, des conteneurs ou des traitements exécutés par d'autres plateformes data.

Quels sont les points de vigilance avant de déployer Apache Airflow ?

Trois points principaux : Airflow est un outil supplémentaire à installer, configurer et maintenir ; la définition et la maintenance des DAG demandent du temps ; et la gestion des erreurs et des exécutions concurrentes, via des paramètres comme max_active_runs, doit être correctement configurée.

Articles récents
Évènements à venir
Prochain webinar
Spécial Collectivités : Cartographier votre patrimoine BI et préparer sa migration
📅 19 novembre 2026 · 11h00–12h00
Découvrir le webinar →
Échange gratuit · 30 min

Discutez avec un expert

Échange de 30 minutes maximum avec un expert pour discuter de votre contexte BI/Data et voir si DeciVision peut répondre à vos besoins.

Prendre rendez-vous

Sans engagement · 30 min maximum

Newsletter DeciVision

Soyez notifiés de nos derniers articles de blog, de nos prochains webinars et nos actualités !