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.)

🎯 Problème métier

✅ Solution : Lookback window + merge strategy