Apache Airflow est une plateforme d'orchestration de flux de travail open source qui définit les dépendances des tâches et la logique de planification via Python DAG. Il est largement utilisé dans les pipelines de données, les pipelines ML et l'automatisation de l'infrastructure cloud.

ApacheAirflow

Paramètres et statistiques de base

Apache Airflow n'est pas un « outil d'IA », mais l'infrastructure du pipeline de données d'IA : il est chargé d'orchestrer les dépendances et de planifier la logique de tâches telles que la formation de modèles, le nettoyage des données, l'ingénierie des fonctionnalités et le déploiement de modèles. Il s’agit de la couche la plus facilement négligée mais la plus critique du système de production d’IA. Airflow a été créé par Airbnb en 2014. Il est entré dans l'Incubateur Apache en 2016 et a obtenu son diplôme de projet de haut niveau en 2019. Il s'agit toujours de la plateforme d'orchestration de flux de travail la plus utilisée dans le domaine de l'ingénierie des données.

Projets	Informations publiques
Positionnement officiel	Plateforme d'orchestration de flux de travail open source
Paradigme de base	Graphe dirigé (DAG), défini en code Python
Moteur de planification	Planificateur distribué + exécuteur (Celery, Kubernetes, CeleryKubernetes, Local, Sequential)
Formulaire de déploiement	Service cloud géré auto-hébergé (machine unique/cluster) (Amazon MWAA, Google Cloud Composer, Astronomer)
Licence Open Source	Apache2.0
Taille de la communauté	GitHub environ 39 000+ étoiles, 2 000+ forks, 800+ contributeurs
Écosystème de fournisseurs	Plus de 100 fournisseurs officiels + des centaines de fournisseurs communautaires, couvrant AWS/GCP/Azure/Snowflake/Databricks/Spark, etc.
Langue de base	Python
Moteur de base de données	PostgreSQL, MySQL, SQLite (pour le développement)
File d'attente des messages	Redis/LapinMQ

Statut de l'industrie : le paradigme DAG-as-Code d'Airflow est devenu la norme de facto pour l'orchestration des flux de travail. Les trois principaux fournisseurs de cloud AWS, GCP et Azure fournissent tous des services Airflow gérés, et Astronomer fournit une plate-forme de gestion multi-locataires au niveau de l'entreprise. Dans le panorama cloud natif de la CNCF, Airflow est répertorié comme projet de référence dans le domaine du workflow et de la planification.

Reconnaissance des utilisateurs et du marché

La position d'Airflow sur le marché peut être observée sous trois dimensions : l'activité de la communauté, l'adoption par les entreprises et l'investissement des fournisseurs de cloud.

Activité communautaire : Airflow compte environ 39 000 étoiles, plus de 2 000 forks et plus de 800 contributeurs actifs sur GitHub. Il s'agit de la plus grande communauté parmi les outils d'orchestration de flux de travail open source. Chaque version majeure (telle que 2.0, 2.9, 2.10) déclenchera un pic de contributions de la communauté. La chaîne Slack d'Airflow compte des dizaines de milliers d'utilisateurs enregistrés, et il existe chaque mois des centaines de fils de discussion sur l'utilisation du fournisseur d'écriture DAG et l'optimisation des performances.

Adoption par les entreprises : Airflow est utilisé dans des environnements de production par des milliers d'entreprises à travers le monde, couvrant des secteurs verticaux tels que la finance, le commerce électronique, la technologie, les soins médicaux et la fabrication. Les utilisateurs connus incluent Airbnb (à l'origine), Twitter/Lyft/Slack (les premiers utilisateurs), Walmart, JPMorgan Chase, Adobe, Intuit et d'autres. Sur le marché chinois, des sociétés Internet de premier plan telles que ByteDance, Alibaba et Meituan ont déployé Airflow ou ses propres dérivés à grande échelle. Les données divulguées par Airbnb en 2021 montrent que son cluster Airflow exécute plus de 500 000 tâches chaque jour.

Investissement des fournisseurs de cloud : Amazon MWAA (Managed Workflows for Apache Airflow) a continué d'étendre les zones et les fonctions disponibles depuis GA en 2021. Google Cloud Composer est le produit principal pour l'orchestration native des pipelines de données de GCP, et Data Factory d'Azure fournit également l'intégration Airflow intégrée. L'investissement en hébergement des trois principaux fournisseurs de cloud confirme la position irremplaçable d'Airflow dans le domaine de l'orchestration des pipelines de données.

Avantage de coût

La structure de coûts d'Airflow est différente de celle des outils SaaS commerciaux et doit être décomposée en trois niveaux : « coût de la licence open source + coût d'exploitation et de maintenance auto-hébergé + coût d'achat de services gérés ».

Utilisateurs individuels/côté C : aucun coût de licence, mais le seuil matériel existe. Airflow Community Edition est entièrement gratuit, sans restrictions de fonctions ni fermetures de compte. Les particuliers peuvent lancer Airflow via Docker Compose ou le contexte virtuel Python sur leurs ordinateurs portables pour l'apprentissage ou de petits pipelines de données. Cependant, lorsqu'il s'agit d'un DAG à grande échelle ou d'une planification à haute concurrence, le backend SQLite et l'exécuteur séquentiel déployés sur une seule machine exposeront rapidement des goulots d'étranglement en termes de performances.

