dbt vs Airflow : définitions et fonctions clés

Si vous comparez dbt vs airflow, le point de départ est simple : dbt gère la transformation SQL dans l’entrepôt, alors que airflow pilote l’ordre d’exécution d’un pipeline plus large. Les deux outils travaillent souvent ensemble, and c’est précisément là que la comparaison devient utile. dbt compile des modèles, lance des tests, génère de la documentation and du lineage. Airflow, de son côté, orchestre des tâches Python, des appels API, des jobs warehouse and des notifications. In the first minutes of a project, that distinction change presque tout for your architecture, surtout si you travaillez with dbt cloud ou un data warehouse moderne.

Ce que fait dbt dans un data warehouse

dbt, pour data build tool, exécute des requêtes SQL directement dans le warehouse. Il ne fait ni extract ni load. Il part du principe que les données sont déjà là, dans Snowflake, BigQuery, Redshift ou un autre moteur. Ensuite, il applique une logique de modélisation via des fichiers .sql, des tests YAML, des snapshots et des macros.

Dans les faits, dbt apporte cinq briques très concrètes :

• modèles versionnés pour transformer des tables brutes en tables métier
• tests intégrés comme not null, unique ou des règles custom
• documentation générée à partir du projet
• lineage exploitable pour voir quelles tables dépendent de quelles sources
• compilation SQL avant exécution, ce qui aide à relire le code final

Un exemple simple. Une équipe e commerce charge 50k events par jour dans BigQuery. dbt transforme ces événements en tables orders, customers et daily_sales. Le build complet prend 20 minutes. C’est propre, lisible, et surtout reproductible.

Ce que fait apache airflow pour l’orchestration

Airflow est un orchestrateur Python créé chez Airbnb en 2014, puis passé en open source en 2016 sous l’égide Apache. Sa mission : définir des DAG, planifier des runs, suivre les dépendances, relancer les tâches en erreur, envoyer des alertes. Autant le dire, airflow ne remplace pas dbt. Il fait autre chose.

Vous décrivez un workflow sous forme de DAG. Chaque tâche peut lancer un script Python, interroger une API, déposer un fichier S3, démarrer un job SQL, appeler un job dbt cloud, ou publier un message Slack. C’est large. Très large, même.

Dans un pipeline journalier e commerce, airflow peut :

• lancer l’ingestion des commandes à 2 h 00
• vérifier que le chargement brut est terminé à 2 h 08
• démarrer un job dbt à 2 h 10
• lancer les tests puis un refresh BI à 2 h 32
• envoyer une alerte si le SLA de 45 minutes est dépassé

Mini timeline dbt and airflow

Le repère temporel aide pas mal.

• 2014, Airbnb crée airflow pour ses workflows internes
• 2016, apache airflow devient un projet open source plus largement adopté
• 2016 aussi, dbt arrive avec une approche SQL first pour analytics engineering
• 2020 à 2026, les deux entrent dans beaucoup de stacks modernes
• aujourd’hui, les équipes data teams les combinent souvent dans des pipelines batch

Le truc à retenir : dbt traite la logique de transformation and airflow traite la logique d’exécution.

Comparaison technique : transformation sql avec dbt

Comment dbt compile vos models sql dans the warehouse

dbt fonctionne avec des models, c’est à dire des fichiers SQL qui décrivent un select. Au moment du run, dbt résout les références, injecte les macros Jinja, compile le tout and exécute le SQL final dans the warehouse. Cette étape de compilation compte beaucoup, parce qu’elle donne de la traçabilité et un point de contrôle avant production.

Prenons un model simple :

Ce code paraît court. Pourtant, dbt ajoute autour toute une mécanique de dépendances, de materialization, de testing and de documentation. Un analyste peut write ce model, un engineer peut relire le SQL compilé, puis la CI valide les changements before merge.

Materializations, snapshots, tests et limites de dbt

dbt propose plusieurs materializations. view, table, incremental, parfois ephemeral. Le choix dépend du volume, du cost de compute et du niveau de fraîcheur attendu. Sur une table de 200 millions de lignes, un mode incremental évite de rebuild tout chaque nuit. Franchement, c’est souvent là que le gain financier se joue.

dbt includes aussi les snapshots pour suivre l’historique d’une dimension lente, par exemple l’évolution d’une adresse client. Et la couche de testing and quality réduit les régressions bêtes, celles qui arrivent quand une source change de type ou qu’une clé n’est plus unique.

Avantages opérationnels assez nets :

• sql based workflow accessible à des analysts et analytics engineers
• testing and documentation dans le même projet
• lineage visuel utile pour l’impact analysis
• dbt core ou dbt cloud selon le niveau de managed souhaité
• bonne intégration Git pour CI, review et déploiement

