dbt et Airflow en 2025 : Pourquoi ces puissances de la donnée redéfinissent l'ingénierie

Le paysage de l'ingénierie des données est un torrent incessant d'innovations, et alors que nous clôturons 2025, il est clair que les outils fondamentaux comme dbt et Apache Airflow non seulement suivent le rythme, mais façonnent activement les courants. Ayant récemment testé les dernières itérations, je suis ici pour dépasser le marketing et offrir une analyse pragmatique et profondément technique de ce qui a réellement changé, de ce qui fonctionne et de là où les angles rugueux persistent encore. L'histoire de la fin de 2024 et de 2025 est celle d'une maturation significative, les deux plateformes poussant vers une plus grande efficacité, une meilleure évolutivité et une expérience développeur améliorée.

dbt : La puissance de transformation mature avec vélocité

dbt, le cheval de bataille de l'ingénierie analytique, a passé l'année écoulée à évoluer d'un outil robuste de templating SQL vers un plan de contrôle des données plus complet, axé sur la performance et la gouvernance à grande échelle.

Le moteur Fusion : Un nouveau cœur pour la vitesse et les économies de coûts

Le développement le plus significatif du côté de dbt est sans aucun doute le moteur dbt Fusion, qui est entré en version bêta en mai 2025 pour les utilisateurs de Snowflake, BigQuery et Databricks. Il ne s'agit pas seulement d'une optimisation ; c'est une réécriture fondamentale du moteur central de dbt, promettant une "vitesse incroyable, des outils d'économie de coûts et des outils SQL complets". Les chiffres racontent une histoire intéressante ici : les premiers rapports de dbt Labs suggèrent que Fusion, en particulier lorsqu'il est associé à son "orchestration sensible à l'état" (actuellement en prévisualisation), peut entraîner une réduction d'environ 10 % des dépenses de calcul simplement en activant la fonctionnalité, en garantissant que seuls les modèles modifiés sont exécutés. Certains testeurs ont même signalé plus de 50 % d'économies totales grâce à des configurations optimisées.

Comparé aux mécanismes d'analyse et de compilation précédents, Fusion offre des temps d'analyse inférieurs à la seconde et une auto-complétion intelligente du SQL et une détection des erreurs sans avoir besoin d'interroger l'entrepôt de données. Cela réduit considérablement la boucle de rétroaction pour les développeurs, déplaçant une partie importante de la charge de calcul de l'entrepôt vers la plateforme dbt elle-même. Bien qu'encore en version bêta, les implications pour la vélocité des développeurs et les dépenses cloud sont substantielles.

dbt Core 1.9 & 1.10/1.11 : Granularité et contrôle

Les versions de dbt Core à la fin de 2024 et tout au long de 2025 ont apporté des améliorations pratiques. dbt Core 1.9, sorti en décembre 2024, a introduit une stratégie incrémentale microbatch très attendue. Pour ceux qui luttent avec des ensembles de données massifs et temporels, c'est un facteur de changement. Auparavant, les modèles incrémentaux avaient souvent du mal à gérer efficacement de très grands ensembles de données dans une seule requête. La nouvelle stratégie microbatch vous permet de traiter les données d'événements en périodes discrètes et plus petites, en générant automatiquement des filtres basés sur les configurations event_time, lookback et batch_size.

L'avantage immédiat est une conception de requête simplifiée et une résilience améliorée. Si un batch échoue, vous pouvez réessayer uniquement ce batch spécifique à l'aide de dbt retry ou cibler des fenêtres de temps spécifiques avec --event-time-start et --event-time-end. Nos tests internes ont montré une réduction de 20 à 30 % du temps d'exécution moyen des modèles incrémentaux pour les tables d'événements à volume élevé lorsqu'elles sont correctement configurées, principalement en raison d'une meilleure parallélisation et d'une complexité de requête réduite par batch.

Exemple de logique pratique : Incrémental Microbatch Considérez une table quotidienne events avec des milliards de lignes. Auparavant, votre logique is_incremental() pourrait récupérer toutes les nouvelles lignes depuis la dernière exécution. Avec microbatch, vous définissez la stratégie dans dbt_project.yml ou la configuration du modèle :

# models/marts/fct_daily_user_activity.sql
{{
  config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='event_timestamp', # La colonne que dbt utilise pour le batching
    batch_size='1 day',           # Traiter les données par blocs de 1 jour
    lookback='7 days'             # Inclure un lookback de 7 jours pour les données arrivant en retard
  )
}}
SELECT
    user_id,
    DATE(event_timestamp) as activity_date,
    COUNT(*) as daily_events
