Guide Spark, Airflow, dbt pour tout comprendre facilement

Dans mes missions, je croise beaucoup de professionnels qui confondent ces trois outils ou on une idée très flou de leur usage. Lors de mon dernier projet, mon client m’a demandé un article qui explique très simplement le rôle de ces outils (et d’autres que je traiterais dans d’autre article et vidéo youtube). Voici donc mon guide pour comprendre facielement à quoi sert Sparck, airflow et dbt.

Disons le tout de suite, Spark, Airflow et dbt ne font pas la même chose, chacun à un boulot bien à lui. Ils peuvent travailler ensemble, mais ils ne répondent pas au même problème.

Outil	Sert à quoi ?	Question à laquelle il répond
Apache Spark	Traiter beaucoup de données	“Comment je calcule vite sur de gros volumes ?”
Airflow	Orchestrer des traitements	“Dans quel ordre j’exécute mes tâches, et quand ?”
dbt	Transformer/modéliser les données en SQL	“Comment je construis proprement mes tables analytiques ?”

1. Apache Spark : le moteur de calcul distribué

Spark sert à traiter de gros volumes de données, souvent trop lourds pour une base SQL classique ou un script Python simple.

Il peut lire des fichiers, des tables, des logs, des événements, puis faire des transformations dessus.

Exemple :

df = spark.read.parquet("s3://data/events/")
df_filtered = df.filter(df["event_name"] == "purchase")
df_grouped = df_filtered.groupBy("country").sum("revenue")
df_grouped.write.parquet("s3://data/output/revenue_by_country/")

Ce que Spark fait bien :

• traiter des millions ou milliards de lignes ;
• lire/écrire dans des data lakes ;
• faire des agrégations massives ;
• manipuler des fichiers Parquet, JSON, CSV ;
• faire du batch ou du streaming ;
• exécuter du Python, Scala, Java ou SQL.

Image mentale : Spark = l’usine de calcul.

Tu lui donnes beaucoup de matière brute, il transforme à grande échelle.

2. Airflow : le chef d’orchestre

Airflow ne transforme pas vraiment les données lui-même.

Son rôle, c’est de dire :

D’abord tu récupères les données.
Ensuite tu nettoies.
Ensuite tu charges dans BigQuery.
Ensuite tu lances dbt.
Ensuite tu préviens Slack si ça casse.

Airflow organise des tâches sous forme de DAG.

Un DAG, c’est un graphe de dépendances.

Exemple logique :

extract_ga4
   ↓
load_bigquery
   ↓
run_dbt_models
   ↓
run_quality_tests
   ↓
send_report

Exemple simplifié en Python :

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id="daily_marketing_pipeline",
    start_date=datetime(2024, 1, 1),
    schedule="@daily",
    catchup=False
) as dag:

    extract = BashOperator(
        task_id="extract_ga4",
        bash_command="python extract_ga4.py"
    )

    transform = BashOperator(
        task_id="run_dbt",
        bash_command="dbt run"
    )

    test = BashOperator(
        task_id="dbt_test",
        bash_command="dbt test"
    )

    extract >> transform >> test

Ce qu’Airflow fait bien :

• planifier des traitements ;
• gérer les dépendances ;
• relancer une tâche en échec ;
• suivre les logs ;
• déclencher des pipelines ;
• orchestrer Spark, dbt, Python, API, BigQuery, etc.

Image mentale : Airflow = le planning + le superviseur.

Il ne fabrique pas forcément la donnée. Il dit qui travaille, quand, et dans quel ordre.

3. dbt : l’atelier SQL propre

dbt sert à transformer les données dans ton entrepôt de données, souvent avec du SQL.

Par exemple, tu as une table brute :

raw_ga4_events

Tu veux créer :

stg_ga4_events
fct_sessions
fct_conversions
dim_campaigns

Avec dbt, chaque modèle est souvent un fichier SQL.

Exemple :

-- models/marts/fct_conversions.sql

SELECT
  user_id,
  session_id,
  event_date,
  traffic_source,
  COUNTIF(event_name = 'purchase') AS conversions,
  SUM(revenue) AS revenue