Mais il y a une limite claire. dbt ne fait pas l’orchestration complète d’un système multi sources. Il ne gère pas nativement l’ingestion, les transferts inter systèmes ou les notifications hors de son périmètre.

Pourquoi utiliser dbt pour la data transformation ?

Pourquoi use dbt ? Parce que la data transformation en SQL reste le cas le plus fréquent dans un data warehouse. Si votre team modélise des tables métier, calcule des KPI et publie des marts analytics, dbt donne un cadre propre. Vous obtenez des models and tests versionnés, des docs à jour, un lineage lisible and une séparation claire entre logique métier et exécution.

Quand you avez déjà les données dans Snowflake ou BigQuery, dbt est souvent le meilleur point d’entrée. Pas parce qu’il fait tout. Juste parce qu’il fait très bien sa part.

Comparaison technique : orchestration Airflow et gestion des DAG

Comment airflow exécute des workflows Python

Airflow repose sur plusieurs composants : scheduler, webserver, metadata database, workers, executors. Vous décrivez un DAG en Python, vous définissez des tasks, des operators, des hooks, puis le scheduler déclenche les runs selon une schedule donnée. En pratique, c’est un système très souple, mais qui demande du code, du setup et un minimum de discipline.

Un DAG simple peut ressembler à ça dans son intention :

• extract des commandes depuis une API Shopify
• load des fichiers bruts vers un bucket cloud
• déclencher un job dbt cloud
• vérifier les tests
• notifier Slack si tout est vert

Airflow est bon ici parce qu’il traverse plusieurs systems. Il ne se limite pas au SQL. Il peut orchestrate des scripts Python, des jobs machine learning, des exports CSV, des vérifications de fichiers and des appels REST.

DAG, operators, hooks et monitoring airflow

Le vocabulaire compte. Un DAG décrit le workflow. Les operators définissent le type de tâche. Les hooks gèrent les connexions. Le scheduler lance les exécutions. L’UI permet de monitor les runs, la durée de chaque task, les retries et les erreurs.

Ce qui plaît aux équipes data engineering :

• gestion des dependencies explicites entre tasks
• scheduling sur base horaire, quotidienne ou événementielle
• monitoring centralisé avec logs, retries et SLA
• support multi systèmes via de nombreux providers
• contrôle fin sur le runtime et la reprise après erreur

Le problème, c’est que cette flexibilité a un prix. Airflow requires Python, une infrastructure décente, and parfois Kubernetes selon le scale. Pour une petite équipe de 2 analysts, c’est souvent trop lourd au départ.

Comment utiliser Airflow dans un pipeline data ?

Comment utiliser Airflow ? Commencez petit. Un DAG journalier, 4 à 6 tasks, des logs propres, une seule source, un seul data warehouse. Dans un pipeline e commerce à 50k events/jour, airflow peut trigger l’ingestion à 1 h 30, attendre la fin du loading à 1 h 42, lancer dbt à 1 h 45, puis notifier à 2 h 05. Temps total, 35 minutes. SLA respecté.

Le bon réflexe : garder la logique métier dans dbt and la logique de contrôle dans airflow. Là où ça coince souvent, c’est quand une team essaie de faire toute la transformation directement dans des operators SQL Airflow. Ça marche au début. Puis ça devient pénible à maintenir.

Architecture combinée : comment dbt et Airflow travaillent ensemble

Le pattern le plus propre pour dbt and airflow

Dans une architecture moderne, airflow appelle dbt via CLI, conteneur dédié, ou API dbt cloud. Airflow sait quand lancer le job. dbt sait comment transformer les données. Cette séparation est saine. Elle évite de recréer dans airflow ce que dbt fait déjà mieux, notamment models, tests, documentation and lineage.

Le pattern le plus courant ressemble à ceci :

• ingestion depuis des sources SaaS ou bases relationnelles
• and loading dans le data warehouse
• trigger d’un run dbt sur un sous-ensemble de models
• exécution des tests critiques
• publication downstream vers BI ou alerte ops

Côté choix technique, vous avez en gros deux options. Soit airflow lance dbt run et dbt test avec dbt core. Soit airflow déclenche des jobs dbt cloud déjà configurés. La seconde option réduit la charge de management local, mais ajoute un coût SaaS.

Tableau de responsabilités entre airflow and dbt

Sur un cas e commerce quotidien, l’ingestion prend 12 minutes, le run dbt 20 minutes, le refresh BI 4 minutes. Le pipeline complet tient donc en 36 minutes. Si votre SLA est de 45 minutes avant 7 h 00, vous avez 9 minutes de marge. Ce n’est pas énorme, mais c’est exploitable.

Paramètres, erreurs et retries dans une architecture mixte

Airflow peut passer des variables d’environnement, des dates d’exécution, des sélecteurs de models ou des tags vers dbt. Vous pouvez, par example, lancer seulement tag:finance les lundis, ou un subset hourly pour la table orders_intraday. Ce genre de configuration donne une vraie souplesse.