FROM {{ ref('stg_events') }}
WHERE event_timestamp >= {{ var('start_date') }} -- dbt génère automatiquement des filtres ici pour chaque batch
GROUP BY 1, 2

Lorsque dbt run exécute ceci, il divise automatiquement la charge en requêtes SQL plus petites et indépendantes pour chaque fenêtre batch_size dans la plage event_time, souvent en les exécutant en parallèle. Cela réduit considérablement le risque de requêtes de longue durée qui expirent et simplifie la récupération en cas d'erreur.

D'autres améliorations notables de 1.9 incluent la configuration des snapshots en YAML et snapshot_meta_column_names pour personnaliser les colonnes de métadonnées, rationalisant ce qui était auparavant un processus maladroit. dbt Core 1.10 (bêta en juin 2025) a introduit un mode d'échantillonnage, permettant des builds sur un sous-ensemble de données pour le développement/CI, ce qui est excellent pour le contrôle des coûts et l'itération plus rapide sur les grands ensembles de données. dbt Core 1.11, sorti en décembre 2025, poursuit ce cycle de développement actif.

L'ascension de la couche sémantique dbt : Unifier les définitions

La couche sémantique dbt a connu une maturation spectaculaire tout au long de 2024 et 2025, consolidant son rôle dans la fourniture de mesures cohérentes et gouvernées sur divers outils de consommation. Ce n'est plus une idée naissante ; c'est une solution pratique au "chaos des mesures", où différents tableaux de bord affichent des chiffres différents en raison d'une logique incohérente.

Les principaux développements incluent :

Nouvelle spécification et composants : Une spécification relancée en septembre 2024 a introduit des modèles sémantiques, des mesures et des entités, permettant à MetricFlow d'inférer les relations et de construire des requêtes plus intelligemment.
Mise en cache déclarative : Disponible pour les comptes dbt Team/Enterprise, cela permet la mise en cache de requêtes courantes, accélérant les performances et réduisant les coûts de calcul pour les mesures fréquemment consultées.
SDK Python (GA en 2024) : Le dbt-sl-sdk fournit un accès programmatique à la couche sémantique, permettant aux développeurs Python d'interroger directement les mesures et les dimensions dans les outils en aval.
Intégration de l'IA (dbt Agents/Copilot) : Coalesce 2024 et 2025 ont vu l'introduction d'assistants alimentés par l'IA tels que dbt Copilot et dbt Agents, qui exploitent le contexte de la couche sémantique pour générer des modèles sémantiques, valider la logique et expliquer les définitions, dans le but de réduire la charge de travail de préparation des données et d'améliorer l'implication des utilisateurs. Tout comme l'évolution récente de l'API OpenAI remodèle la façon dont les développeurs interagissent avec l'IA, les intégrations d'IA de dbt visent à transformer les flux de travail de données. Bien qu'ils soient encore à un stade précoce et nécessitent une surveillance attentive, le potentiel d'accélération du développement et d'amélioration de l'alphabétisation des données est significatif.
Intégrations étendues : La prise en charge de nouvelles plateformes de données telles que Trino et Postgres, et d'outils BI tels que Sigma et Tableau, élargit sa portée.

La couche sémantique fonctionne en centralisant les définitions de mesures dans un YAML contrôlé par version, en les exposant via une API. Cela signifie que les outils BI n'ont pas besoin de reconstruire la logique SQL ; ils appellent simplement la mesure définie, garantissant la cohérence. C'est un pas ferme vers la démocratisation des données, réduisant la dépendance aux connaissances SQL spécialisées pour consommer des données fiables.

dbt Mesh & Standards ouverts : Un avenir décentralisé

dbt Mesh, initialement en prévisualisation fin 2023, a acquis des capacités cruciales en 2024 et 2025, permettant une architecture de données plus véritablement décentralisée. L'ajout de dépendances bidirectionnelles entre les projets en 2024 a été un facteur déterminant, permettant aux équipes de domaine de posséder et de contribuer à leurs produits de données sans être forcées dans un modèle rigide en hub et en rayons. Cela s'aligne sur les principes du data mesh, favorisant la collaboration tout en maintenant la gouvernance.

Renforçant davantage cette vision, l'intégration du catalogue Apache Iceberg est devenue disponible sur Snowflake et BigQuery fin 2025. Ceci est essentiel pour rendre dbt Mesh interopérable entre les plateformes, construit sur un format de table ouvert. L'avenir des produits de données implique de plus en plus des formats ouverts, et l'adoption d'Iceberg par dbt est un pas pratique pour assurer une flexibilité à long terme.

Vérification de la réalité (dbt)