Développeurs/Équipes : Auto-hébergé sans licence, les coûts d'exploitation et de maintenance s'accumulent étape par étape. L'auto-hébergement de niveau production nécessite un déploiement :

• Métadonnées (PostgreSQL/MySQL) - Le coût annuel de la base de données cloud est d'environ 1 200 à 6 000 yuans (selon les spécifications)
• File d'attente de messages (Redis/RabbitMQ) - environ 600 à 3 000 yuans/an
• Planificateur + nœuds de travail (Kubernetes Pod ou EC2) - 5 à 50 unités, frais mensuels de 3 000 à 30 000 yuans
• Stockage et surveillance des journaux (S3/GCS + CloudWatch/Prometheus) - Flottant en fonction du volume de données

Entreprise/Privatisé : coût des services gérés par rapport au coût total de l'auto-exploitation et de la maintenance. La comparaison des services d'hébergement grand public est la suivante (les prix suivants sont des références publiques, qui sont soumises aux pages en temps réel de chaque fournisseur de services) :

Comparaison	Amazon MWAA	Google Cloud Composer	Astronome	Auto-hébergé (cluster K8s)
Modèle de tarification	Frais de périphérique + heure Worker vCPU	Frais de périphérique + heure Worker vCPU	Abonnement (par nœud ou par utilisateur)	Par utilisation réelle de l'infrastructure + main d'œuvre d'exploitation et de maintenance
Tarif mensuel connecté à petite échelle (estimation)	~3 000 à 8 000 yuans	~2 500 à 7 000 yuans	Non divulgué	~2 000 à 5 000 yuans (ressources cloud uniquement)
Forfait mensuel bordé de taille moyenne (estimation)	~10 000 à 30 000 yuans	~8 000 à 25 000 yuans	Confirmation commerciale requise	~8 000 à 20 000 yuans (y compris l'exploitation et la maintenance)
Main d'œuvre d'exploitation et de maintenance	Partage des fournisseurs de cloud	Partage des fournisseurs de cloud	Fournisseur de plateforme entièrement géré	Au moins 0,5 à 1 ETP
Scénarios applicables	Intégration approfondie AWS	Intégration profonde de GCP	Gouvernance multi-cloud/multi-tenant/entreprise	Isolement de la conformité/degré élevé de personnalisation

Conseil sur les coûts cachés :

• Le débogage et l'inspection du DAG prennent du temps : le lien de débogage d'Airflow (échec de l'analyse → réanalyse du planificateur → exécution du travailleur → traçage du journal) peut prendre 15 à 60 minutes pour chaque débogage dans un scénario DAG à grande échelle. Il s’agit du coût caché que les équipes peuvent le plus facilement sous-estimer.
• Coût de migration : lors de la migration d'un service auto-hébergé vers un service hébergé ou vice versa, le code DAG lui-même est portable, mais la migration des informations d'identification du connecteur, des variables de contexte, des métadonnées historiques et des journaux nécessite un travail supplémentaire.

Fonctions principales

Le système fonctionnel d'Airflow s'articule autour des quatre sections « Définition → Planification → Surveillance → Extension ». Sa valeur fondamentale n’est pas une fonction unique, mais la synergie entre ces fonctions.

• Définition DAG (Python-as-Code) : Utilisez le code Python standard pour déclarer les tâches (Opérateurs), les dépendances (>> / << / set_upstream) et les stratégies d'exécution (nombre de tentatives, délais d'attente, files d'attente). Effet de synergie : le code DAG est naturellement contrôlé en version (Git), testable (pytest-airflow) et réutilisable (gestion personnalisée des packages Operator), ce qui résout le problème principal des outils d'orchestration graphique traditionnels de "ne pas savoir qui a changé quoi et être incapable de CR après avoir apporté des modifications".

• Moteur de planification (Timed + Event + Sensor) : prend en charge le déclenchement du timing d'expression Cron et prend également en charge le capteur de données en attente que les données en amont soient prêtes, le capteur de tâches externe dans le DAG, l'attente que le capteur de fichiers surveille l'atterrissage du fichier, etc. Effet de synergie : le capteur et le planificateur peuvent détecter en continu les conditions externes sans consommer les ressources du travailleur. Lorsque les conditions sont remplies, les tâches en aval sont automatiquement déclenchées - cela élimine l'inspection manuelle dans le lien entièrement automatique "attendre l'arrivée des données → démarrer le pipeline → le reporting est terminé".

• UI Web et observabilité : visualisez l'état d'exécution du DAG, le diagramme de Gantt des tâches, la tendance de la durée des tâches, la vue Grille et le lignage au niveau des tâches. Synergie : le diagramme de Gantt expose intuitivement les tâches goulot d'étranglement, l'analyse de lignage aide à localiser la source des problèmes de qualité des données et la vue en grille affiche la répartition de l'état de chaque DAG exécuté par date d'exécution - la combinaison de ces trois éléments permet au personnel d'exploitation et de maintenance de localiser « quelle étape d'une tâche ralentit dans quelle fenêtre de temps » sans avoir à lire les journaux un par un.

• Écosystème de fournisseurs (plus de 100 connecteurs) : le fournisseur officiel couvre AWS (S3, EMR, Lambda, Redshift, SageMaker), GCP (BigQuery, Cloud Storage, Dataflow, Vertex AI), Azure (Blob, Data Lake, Synapse), Snowflake, Databricks, Spark, Kubernetes, Docker, Slack, PagerDuty, etc. Synergie : plusieurs fournisseurs peuvent être connectés en série dans le même DAG - par exemple, lire les données de Snowflake → Le cluster Spark effectue la conversion → écrire dans GCS → déclencher Dataflow pour une analyse ultérieure. Il n'est pas nécessaire d'écrire du code d'appel API dans l'ensemble du processus, il suffit de déclarer l'opérateur correspondant dans le DAG.

• Architecture extensible (Opérateur + Hook + Exécuteur) :

  • Operator : définit « que faire » (par exemple, « PythonOperator » exécute les fonctions Python, « BashOperator » exécute les commandes Shell)
  • Hook : encapsule les détails de connexion des services externes (tels que « S3Hook » pour gérer automatiquement les informations d'identification et les tentatives AWS)
  • Exécuteur : décidez "comment exécuter" (Séquentiel → série locale, Local → parallèle local, Céleri → file d'attente distribuée, KubernetesExecutor → Pod indépendant par tâche)
  • Synergie : le découplage hiérarchique des trois permet à Airflow d'utiliser SequentialExecutor dans un contexte de développement et de passer de manière transparente à CeleryExecutor ou KubernetesExecutor en production sans modifier le code DAG - il s'agit de la capacité d'extension "zéro changement de code" d'Airflow depuis l'expérimentation de tâches autonomes jusqu'à la planification à haute concurrence au niveau de la production.

Evolution du modèle et de la version

En tant que projet open source, les itérations de versions d'Airflow reflètent l'évolution des exigences d'orchestration des flux de travail d'ingénierie des données, de la « planification de scripts » au « pipeline natif cloud + IA ».

ère 1.x (2015-2020) : établir le paradigme DAG

• Airflow 1.0 (2015) : Développés au sein d'Airbnb par Maxime Beauchemin, les concepts fondamentaux de DAG, Opérateur et Planificateur sont tous établis.
• Airflow 1.8 (2018) : Présentation de SubDAG et BranchOperator pour améliorer les capacités de réutilisation des DAG. Il s'agit de l'une des versions 1.x les plus utilisées par la communauté.
• Airflow 1.10 (2019-2020) : entrée dans la première version majeure après l'obtention du diplôme d'Apache, ajout de "KubernetesPodOperator", stabilisation de l'API REST, amélioration du stockage des journaux et de l'interface utilisateur. La série 1.10 continue de se répéter jusqu'à la version 1.10.15.

Ère 2.x (2020 à aujourd'hui) : reconstruction de l'architecture et cloud natif

• Airflow 2.0 (2020-12) : version marquante. Réécriture du planificateur (prenant en charge la haute disponibilité HA), introduction de « l'API TaskFlow » (simplifiant l'écriture du DAG) et prise en charge native de Kubernetes Executor. Le chemin de migration de la version 1.10 vers la version 2.0 nécessite une adaptation manuelle.
• Airflow 2.1-2.2 (2021) : présentation de la vue grille (remplaçant l'ancienne vue arborescente), de l'enregistrement automatique du DAG et de la prise en charge des groupes de tâches. Changement clé : Grid View résout le goulot d'étranglement des performances de visualisation dans des milliers de scénarios d'exécution DAG.
• Airflow 2.3-2.4 (2022) : prise en charge de la génération dynamique de DAG, performances améliorées du planificateur (réduction de plus de 50 % du temps d'analyse), séparation des packages Provider des packages principaux. Changements clés : le découplage des fournisseurs réduit les conflits de dépendances dans les packages de base et chaque fournisseur peut itérer indépendamment.
• Airflow 2.5-2.6 (2023) : gestion des versions DAG, journaux d'audit, prise en charge améliorée des tâches parallèles de la matrice de décorateur @task.
• Airflow 2.7-2.8 (2024) : mécanisme de battement de coeur du planificateur amélioré, optimisation du pool de connexions à la base de données, prise en charge du mode sombre de l'interface Web Python 3.12.
• Airflow 2.9 (2025-12) : planification DAG basée sur des ensembles de données - la planification dépendante basée sur la sortie des données remplace la planification temporelle pure, ce qui est une étape clé pour réaliser de « véritables pipelines de données basés sur des événements ». Le streaming des journaux au niveau des tâches a également été amélioré.
• Airflow 2.10 (2026-05) : La dernière version stable (pas encore de date officielle précise). Concentrez-vous sur l'optimisation de la pression de la base de données de métadonnées du planificateur dans les scénarios DAG à grande échelle (10 000+ DAG), sur l'interface de gestion des actifs/ensembles de données améliorée et sur l'amélioration de la vitesse de démarrage du pod KubernetesExecutor.

Aperçu rapide de l'historique des versions

Série de versions	Temps	Changements clés	Remarques
1.0-1.10	2015-2020	Paradigme DAG établi, accumulation communautaire	1.10.15 est la version finale de 1.x
2.0	2020-12	Planificateur HA, API TaskFlow, prise en charge native de K8s Executor	Jalon de la reconstruction de l'architecture
2.1-2.4	2021-2022	Vue grille, découplage des fournisseurs, DAG dynamique, optimisation des performances du planificateur	Observabilité et expansion écologique
2,5-2,8	2023-2024	Contrôle de version DAG, journal d'audit Python 3.12, améliorations de l'interface utilisateur	Achèvement de la fonction de gouvernance d'entreprise
2.9	2025-12	Planification basée sur des ensembles de données, diffusion de journaux	Compléments clés à l'orchestration événementielle
2.10	2026-05	Optimisation des performances DAG à grande échelle et amélioration de la gestion des actifs	Dernière version stable

Avantages techniques

Airflow a su maintenir sa domination dans le domaine de l'orchestration des workflows depuis dix ans. Son avantage technique ne réside pas dans le « leadership d'une fonction unique », mais dans la rationalité à long terme des décisions au niveau du système telles que la superposition de l'architecture et la conception du planificateur, l'analyse DAG et la séparation des exécutions.

Séparation complète de l'analyse et de l'exécution du DAG : il s'agit de la décision architecturale principale d'Airflow. Le planificateur est chargé d'analyser régulièrement les fichiers Python pour générer des objets DAG (analyse statique), et l'exécuteur est responsable de la distribution des tâches du DAG aux travailleurs pour exécution. Les deux communiquent via la métabase et le planificateur ne contient pas le contexte d'exécution du Worker. Cela signifie :

• Même si le nœud Worker tombe en panne, le planificateur peut replanifier des tâches sur le nouveau Worker.
• Une fois le code DAG mis à jour, le planificateur réanalysera automatiquement et prendra effet sans redémarrer le service.
• Différentes tâches du même DAG peuvent s'exécuter dans différents contextes de travail (pod Kubernetes, conteneur Celery Remote EMR, etc.)

Scheduler HA et analyseur intelligent : le planificateur d'Airflow 2.0+ prend en charge le déploiement haute disponibilité multicopie, et le mécanisme de verrouillage de la base de données garantit qu'il n'y a qu'un seul planificateur actif en même temps. Son analyseur DAG introduit la mise en cache du temps de modification des fichiers et l'analyse incrémentielle dans la version 2.4+ - réanalysant uniquement les fichiers DAG qui ont changé depuis la dernière analyse, compressant le temps d'analyse de plus de 10 000 DAG de quelques minutes à des dizaines de secondes.

Superposition à grain fin d'Executor :

• SequentialExecutor : Pour le développement et le débogage, exécution en série, à l'aide du backend SQLite.
• LocalExecutor : une seule machine exécute des tâches en parallèle, à l'aide d'un pool multi-processus, adapté à la production à petite échelle.
• CeleryExecutor : implémente un pool de travailleurs distribué via Celery + Redis/RabbitMQ, adapté à une échelle moyenne (des centaines à des milliers de tâches/jour).
• CeleryKubernetesExecutor : un exécuteur hybride qui utilise Celery Worker comme épine dorsale et achemine certaines tâches vers des pods Kubernetes pour une meilleure isolation.
• KubernetesExecutor : chaque instance de tâche démarre un pod indépendant et est automatiquement détruite après exécution. Il offre la plus forte isolation des ressources et convient aux tâches de formation ML qui nécessitent un contrôle précis des ressources (CPU/Mémoire/GPU).

Gestion des packages du fournisseur et découplage des versions : Airflow séparera le fournisseur du package principal dans la version 2.3. Chaque fournisseur possède un numéro de version et un cycle de publication indépendants. Cela signifie :

• Les utilisateurs doivent uniquement installer les fournisseurs dont ils ont besoin (« apache-airflow-providers-aws », etc.) pour éviter l'explosion des dépendances
• Les mises à jour du fournisseur ne bloquent pas l'itération de la version principale d'Airflow
• Le fournisseur communautaire peut être libéré indépendamment sans fusionner avec le tronc

Planification basée sur les ensembles de données (ensemble de données) : le mécanisme d'ensemble de données introduit dans la version 2.9+ ne s'appuie pas sur le temps mais s'appuie sur "si les données sont prêtes" pour déclencher des tâches en aval. Lorsqu'une tâche produit un ensemble de données (déclaré via « outlets ), Airflow déclenche automatiquement tous les DAG en aval qui dépendent de cet ensemble de données. Il s'agit de la fonctionnalité clé qui fait passer Airflow d'un « planificateur horaire » à un « planificateur de données » : le pipeline de données réalise véritablement une automatisation du streaming « déclenchée par la sortie ».

Comment utiliser

Le parcours d'utilisation d'Airflow est divisé en trois étapes : mise en place du DAG, écriture, déploiement et exploitation. Chaque étape comporte des choix technologiques clés clairs.

Construction contextuelle (trois solutions typiques)

Comment utiliser	Étape applicable	Commande/opération	Descriptif
Docker Compose (exemple officiel)	Développement/apprentissage local	curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.10.0/docker-compose.yaml' && mkdir -p ./dags ./logs ./plugins && docker-compose up	Démarrage en un clic, y compris planificateur, travailleur, serveur Web et base de données
installation de pips	Vous disposez déjà d'un environnement Python	pip install apache-airflow puis exécutez airflow db init && airflow webserver && airflow planificateur	Flexible mais devez gérer vous-même les dépendances
Tableau de barre (production K8)	Déploiement en production	helm repo ajouter apache-airflow https://airflow.apache.org && helm installer airflow apache-airflow/airflow	Tableau de barre officiel, prend en charge K8sExecutor, CeleryExecutor

Exemple d'écriture DAG

Voici un DAG de pipeline de données d'IA typique qui comprend l'extraction, la transformation, le chargement et la formation de données :

à partir de dateheure importer dateheure
à partir de l'importation du flux d'air DAG
depuis airflow.operators.python importer PythonOperator
depuis airflow.providers.amazon.aws.hooks.s3 importer S3Hook
à partir de airflow.providers.snowflake.operators.snowflake importation SnowflakeOperator

par défaut_args = {
    "propriétaire": "data_team",
    "depends_on_past" : Faux,
    "nouvelles tentatives": 2,
    "retry_delay": timedelta(minutes=5),
}

avec DAG(
    dag_id="ai_training_pipeline",
    start_date=datetime(2026, 1, 1),
    planning_interval="@daily",
    rattrapage=Faux,
    tags=["ai", "formation"],
    default_args=default_args,
) comme jour :

    extract_raw_data = SnowflakeOperator (
        task_id="extrait_raw_data",
        sql="SELECT * FROM raw_events WHERE dt = '{{ ds }}'",
        snowflake_conn_id="snowflake_prod",
    )

    def transform_data(**contexte) :
        # Nettoyage des données et logique d'ingénierie des fonctionnalités
        df = contexte["task_instance"].xcom_pull(task_ids="extract_raw_data")
        transformé = df.dropna().pipe(engineer_features)
        retourner transformé.to_json()

    transform_task = PythonOperator (
        task_id="transform_data",
        python_callable=transform_data,
    )

    upload_to_s3 = PythonOperator(
        task_id="upload_to_s3",
        python_callable=lambda : S3Hook(aws_conn_id="aws_prod")
            .load_string(
                string_data="{{ ti.xcom_pull(task_ids='transform_data') }}",
                key="training/{{ ds }}/features.json",
                bucket_name="ml-features",
            ),
    )

    trigger_training = BashOperator (
        task_id="trigger_training_job",
        bash_command="aws sagemaker create-training-job --region us-east-1 ...",
    )

    extract_raw_data >> transform_task >> upload_to_s3 >> trigger_training

Notes clés :

• xcom_pull / xcom_push est utilisé pour transférer de petites quantités de données entre les tâches (recommandé <100 Ko)
• schedule_interval prend en charge @daily, @hourly, les expressions Cron et les objets Dataset
• Les transferts de fichiers volumineux doivent utiliser un stockage externe tel que S3/GCS et éviter de passer par la métabase Airflow

Configuration des clés pour le déploiement en production

# configuration de la clé docker-compose.yaml
x-airflow-commun :
  &débit d'air commun
  image : apache/airflow : 2.10.0
  environnement :
    AIRFLOW__CORE__EXECUTOR : CeleryExecutor
    AIRFLOW__CORE__SQL_ALCHEMY_CONN : postgresql+psycopg2://airflow:airflow@postgres/airflow
    AIRFLOW__CELERY__RESULT_BACKEND : db+postgresql://airflow:airflow@postgres/airflow
    AIRFLOW__CELERY__BROKER_URL : redis://:@redis:6379/0
    AIRFLOW__SCHEDULER__DAG_DIR_LIST_INTERVAL : 30
    AIRFLOW__CORE__PARALLELISME : 128
    AIRFLOW__CORE__DAG_CONCURRENCY : 16

Prix des produits

La tarification d'Airflow est divisée en deux dimensions orthogonales : les services entièrement open source et les services gérés. Les deux ne sont pas des substituts, mais un choix entre « l'exploitation et la maintenance propres ou l'exploitation et la maintenance externalisées ».

Community Edition (entièrement gratuite) : licence Apache 2.0, pas d'émasculation de fonctionnalités, pas de limite d'utilisateurs, pas de limite d'utilisation commerciale. Toute organisation peut librement le télécharger, le modifier, le déployer et l’utiliser commercialement. Il s’agit du plus grand avantage tarifaire d’Airflow : zéro frais de licence.

Coût réel de l'auto-hébergement (en années) :

• À petite échelle (individuel/petite équipe, <50 DAG/jour) : les frais mensuels du serveur cloud sont d'environ 200 à 800 yuans et le coût annuel total est d'environ 2 400 à 10 000 yuans.
• Échelle moyenne (équipe, 200 à 500 DAG/jour) : 3 à 5 nœuds de travail + base de données gérée + file d'attente de messages, les frais mensuels sont d'environ 5 000 à 15 000 yuans, le coût annuel est d'environ 60 000 à 180 000 yuans.
• À grande échelle (niveau entreprise, plus de 1 000 DAG/jour, haute disponibilité) : cluster K8s (10 à 30 pods) + base de données haute disponibilité + Redis Sentinel, les frais mensuels sont d'environ 20 000 à 60 000 yuans, le coût annuel est d'environ 240 000 à 720 000 yuans et au moins 0,5 à 1 ETP d'exploitation et de maintenance sont requis.

Référence des coûts du service hébergé :

• Amazon MWAA : il y a des frais de frontière (à partir d'environ 1 400 yuans/mois) + des frais horaires Worker vCPU. Convient aux entreprises déjà présentes dans l'écosystème AWS.
• Google Cloud Composer : il y a des frais de frontière (à partir d'environ 1 200 yuans/mois) + des frais de travailleur. Convient aux entreprises déjà présentes dans l'écosystème GCP.
• Astronomer : basé sur un abonnement, facturé en fonction du nombre de nœuds ou d'utilisateurs, offrant une architecture mutualisée, un contrôle d'accès au niveau de l'équipe et des fonctions d'audit de sécurité supplémentaires. Les prix spécifiques nécessitent une confirmation commerciale.

La valeur fondamentale des services d'hébergement est d'externaliser les travaux d'exploitation et de maintenance tels que la configuration de la haute disponibilité du planificateur, la maintenance des bases de données, les mises à niveau de version, ainsi que la surveillance et l'alarme, auprès de fournisseurs de cloud ou de plates-formes. Pour les petites et moyennes organisations qui ne disposent pas d'une équipe opérationnelle Airflow dédiée, les services gérés sont souvent plus économiques que l'auto-hébergement.

Scénarios d'application

Les scénarios applicables d'Airflow vont bien au-delà de l'ETL traditionnel et jouent un rôle de plus en plus central dans les pipelines de données pilotés par l'IA.

• Orchestration du pipeline de formation AI : il s'agit du scénario à la croissance la plus rapide pour Airflow en 2024-2026. Liens typiques : Collecte de données brutes → Nettoyage et annotation des données → Ingénierie des fonctionnalités → Formation du modèle (SageMaker/Kubernetes/Kubeflow) → Évaluation du modèle → Enregistrement du modèle → Déploiement du modèle (tests A/B). « KubernetesPodOperator » ou « SageMakerOperator » d'Airflow peuvent lancer directement des tâches de formation GPU dans le DAG et recycler automatiquement les ressources une fois la formation terminée. Réduction des coûts et amélioration de l'efficacité : dans les méthodes traditionnelles, les ingénieurs ML organisent manuellement les étapes de formation, vérifient les résultats intermédiaires et déclenchent l'étape suivante. Il faut environ 30 à 60 minutes d’opération manuelle pour démarrer un seul pipeline de formation. Après la connexion à Airflow, le pipeline est déclenché et exécuté de manière entièrement automatique, et une intervention manuelle n'est requise que lorsque les résultats de l'évaluation du modèle sont anormaux. La durée d'un seul pipeline est compressée à 5 à 10 minutes, ce qui permet d'économiser environ 70 à 80 % du temps d'orchestration.

• Data Lake/Warehouse ETL Pipeline : extrayez les données de plusieurs systèmes sources (base de données OLTP, API SaaS de flux de journaux), agrégez-les et nettoyez-les, puis écrivez-les dans le lac de données (S3/GCS/ADLS) ou l'entrepôt de données (Snowflake/BigQuery/Redshift). Synergie : la combinaison capteur + fournisseur d'Airflow peut implémenter un pipeline en temps réel qui "déclenche l'extraction lorsque les données arrivent" - S3KeySensor surveille l'atterrissage du fichier → S3ToSnowflakeOperator déclenche le chargement → SnowflakeOperator effectue la conversion → SlackWebhookOperator informe l'équipe de données. Conseils de mise en œuvre : dans les scénarios cross-cloud, vous devez faire attention à la compatibilité de la version du fournisseur et de chaque SDK cloud. Il est recommandé d'ajouter des tests d'intégration multi-fournisseurs dans CI.

• Infrastructure cloud et automatisation DevOps : orchestrez la création de ressources multi-cloud, la construction d'images AMI, la migration de bases de données, la rotation des certificats, l'inspection de conformité et d'autres processus d'exploitation et de maintenance. Limite de collaboration homme-machine : la création de l'infrastructure, la vérification de la configuration, la confirmation de l'état et d'autres étapes peuvent être 100 % automatisées ; cependant, pour les opérations impliquant une restauration limitée à la production, des modifications du schéma de base de données, l'approbation des autorisations et d'autres opérations, des points de confirmation manuelle doivent être configurés (BranchPythonOperator ou au niveau de la tâche trigger_rule="none_failed" en conjonction avec la tâche d'approbation manuelle). Airflow fournit AirflowSkipException et DagRunState.FAILED et d'autres mécanismes pour gérer les chemins d'approbation et de rejet.

• Rapport BI et fonctionnement des produits de données : Extrayez automatiquement les données commerciales quotidiennement/hebdomadairement → Effectuez le pré-calcul et l'agrégation → Push vers les outils BI (Tableau/Power BI/Metabase) ou l'API du produit de données. Le « BranchPythonOperator » d'Airflow peut déclencher automatiquement le pipeline d'alarme lorsque la qualité des données n'est pas conforme aux normes au lieu de transmettre directement des données sales pour éviter de signaler des accidents.

Ne convient pas aux scénarios : traitement de flux en temps réel (délai de l'ordre de la milliseconde), scripts ponctuels (les frais généraux d'exploitation et de maintenance dépassent les avantages), logique en dehors de la définition pure du DAG (comme l'exécution directe d'une transformation de données dans Airflow épuisera la mémoire Worker).

Personnes concernées

Le public applicable d'Airflow se concentre sur les tâches de traitement de données « en plusieurs étapes, dépendantes et planifiées » et ne convient pas aux scripts en une seule étape ou aux scénarios de traitement de flux en temps réel.

• Équipe d'ingénierie de données (utilisateurs principaux) : L'équipe contient généralement plus de 3 ingénieurs de données et est responsable de la construction, de la maintenance et de la surveillance des pipelines de données au niveau de l'entreprise. Le paradigme DAG-as-Code d'Airflow permet aux pipelines de données d'être révisés, versionnés et testés unitairement, tout comme le code d'application. Ne convient pas aux limites : si l'équipe ne dispose pas de bases Python ou si une seule personne travaille à temps partiel sur le pipeline de données, les coûts d'apprentissage, d'exploitation et de maintenance d'Airflow peuvent dépasser les avantages. Dans ce cas, il est recommandé d'évaluer d'abord Prefect (la courbe d'apprentissage est plus plate) ou l'outil de planification intégré du fournisseur de cloud.

• MLOps/AI Engineer : il est nécessaire d'organiser les multiples étapes de formation, d'évaluation et de déploiement du modèle dans un pipeline automatisé, et de le combiner avec CI/CD pour réaliser la publication automatique du modèle depuis la soumission du code vers les services en ligne. « KubernetesPodOperator » et « SageMakerOperator » d'Airflow peuvent lancer directement des tâches GPU sur le cluster de formation, mais ils nécessitent que l'équipe ait des connaissances de base en matière d'exploitation et de maintenance de K8 ou de SageMaker. Conseils de mise en œuvre : dans les scénarios ML, il est recommandé d'encapsuler la logique de formation du modèle dans une image Docker. Le DAG est uniquement responsable de l'orchestration et du déclenchement, et n'est pas responsable de l'exécution de la gestion des dépendances contextuelles. De cette manière, les mises à niveau du code de formation ne nécessitent pas de modification du DAG.

• Exploitation et maintenance de la plateforme/Équipe de plateforme : fournit une plateforme de planification de tâches unifiée pour plusieurs équipes (ML de données, analyse, entreprise) et doit gérer l'isolement des DAG multi-locataires, les quotas de ressources, l'audit des journaux et les alarmes. Le RBAC (contrôle d'accès basé sur les rôles) d'Airflow a mûri dans la version 2.0+ et peut être connecté à l'authentification unifiée d'entreprise avec LDAP/SSO. Ne convient pas aux limites : si l'organisation dispose déjà d'un système K8s CronJob + Argo Workflows complet et n'a pas d'exigences d'orchestration en plusieurs étapes, l'introduction d'Airflow augmentera la redondance de la chaîne d'outils.

• Analyste de données (adaptation limitée) : affichez l'état d'exécution du cadre DAG existant et effectuez des déclencheurs simples (tels que le remplissage des données historiques). Le travail d'analyse quotidien est toujours basé sur SQL et Notebook, et le DAG n'est pas écrit directement. Il est recommandé que l'équipe d'ingénierie des données encapsule un modèle DAG standard, et les analystes n'ont qu'à renseigner les paramètres pour déclencher l'exécution.

Résumé et Outlook

Apache Airflow a établi une position concurrentielle presque standardisée dans le domaine de l'orchestration des flux de travail grâce à son paradigme DAG-as-Code et son vaste écosystème de fournisseurs. Son principal obstacle n'est pas une fonction unique, mais une combinaison des trois suivantes : Définition DAG versionnable + Écosystème de fournisseurs couvrant les services cloud et de données grand public + Capacités d'expansion transparentes du mode autonome à Kubernetes. Cette combinaison fait d'Airflow une « couche de base » essentielle pour l'ingénierie des données et l'infrastructure d'IA.

Avantages de base actuels :

• L'échelle communautaire et la couverture des fournisseurs dépassent de loin les produits concurrents similaires (Prefect, Dagster, Argo Workflows). Les nouveaux services de données prennent généralement en charge Airflow Provider après leur lancement.
• Capacités flexibles de développement secondaire et de personnalisation - de l'opérateur personnalisé à l'exécuteur personnalisé, les entreprises peuvent avoir un contrôle approfondi sur le comportement de planification.
• L'amélioration des services d'hébergement des fournisseurs de cloud a abaissé le seuil d'utilisation d'Airflow par les petites et moyennes organisations.

Limitations actuelles majeures :

• Les goulots d'étranglement en termes de performances sont évidents lorsque le planificateur s'étend à très grande échelle (10 000+ DAG) - Le temps d'analyse du DAG du pool de connexions de métabase et la concurrence en termes de rythme cardiaque de planification doivent être atténués grâce au partitionnement de la base de données et à la configuration de la planification personnalisée dans les déploiements à grande échelle.
• Il y a encore des frictions dans l'expérience d'écriture et de débogage du DAG - le débogage local s'appuie sur le « test airflow dags » pour simuler l'exécution, et les erreurs de syntaxe Python ne seront exposées que lors de l'analyse du planificateur, ce qui est un niveau plus lent que le mode de développement REPL des scripts Python traditionnels. Nécessite l'aide d'outils tels que pytest-airflow ou community dag-factory.
• Le traitement en temps réel et en flux ne sont pas ses objectifs de conception - L'intervalle de planification minimum d'Airflow est limité à « min_file_process_interval » (généralement 30 secondes) et ne peut pas être utilisé dans des scénarios en temps réel inférieurs à la minute. Pour les tâches de traitement de flux, il est recommandé de collaborer avec Kafka/Flink. Airflow sert uniquement de couche d'orchestration par lots.
• La planification basée sur les ensembles de données est encore en cours de maturation - Le mécanisme Dataset introduit dans la version 2.9+ résout les dépendances de données entre DAG, mais la garantie de cohérence du graphe de planification sous le réseau Dataset à grande échelle et la vérification de la fiabilité du contexte de production nécessitent encore davantage de retours de la communauté.

Comparaison des produits concurrents en un coup d'œil :

Comparer les dimensions	Flux d'air	Préfet	Dague	Flux de travail Argo
Définition Langue	DAG Python	Décorateur Python	Python + Définition des actifs	YAML
Granularité de la planification	Niveau des minutes	Deuxième niveau	Niveau des minutes	Niveau des minutes
Observabilité de l'interface utilisateur	Grille + Gantt + Lignée	Interface utilisateur moderne + chronologie	Diagramme de lignage des actifs	Vue de base du module
Diplôme natif cloud	K8sExecutor + Helm	K8 natif + sans serveur	Dagit + K8	Natif Kubernetes
Gouvernance d'entreprise	RBAC + Journaux d'audit	RBAC + SSO	RBAC + Isolement d'équipe	Héritage RBAC K8s
Communauté et fournisseurs	Plus de 100 fournisseurs	Moins de fournisseurs natifs	Moins de fournisseurs natifs	Aucun fournisseur autonome
Courbe d'apprentissage	Moyen-Élevé (nécessite une compréhension de l'architecture Airflow)	Moyen-bas	Moyen (nécessite une adaptabilité aux concepts d'actifs)	Faible (définition YAML)
Échelle applicable	Tout usage à petite et grande échelle	Moyenne à grande échelle	Moyenne à grande échelle	Petite et moyenne échelle

Évaluation des risques en matière d'approvisionnement et d'adoption :

Pour l'apprentissage individuel et le pilotage en petite équipe, le coût de licence nul d'Airflow et le démarrage en un clic de Docker Compose en font un choix presque sans risque : passer un week-end à configurer l'environnement et à exécuter le didacticiel officiel suffit pour juger s'il répond aux besoins.

Pour les moyennes et grandes organisations, les trois points suivants méritent une évaluation minutieuse avant d’investir :

1. Investissement dans l'exploitation et la maintenance par rapport au choix des services d'hébergement : en mode d'auto-hébergement, au moins 0,5 ETP est requis pour l'exploitation et la maintenance à temps plein (réglage du planificateur, maintenance de la base de données, mise à niveau de version, prise en charge du débogage DAG). Si l'organisation n'a pas d'expérience en matière d'opérations Airflow, il est fortement recommandé de commencer par un service géré (MWAA / Cloud Composer / Astronomer) - les frais d'hébergement sont généralement inférieurs au coût de main-d'œuvre caché de l'auto-hébergement, et le fournisseur de cloud est responsable des mises à niveau de version et de la gestion des pannes d'infrastructure.
2. L'effet de verrouillage de la pile technologique DAG : le code DAG lui-même est portable, mais la migration de la configuration du fournisseur (chaîne de connexion, gestion des informations d'identification) et des dépendances limitées (packages Python, bibliothèques système) entre différentes méthodes de déploiement nécessite des tests et une vérification. Il est recommandé d'utiliser la conteneurisation pour exécuter toutes les tâches DAG dès les premières étapes du projet et d'encapsuler les dépendances contextuelles dans les images Docker afin de réduire les frictions lors des migrations futures.
3. Contraintes d'orchestration GPU dans les scénarios AI/ML : lors de l'organisation des tâches de formation GPU dans Airflow, vous devez vous assurer que le pod de KubernetesExecutor peut demander des ressources GPU et faire attention au mécanisme de nouvelle tentative d'expiration du planificateur qui peut être déclenché par des tâches de formation à long terme (> 12 heures). Il est recommandé de définir execution_timeout et retries=0 pour les tâches de formation à long terme afin d'empêcher le planificateur d'extraire à plusieurs reprises de nouvelles instances lorsque la formation n'est pas terminée.

Informations de version

• Flux d'air 2.10 ：Il n’y a pas encore de date officielle précise. （2026-05）
• Débit d'air 2.9 ：Il n’y a pas encore de date officielle précise. （2025-12）