Et la surprise : le retry ne se place pas au même niveau. Airflow gère le retry de la tâche. dbt gère les erreurs de compilation, de test ou de requête SQL. Il faut donc définir clairement qui fait quoi, sinon vous aurez des reruns peu lisibles.

Coût, scalabilité et opérations : data warehouse et orchestration

Coûts réels de dbt, dbt cloud et airflow

Côté portefeuille, c’est différent selon le composant. dbt exécute ses transformations dans le warehouse. Le cost principal vient donc du compute Snowflake, BigQuery ou Redshift. Un run de 20 minutes sur 50k events/jour coûte peu. Un rebuild complet sur 2 milliards de lignes, lui, peut coûter cher. Très cher, même.

Airflow est open source, mais pas gratuit dans les faits. Il faut des workers, un scheduler, du stockage de logs, du monitoring, des upgrades, un peu de sécurité, parfois un managed service comme MWAA, Cloud Composer ou Astronomer. Le coût n’est pas dans la licence. Il est dans l’infrastructure et le temps humain.

Repères utiles :

• dbt core ne facture pas de licence, mais demande CI/CD et runtime
• dbt cloud ajoute une couche managed, du scheduling et une UI
• airflow consomme des ressources infra, surtout si le volume de tasks grimpe
• build incremental de quelques minutes coûte bien moins qu’un full refresh
• workers sous utilisés finissent vite par peser sur le budget

Scalabilité, sécurité et cycle de release

Pour la scalabilité, dbt dépend surtout du moteur SQL. Si votre warehouse scale bien, dbt suit. Airflow scale via plus de workers, une meilleure queue, un exécuteur adapté. Les deux peuvent tenir de gros volumes, mais pas de la même façon.

Sur la sécurité, il faut penser secrets, rôles, comptes de service et séparation dev prod. dbt cloud facilite certains points de configuration. Airflow managed aussi, selon la platform choisie. Avec dbt core and airflow auto hébergé, la charge ops grimpe vite.

Impact sur le cycle de release :

• dbt simplifie les revues de code métier
• airflow impose des tests de DAG et une discipline de deployment
• the data team doit synchroniser release SQL and release orchestration
• monitoring end to end devient indispensable dès 2 ou 3 pipelines critiques
• support de production demande des runbooks, même pour des cas simples

Franchement, le point le plus sous estimé n’est pas la techno. C’est le temps de maintien.

Questions fréquentes sur dbt vs airflow

Quelle est la différence entre dbt et Airflow ?

dbt traite la transformation sql dans le data warehouse. Airflow gère l’orchestration de tasks et de workflows across plusieurs systems. L’un transforme, l’autre coordonne. Ils ne sont pas interchangeables.

Le flux d’air est-il similaire à celui du DBT ?

Non. Apache airflow et dbt n’ont pas le même niveau d’abstraction. Airflow orchestre des DAG Python and des tâches variées, alors que dbt compile du SQL, exécute des models, des tests et de la documentation dans the warehouse.

Quand utiliser dbt seul ?

Use dbt seul quand votre besoin porte surtout sur des transformations in warehouse, avec peu de dépendances externes. Typiquement, une petite équipe analytics, un seul warehouse, une schedule quotidienne et pas de machine learning ni de workflow multi systèmes.

Comment intégrer dbt cloud ?

Le plus simple est de laisser airflow trigger des jobs dbt cloud via API ou provider dédié. Vous gardez l’orchestration globale dans airflow, and vous profitez de l’interface managed de dbt cloud pour les runs, la docs et certains logs.

Checklist de choix pour dbt airflow

Avant de choose, passez cette checklist. Elle évite pas mal d’erreurs de cadrage.

• Vous avez surtout besoin de transformation sql dans un warehouse déjà alimenté, use dbt d’abord
• Vous devez coordonner ingestion, dbt, alertes et exports, use airflow comme orchestrator
• Votre équipe est surtout SQL, dbt sera plus simple à adopter que Python airflow
• Votre pipeline est critique avec SLA, retries et dépendances cross systems, airflow devient vite nécessaire
• Vous voulez moins de management infra, dbt cloud ou un airflow managed peuvent faire gagner du temps
• Vous avez du ML, des API, des transferts inter services, airflow prend l’avantage sur la partie workflow
• Vous cherchez une couche de qualité, documentation and lineage, dbt couvre très bien ce besoin
• Votre meilleure option est souvent la combinaison, avec airflow pour le contrôle and dbt pour la logique métier

Le point final, si vous voulez un avis net : pour un pipeline fiable, lisible et maintenable, le duo marche mieux que l’opposition. Use dbt pour transformer. Use airflow pour piloter. C’est plus clair pour les engineers, plus propre pour les analysts, et bien plus robuste quand les volumes montent.