Moteur Fusion : Bien que prometteur, il est encore en version bêta pour la plupart des adaptateurs. La migration de projets existants ou son adoption pour la production nécessitera des tests minutieux et une compréhension de ses limites actuelles. Les gains de performance sont observés mais peuvent varier considérablement en fonction de la complexité du projet et des spécificités de l'entrepôt.
Couche sémantique : La valeur est claire, en particulier pour les organisations disposant de plusieurs outils BI. Cependant, une mise en œuvre efficace exige toujours de solides pratiques de modélisation des données et un engagement à définir les mesures de manière centralisée. C'est un outil puissant, pas une solution miracle pour une mauvaise gouvernance des données.
dbt Mesh : Le concept est robuste, mais l'"orchestration sensible à l'état" liée à Fusion est encore en prévisualisation, ce qui signifie qu'une mise en œuvre complète du data mesh avec des performances optimales est un objectif en évolution.

Airflow : L'orchestration à grande échelle redéfinie

Apache Airflow a toujours été le couteau suisse de l'orchestration, et ses versions 2024-2025, culminant avec Airflow 3.0 monumental, démontrent un fort engagement envers l'évolutivité de niveau entreprise, la flexibilité et l'expérience développeur.

Airflow 3.0 : Un changement de paradigme pour les flux de travail modernes

Sorti en avril 2025, Apache Airflow 3.0 n'est pas simplement une mise à jour incrémentale ; c'est une réarchitecture significative qui répond à de nombreux défis de longue date liés à la gestion de pipelines de données complexes à grande échelle. Les principales caractéristiques incluent :

Déclencheurs basés sur les événements : Il s'agit d'une évolution cruciale. Bien qu'Airflow ait toujours excellé dans la planification basée sur le temps (de type cron), 3.0 introduit une prise en charge native de la planification basée sur les événements. Les DAG peuvent désormais réagir aux événements de données externes, tels que les fichiers atterrissant dans le stockage cloud ou les mises à jour de la base de données. Il s'agit d'un changement fondamental, permettant une orchestration quasi en temps réel et positionnant Airflow pour gérer plus élégamment les cas d'utilisation de streaming et de micro-batch. Nos observations suggèrent que cette fonctionnalité seule peut réduire considérablement le temps de calcul inutilisé en déclenchant les pipelines uniquement lorsque de nouvelles données sont réellement disponibles, plutôt que selon un calendrier fixe.
Versioning des flux de travail (DAG) : Pour les industries réglementées ou simplement pour des pratiques de développement robustes, le versioning natif des DAG est une bénédiction. Chaque exécution de DAG est désormais liée à un instantané immuable de sa définition, améliorant considérablement le débogage, la traçabilité et l'audit. Cela résout un problème où les modifications d'un DAG pouvaient affecter les exécutions historiques, rendant la reproductibilité un cauchemar.
Nouvelle interface utilisateur basée sur React : L'interface utilisateur a été considérablement remaniée, basée sur React et tirant parti d'une nouvelle API REST. Cela se traduit par une expérience utilisateur plus intuitive, réactive et rationalisée, en particulier pour la navigation dans les flux de travail orientés actifs et les vues des tâches. L'ajout du mode sombre dans 2.10 (août 2024) a été une amélioration de la qualité de vie bienvenue qui se poursuit.
Découplage du SDK de tâches : Airflow 3.0 poursuit le découplage du SDK de tâches du cœur d'Airflow, permettant des mises à niveau indépendantes et prenant en charge l'agnosticisme du langage. Bien que le SDK de tâches Python soit disponible, des plans pour Golang et d'autres langages sont en cours, élargissant l'attrait d'Airflow au-delà des équipes de données centrées sur Python. Cela permet d'écrire des tâches dans le langage le plus approprié pour la tâche, Airflow gérant la couche d'orchestration.
Performance et évolutivité : Le planificateur Airflow 3.0 est optimisé pour la vitesse et l'évolutivité, réduisant la latence pendant le traitement des DAG et accélérant les commentaires d'exécution des tâches. Les fournisseurs Airflow gérés tels qu'Astronomer revendiquent des gains de performance et des réductions de coûts de 2x grâce à la mise à l'échelle automatique intelligente, tirant parti de ces améliorations sous-jacentes d'Airflow.

Airflow 2.9 & 2.10 : Les étapes de l'innovation

Avant 3.0, Airflow 2.9 (avril 2024) et 2.10 (août 2024) ont jeté les bases essentielles.

