Toutes les organisations exploitent un orchestrateur. Il est même étonnant d’observer que nombre de clients vont s’appuyer sur un orchestrateurs pour gérer l’ensemble des tâches à exécuter pour tous les systèmes et applications en lieu et place de celui associés à leurs solutions ETL.
De même, les organisations ont un besoin de modernisation, justement de leur orchestrateur, qui ne leur offre pas l’agilité et la flexibilité des nouvelles approches « as code ».
Il y un nombre très important de solutions d’orchestration, y compris en open source. Une solutions qui innove grandement en la matière : Kestra. De nombreuses solutions d’orchestration se compare à Apache Airflow en pointant ses défauts.
A la mi-avril 2025 la version 3.0 de ce projet va voir le jour. Elle apporte des améliorations significatives qui promettent de transformer l’expérience des utilisateurs et d’attirer de nouveaux adeptes.
Performance et architecture repensées
La nouvelle architecture client-serveur d’Airflow 3.0 offre une flexibilité et une scalabilité accrues. Cette refonte permet une exécution fluide sur différents environnements cloud et améliore considérablement les performances globales du système.
Le monitoring des DAGs a été optimisé, offrant une visibilité en temps réel sur l’état des workflows. Le découplage entre l’API et le frontend permet une meilleure réactivité de l’interface utilisateur et facilite les mises à jour indépendantes de ces composants.
La version 3 introduit le Edge Executor ! Il est ainsi possible d’avoir des déploiements très flexibles. L’exécution des tâches est réalisée au plus près des données.
Avec l’introduction des tâches différables, il est déjà possible d’exécuter des workflows asynchrones et de libérer le slot du worker Airflow. Certes, on peut utiliser l’opérateur SSH, mais Airflow ne prenait pas nativement en charge l’exécution de workers sur des machines distantes. Avec Airflow 3.0, tout cela change.
Les workers n’auront plus besoin d’être contenus dans le déploiement Airflow. Airflow fait référence aux workers externes sous le nom d’Edge executors. Cela signifie que plusieurs choses vont changer :
- Les workers ne pourront plus accéder à la base de données Airflow. Par défaut, tous les services Airflow ont accès à la base de données Airflow car elle est responsable du suivi de l’état. En découplant les workers et la base de données Airflow, il devient possible d’exécuter des workers à distance. Ceci est principalement facilité par le nouveau Task SDK.
- Les workers communiqueront via l’API REST d’Airflow. L’authentification des workers externes se fera par le biais de jetons JWT ou ID.
- Les workers ne seront plus liés aux packages Airflow. Il n’y aura plus de dépendance aux packages installés dans l’image fournie avec le déploiement Airflow. Un package distinct sera disponible, beaucoup plus léger que l’image de base d’Airflow. Ce package fournira les outils nécessaires pour exécuter le worker externe.
Versionning des DAGs
Une fonctionnalité très attendue est le versionning natif des DAGs. Les utilisateurs peuvent désormais suivre l’historique des modifications de leurs workflows directement dans l’interface utilisateur. Cette fonction permet de visualiser les changements apportés aux DAGs au fil du temps et de revenir facilement à des versions antérieures si nécessaire.
Des Datasets aux Assets
Airflow 3.0 introduit le concept d’Assets, une évolution des Datasets. Cette approche offre une gestion plus fine des dépendances entre les tâches et les données.
from airflow.decorators import dag, task from airflow.datasets import Dataset input_dataset = Dataset("s3://bucket/input.csv") output_dataset = Dataset("s3://bucket/output.csv") @dag(schedule=[input_dataset]) def process_data(): @task(outlets=[output_dataset]) def transform(): # Logique de transformation return "Data processed" transform() dag = process_data() |
De cette manière, la traçabilité entre jeu de données et traitements (tâche, DAG) est intrinsèque. Vous pourrez tout de suite identifier les jeux de données exploités par un DAG et tous les DAGs qui lisent ou écrivent tels ou tels jeux de données.
SDK multi-langages
Airflow 3.0 étend son support à plusieurs langages de programmation grâce à un nouveau SDK. Les langages de programmation supportés par le nouveau SDK : Python, Java (langages dérivé Scala…), Javascript, TypeScript, Go.
Par exemple, on peut maintenant écrire les DAG en Java.
import io.astronomer.airflow.sdk.DAG; import io.astronomer.airflow.sdk.annotations.DAGTask; import io.astronomer.airflow.sdk.annotations.Workflow; @Workflow( dagId = "java_example", schedule = "0 0 * * *", startDate = "2025-04-01" ) public class JavaExampleDAG extends DAG { @DAGTask public void helloWorld() { System.out.println("Hello from Java DAG!"); } } |
Interface graphique modernisée
L’interface utilisateur d’Airflow 3.0 a été entièrement repensée avec React et FastAPI. Elle offre une expérience plus intuitive et réactive, avec des fonctionnalités telles que :
- Un mode sombre
- Une vue en grille et une vue graphique des DAGs redimensionnables
- Une visualisation améliorée des dépendances entre les assets
- Un accès rapide aux informations clés sur le déploiement Airflow et l’état des services.
Tester Apache Airflow 3 par vous même
L’article a surtout vocation à vous rappeler que la version 3 est bientôt là. Bien sûr toutes les fonctionnalités de cette verion 3 n’ont pas été exhaustivement listées. Et nous vous invitons à le découvrir par vous même. Cette suite de commandes devrait vous aider.
git clone https://github.com/apache/airflow.git cd airflow# Création et activation de l'environnement virtuel (recommandé) python3 -m venv .venv source .venv/bin/activate git checkout v3-0-stable pip install "pipx>=1.4.1" pipx ensurepath pipx install -e ./dev/breeze breeze start-airflow --backend postgres --load-example-dags --dev-mode --db-reset |
Par la suite, ouvrez votre navigateur à la page suivante : http://127.0.0.1:28080.
La participation de tout un chacun est importante. Faites des retours à la communauté.
En attendant la mi-avril
Avec ces améliorations majeures, Apache Airflow 3.0 se positionne comme une solution d’orchestration de workflows encore plus puissant et accessible. Dans un contexte économique où la maîtrise du système d’information est cruciale, cette nouvelle version pourrait attirer de nombreux nouveaux utilisateurs en quête d’un outil flexible, performant et facile à utiliser pour gérer leurs pipelines de données et leurs processus métier. Les utilisateurs de Control-M seraient surpris de la facilité de migration vers Apache Airflow.
Toute l’équipe de Synaltic se tient disponible pour vous aider à découvrir et faire vos premiers pas avec Apache Airflow y compris avec cette nouvelle version.
