dbt: Lookback window + merge strategy

🎯 Problème métier

Dans une table de faits (par exemple : commandes, paiements…), il arrive que certaines données arrivent en retard, plusieurs jours après l’événement réel.

Exemples :

• une commande du 5 juin arrive en base source le 10 juin
• une mise à jour d’un enregistrement existant est retardée à cause d’un bug ou d’un ETL lent

Si tu utilises un modèle incremental classique avec un filtre sur la date du jour (event_date = current_date), tu risques de manquer ces données en retard.

---

✅ Solution : Lookback window + merge strategy

Rejouer uniquement les n derniers jours (ex : 7 jours) et utiliser une stratégie merge pour insérer ou mettre à jour les lignes.

---

🧱 Exemple complet dbt

📁 Modèle : fact_commandes.sql

{{ config(
    materialized = 'incremental',
    incremental_strategy = 'merge',
    unique_key = 'id_commande'
) }}

SELECT *
FROM {{ ref('stg_commandes') }}
WHERE date_commande >= dateadd(day, -7, current_date)

🔍 Explications :

Élément	Rôle
materialized = 'incremental'	active l’incrémental
incremental_strategy = 'merge'	dbt générera un MERGE si supporté par le warehouse
unique_key = 'id_commande'	identifie de manière unique chaque ligne à insérer ou mettre à jour
WHERE date_commande >= ...	définit la fenêtre de rattrapage (“lookback window”)

---

🔁 Que fait dbt ?

Si tu fais :

dbt run --select fact_commandes

dbt générera un SQL comme :

MERGE INTO analytics.fact_commandes AS target
USING (SELECT * FROM stg_commandes WHERE date_commande >= ...) AS source
ON target.id_commande = source.id_commande
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...

✅ Les données en retard sont corrigées automatiquement
❌ Pas besoin de full-refresh
⚠️ Nécessite un entrepôt qui supporte MERGE (BigQuery, Snowflake, Redshift…)

---

📊 Pourquoi c’est efficace ?

Avantage	Description
✅ Données en retard prises en compte	tu ne perds rien si une ligne arrive 3 jours plus tard
⚙️ Requêtes légères	tu ne rejoues que 7 jours, pas toute l’histoire
🧼 Pas de doublons	grâce à unique_key
🔁 Update automatique	dbt met à jour les lignes existantes si besoin
🧠 Compatible avec le concept de “données chaudes”	tu rejoues une “fenêtre glissante” de données récentes

---

🧠 Bonus : affiner la logique avec is_incremental()

SELECT *
FROM {{ ref('stg_commandes') }}
{% if is_incremental() %}
WHERE date_commande >= dateadd(day, -7, current_date)
{% endif %}

✅ Cela permet de :

• rejouer tout à la première exécution (pas de filtre)
• appliquer la lookback uniquement en mode incrémental

---

✅ Résumé final

Élément clé	Rôle
incremental_strategy = 'merge'	Gère insertions et mises à jour
unique_key	évite les doublons
Lookback window (WHERE date >=)	gère les données en retard
is_incremental()	logique conditionnelle à l’incrémental
Recommandé pour	tables de faits avec arrivées tardives (commandes, paiements, etc.)

---