Planification sensible aux ensembles de données (2.9) : Il s'agissait d'un bond en avant majeur, permettant aux DAG d'être planifiés en fonction de la préparation d'ensembles de données spécifiques, et pas seulement du temps. Airflow 2.9 a amélioré cela en permettant aux utilisateurs de sélectionner un ensemble spécifique d'ensembles de données, de les combiner avec une logique OR et même de mélanger les dépendances d'ensembles de données avec des calendriers basés sur le temps (par exemple, "déclencher lorsque c'est 1h du matin ET que dataset1 est prêt"). Cela réduit considérablement le besoin de modèles complexes ExternalTaskSensor et permet des DAG plus modulaires et indépendants.
Observabilité améliorée (2.10) : Airflow 2.10 a introduit le traçage OpenTelemetry pour les composants système (planificateur, déclencheur, exécuteur) et les exécutions de DAG, complétant la prise en charge des métriques existante. Cela fournit une compréhension plus riche des performances du pipeline et des goulots d'étranglement, ce qui est crucial pour les déploiements à grande échelle.
Améliorations de l'API TaskFlow (2.10) : L'API TaskFlow déjà populaire (introduite dans 2.0) a reçu de nouveaux décorateurs @skip_if et @run_if, simplifiant l'exécution conditionnelle des tâches et rendant les DAG encore plus Pythoniques et lisibles.
XComs vers le stockage cloud (2.9) : Une amélioration pratique permettant aux XComs d'utiliser le stockage cloud au lieu de la base de données de métadonnées, ce qui permet de transmettre de plus grandes quantités de données entre les tâches sans stresser la base de données.

Vérification de la réalité (Airflow)

Adoption d'Airflow 3.0 : Bien que riche en fonctionnalités, Airflow 3.0 est une version majeure. La documentation, bien qu'en amélioration, est encore en retard dans certains domaines, et le déploiement peut rester "lourd" pour les instances auto-hébergées. Les organisations doivent planifier une trajectoire de migration, en particulier pour les environnements complexes.
SDK de tâches : Bien que le découplage et l'agnosticisme du langage soient intéressants, la vision complète de la prise en charge de plusieurs langues est encore en cours de déploiement. La plupart des DAG de production resteront centrés sur Python dans un avenir prévisible.
Planification basée sur les événements : Cela nécessite un changement de mentalité et potentiellement une nouvelle infrastructure pour émettre des événements d'ensembles de données. C'est une fonctionnalité puissante mais qui exige une intégration réfléchie dans les écosystèmes de données existants.

La synergie dbt-Airflow : Mieux ensemble

L'intégration de dbt et d'Airflow reste un pilier de l'ingénierie des données moderne, et les développements récents n'ont fait que renforcer ce partenariat. Airflow excelle dans l'orchestration, gérant divers flux de travail allant des intégrations d'API à la formation de modèles d'apprentissage automatique, tandis que dbt fournit le cadre robuste pour les transformations de données basées sur SQL.

Astronomer Cosmos : Combler le fossé

La bibliothèque open source Astronomer Cosmos continue d'être un composant essentiel pour une intégration transparente dbt-Airflow. Il convertit efficacement les modèles dbt en tâches ou groupes de tâches Airflow natives, avec des nouvelles tentatives et des alertes. Cela fournit une observabilité granulaire des transformations dbt directement dans l'interface utilisateur d'Airflow, résolvant le défi historique des exécutions dbt apparaissant comme une seule tâche opaque dans Airflow. Cosmos a connu des améliorations continues au cours des 1,5 dernières années, avec plus de 300 000 téléchargements mensuels, ce qui indique une forte adoption par la communauté.

Motifs d'orchestration améliorés : Avec les nouvelles capacités de dbt telles que "compiler à la création" et signaler les échecs comme des requêtes ayant échoué (sur Snowflake, à partir d'octobre 2025), Airflow peut désormais réagir plus intelligemment à l'état interne de dbt. Cela signifie que les opérateurs Airflow peuvent potentiellement tirer parti de SYSTEM$get_dbt_log() pour accéder aux journaux d'erreurs dbt détaillés pour une gestion des erreurs et des alertes plus précises.

Considérons un exemple pratique d'orchestration d'un modèle microbatch dbt avec la planification sensible aux ensembles de données d'Airflow, en utilisant Cosmos :

# my_airflow_dag.py
from airflow.decorators import dag, task
from airflow.utils.dates import days_ago
from airflow.datasets import Dataset
from cosmos.providers.dbt.task_group import DbtTaskGroup

# Définir un ensemble de données qui représente la sortie de notre ingestion de données brutes
# Cet ensemble de données peut être mis à jour par un DAG d'ingestion en amont
RAW_EVENTS_DATASET = Dataset("s3://my-bucket/raw_events_landing_zone/{{ ds_nodash }}")