FROM {{ ref('stg_ga4_events') }}
GROUP BY
  user_id,
  session_id,
  event_date,
  traffic_source

dbt gère les dépendances avec ref() :

FROM {{ ref('stg_ga4_events') }}

Ça veut dire :

Ce modèle dépend de stg_ga4_events.
Donc dbt sait qu’il doit construire stg_ga4_events avant.

Ce que dbt fait bien :

• organiser les transformations SQL ;
• documenter les modèles ;
• tester la qualité des données ;
• gérer les dépendances entre tables ;
• versionner la logique métier ;
• construire des modèles analytiques propres.

Image mentale : dbt = le chantier de modélisation analytique.

C’est là que tu transformes des tables brutes en tables utiles pour la BI, le reporting, l’analyse et le machine learning.

Le piège classique

Beaucoup de débutants mélangent tout.

Ils pensent :

“Airflow fait la transformation.”

Pas vraiment.

Airflow peut déclencher une transformation, mais il n’est pas censé contenir toute la logique métier.

Ils pensent aussi :

“dbt remplace Airflow.”

Pas complètement.

dbt sait gérer les dépendances entre modèles SQL, mais il n’orchestre pas toujours tout ton système : appels API, ingestion, fichiers, Spark jobs, exports, notifications, etc.

Ils pensent enfin :

“Spark remplace dbt.”

Pas forcément.

Spark peut transformer de la donnée, mais dbt structure mieux la logique analytique quand ton travail est principalement SQL dans un data warehouse.

Exemple concret : pipeline marketing

Imaginons un pipeline classique :

Tu veux récupérer :

• événements GA4 ;
• coûts Google Ads ;
• coûts Meta Ads ;
• CRM leads ;
• ventes e-commerce.

Objectif : créer une table fiable pour Looker Studio :

fct_campaign_performance

Avec :

date
source
medium
campaign
cost
sessions
leads
transactions
revenue
roas

Architecture possible :

API Google Ads / Meta / CRM
          ↓
      ingestion Python
          ↓
  stockage brut BigQuery
          ↓
      dbt staging
          ↓
      dbt marts
          ↓
   Looker Studio / BI

Airflow pilote tout :

1. extract_google_ads
2. extract_meta_ads
3. extract_crm
4. load_raw_bigquery
5. run_dbt
6. run_dbt_tests
7. notify_if_error

Spark n’est utile que si les volumes deviennent sérieux :

logs massifs
events web très volumineux
datalake
traitements distribués
fichiers Parquet énormes
streaming

Sinon, pour beaucoup de cas marketing, BigQuery + dbt + Airflow suffit largement.

Quand utiliser quoi ?

Situation	Outil principal
Transformer des tables dans BigQuery/Snowflake/Redshift	dbt
Planifier un pipeline quotidien	Airflow
Gérer des dépendances entre tâches	Airflow
Documenter les tables analytiques	dbt
Tester not_null, unique, relations entre tables	dbt
Traiter plusieurs centaines de Go ou To	Spark
Lire/transformer un data lake	Spark
Lancer un traitement toutes les nuits	Airflow
Créer un modèle étoile propre	dbt
Déclencher dbt après ingestion	Airflow

Comment ils travaillent ensemble ?

Une architecture réaliste :

              Airflow
                 │
 ┌───────────────┼────────────────┐
 │               │                │
Extract API   Spark job        dbt run
 │               │                │
raw tables   cleaned files   analytical tables
 │               │                │
 └───────────────┴────────────────┘
                 ↓
          Data Warehouse
                 ↓
           BI / Reporting

Mais attention : tout mettre dans Airflow est une mauvaise idée.

Mauvais usage :

# Airflow rempli de SQL métier énorme
task = BigQueryOperator(
    sql="""
    SELECT
      ...
    300 lignes de logique métier
    ...
    """
)

Meilleur usage :

run_dbt = BashOperator(
    task_id="run_dbt",
    bash_command="dbt run && dbt test"
)

La logique métier reste dans dbt.
Airflow orchestre.

En résumé

Spark calcule.
Airflow orchestre.
dbt modélise.

Parce que sans SQL propre et sans modèle de données clair, Spark et Airflow ne feront qu’automatiser le chaos.