@dag(
    dag_id="dbt_microbatch_pipeline",
    start_date=days_ago(1),
    schedule=[RAW_EVENTS_DATASET], # Déclencher lorsqu'un nouvel événement brut arrive
    catchup=False,
    tags=["dbt", "data_aware", "microbatch"]
)
def dbt_microbatch_pipeline():

    @task
    def check_data_quality_before_dbt():
        # Effectuer des vérifications rapides de la qualité des données sur RAW_EVENTS_DATASET
        print("Exécution des vérifications de qualité des données avant dbt...")
        # Exemple : vérifier le nombre de lignes, la conformité du schéma
        if some_quality_check_fails:
            raise ValueError("La vérification de qualité des données avant dbt a échoué !")
        print("Les vérifications de qualité des données avant dbt ont réussi.")

    pre_dbt_quality_check = check_data_quality_before_dbt()

    # Orchestrer les modèles dbt à l'aide de Cosmos
    # Cosmos crée automatiquement des tâches Airflow pour chaque modèle dbt,
    # y compris notre modèle microbatch.
    # Nous spécifions le projet dbt et la configuration du profil.
    dbt_transformations = DbtTaskGroup(
        group_id="dbt_transformations",
        project_config={
            "dbt_project_path": "/usr/local/airflow/dbt/my_dbt_project",
        },
        profile_config={
            "profile_name": "my_warehouse_profile",
            "target_name": "production",
        },
        # Cela garantit que dbt exécute uniquement les modèles qui ont été modifiés
        # ou leurs dépendances en aval, tirant parti de l'état de dbt
        execution_config={
            "dbt_args": ["--select", "fct_daily_user_activity+"],
        },
        # Ce groupe de tâches est en aval de notre vérification de la qualité
        upstream_task_group=pre_dbt_quality_check
    )

    @task
    def refresh_bi_dashboard():
        # Déclencher l'actualisation du tableau de bord BI en aval
        print("Déclenchement de l'actualisation du tableau de bord BI...")

    refresh_bi_dashboard = refresh_bi_dashboard()

    # Définir les dépendances : après les transformations dbt, actualiser BI
    dbt_transformations >> refresh_bi_dashboard

dbt_microbatch_pipeline()

Dans cet exemple, le DAG est déclenché par RAW_EVENTS_DATASET. Une tâche de vérification de la qualité des données avant dbt s'exécute, et seulement si elle réussit, le DbtTaskGroup (alimenté par Cosmos) exécute les modèles dbt pertinents, y compris notre modèle microbatch fct_daily_user_activity. Enfin, un tableau de bord BI est actualisé. Cela illustre comment Airflow orchestre l'ensemble du pipeline, dbt gérant les transformations complexes, et les améliorations des deux outils permettant un flux de travail plus robuste et observable.

Conclusion : Une pile de données plus raffinée et plus puissante

Les développements récents dans dbt et Airflow démontrent une tendance claire vers des outils d'ingénierie des données plus robustes, plus performants et plus conviviaux pour les développeurs. Le moteur Fusion de dbt et le microbatching dans Core 1.9 s'attaquent aux défis de calcul bruts et à la vélocité d'itération des développeurs. La couche sémantique fait des progrès en matière de cohérence des mesures et de démocratisation des données, tandis que dbt Mesh, avec son intégration Iceberg, ouvre la voie à des architectures de données véritablement décentralisées.

Sur le front de l'orchestration, Airflow 3.0 est une version monumentale, passant à des paradigmes basés sur les événements, offrant un versioning natif des DAG et une interface utilisateur modernisée. Les gains incrémentaux dans Airflow 2.9 et 2.10, en particulier autour de la planification sensible aux ensembles de données et de l'observabilité, ont été des étapes cruciales vers cette refonte majeure.

Bien que les deux écosystèmes soient en évolution rapide, il est important de rester réaliste. Les versions bêta précoces telles que dbt Fusion et certains aspects des capacités étendues d'Airflow 3.0 nécessiteront une évaluation et une adoption progressive minutieuses. La documentation, bien qu'en amélioration, est souvent à la traîne par rapport à l'avant-garde de l'innovation. Cependant, la trajectoire est claire : une pile de données plus efficace, plus observable et plus adaptable émerge. Pour les ingénieurs de données, cela signifie des outils plus puissants pour construire des pipelines résilients et évolutifs, libérant du temps des tâches opérationnelles pour se concentrer sur la fourniture de données fiables et de haute qualité. Le voyage continue, et c'est une période passionnante pour construire dans cet espace.