Accueil›Blog›Test technique dbt modèles incrémentaux : stratégies et optimisation

Guide recrutement data

Test technique dbt modèles incrémentaux : stratégies et optimisation

Les modèles incrémentaux dbt sont le levier le plus puissant pour réduire les coûts et le temps de traitement. Mal configurés, ils produisent des données incorrectes. En entretien, on évalue la maîtrise des stratégies.

Data Builder·Juin 2025·7 min de lecture·Analytics Engineer

Sommaire

Pourquoi les modèles incrémentaux
Les 4 stratégies
Strategy merge en détail
Late-arriving data
Full refresh et pièges
Incrémental sur Snowflake
Grille

1Pourquoi les modèles incrémentaux

Question discriminante

Quel problème les modèles incrémentaux dbt résolvent-ils ?

Problème — reconstruire entièrement une table de 1 milliard de lignes à chaque run dbt coûte cher en temps et en compute
Solution — ne traiter que les nouvelles lignes ou les lignes modifiées depuis le dernier run
Exemple — table fct_events : 500M lignes historiques. Chaque jour, 1M nouvelles lignes arrivent. Traiter 1M au lieu de 501M = 500x moins de compute
Risque — mal configuré, un modèle incrémental peut rater des lignes ou créer des doublons

2Les 4 stratégies incrémentales

Question discriminante

Quelles sont les différentes stratégies dbt pour les modèles incrémentaux ?

-- Strategy 1 : append (par défaut)
-- Ajoute les nouvelles lignes, ne modifie pas les existantes
{{ config(materialized='incremental') }}
SELECT *
FROM {{ ref('stg_events') }}
{% if is_incremental() %}
WHERE event_date > (SELECT MAX(event_date) FROM {{ this }})
{% endif %}

-- Strategy 2 : merge (upsert)
-- INSERT de nouvelles lignes + UPDATE des existantes
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge'
) }}
SELECT * FROM {{ ref('stg_orders') }}
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

-- Strategy 3 : delete+insert
-- Supprime les lignes de la fenetre et reinsere
{{ config(
    materialized='incremental',
    unique_key=['order_id', 'date'],
    incremental_strategy='delete+insert'
) }}

3Strategy merge : quand et comment

Question discriminante

Quand utilisez-vous merge plutôt qu append ? Quel est le risque si unique_key est mal défini ?

Append — pour les données immuables (events, logs). Une ligne créée ne change jamais
Merge — pour les données qui changent (statut commande, profil client). Nécessite un unique_key
Risque unique_key incorrect — si plusieurs lignes ont la même clé, le merge garde une seule de manière arbitraire. Perte de données silencieuse
Composite key — souvent nécessaire : unique_key=['order_id', 'date'] si les données sont partitionnées par date

4Gérer les late-arriving data

Question discriminante

Qu est-ce que le late-arriving data ? Comment le gérez-vous dans un modèle incrémental ?

-- Problème : des événements du passé arrivent en retard
-- Ex : un mobile en mode offline synchronise des events datant de 3 jours

-- Solution : reprocesser une fenetre glissante de N jours
{{ config(
    materialized='incremental',
    unique_key='event_id'
) }}

SELECT *
FROM {{ ref('stg_events') }}
{% if is_incremental() %}
-- Reprocesser les 3 derniers jours pour capturer les retardataires
WHERE event_date >= (
    SELECT DATEADD('day', -3, MAX(event_date))
    FROM {{ this }}
)
{% endif %}

Late-arriving data — données qui arrivent dans le pipeline après la date attendue
Fenetre glissante — reprocesser les N derniers jours plutôt que seulement depuis le MAX. Plus coûteux mais correct

5Full refresh : quand l utiliser

Question discriminante

Dans quels cas forcez-vous un full refresh sur un modèle incrémental ?

# Forcer un full refresh manuellement
dbt run --full-refresh --select fct_orders

# Cas où le full refresh est nécessaire :
# 1. Changement de logique qui affecte l historique
# 2. Ajout d une nouvelle colonne calculée
# 3. Bug découvert sur les données passées
# 4. Migration de stratégie (append -> merge)

# Configuration : interdire le full refresh en production
{{ config(
    materialized='incremental',
    full_refresh=false  # bloque dbt run --full-refresh sur cette table
) }}

Bloquer le full refresh — sur les très grandes tables (TB+), un full refresh accidentel peut coûter très cher
Process de migration — pour les changements historiques, utiliser un backfill contrôlé par tranches de dates

6Optimisation incrémentale sur Snowflake

Question discriminante

Comment optimisez-vous les performances d un modèle dbt incrémental sur Snowflake ?

{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',
    cluster_by=['order_date', 'region'],  # clustering sur Snowflake
    on_schema_change='append_new_columns',
    snowflake_warehouse='TRANSFORM_WH_S',
    merge_exclude_columns=['created_at']  # ne pas updater created_at
) }}

cluster_by — pré-trier les données pour que le merge soit plus rapide sur les grandes tables
merge_exclude_columns — éviter d écraser des colonnes qui ne doivent pas changer (created_at, inserted_at)
on_schema_change — append_new_columns ajoute les nouvelles colonnes sans full refresh

-- dbt incremental : les strategies
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',  -- merge, append, delete+insert, insert_overwrite
    on_schema_change='sync_all_columns'  -- gerer les changements de schema
) }}

SELECT order_id, customer_id, amount, status, updated_at
FROM {{ source('raw', 'orders') }}
{% if is_incremental() %}
    WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
    -- Pour Snowflake : WHERE updated_at > (SELECT DATEADD('day',-1,MAX(updated_at)) FROM {{ this }})
    -- Safety window de 1 jour pour les retards de replication
{% endif %}

-- Verifier la fraicheur apres un run
-- SELECT MAX(updated_at) FROM {{ this }} -- doit etre proche de NOW()

Safety window - toujours inclure un overlap (1-2h ou 1j) dans le filtre incremental pour capturer les donnees en retard de la source. Ne pas filtrer exactement sur MAX(updated_at)
Strategie merge vs append - merge : upsert, necessite une unique_key. append : ajoute uniquement les nouvelles lignes (plus rapide mais risque de doublons si rerun). delete+insert : supprime la partition puis reinsere
on_schema_change - sync_all_columns ajoute les nouvelles colonnes automatiquement. fail (defaut) : bloquer si le schema change. Choisir selon la maturite de la source
Full refresh force - dbt run --full-refresh recrée la table completement. A utiliser apres un changement de logique majeur ou pour corriger des donnees historiques
Partition pruning avec incremental - sur BigQuery/Snowflake, filtrer sur la colonne de partition dans la condition incrementale. Evite de scanner toute la table source

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	Stratégie append et merge, is_incremental(), unique_key	A configuré un modèle merge avec unique_key, comprend is_incremental()	Ne sait pas ce qu est un modèle incrémental dbt
Senior	Late-arriving data, full refresh strategy, optimisation warehouse	Gère les late-arriving data avec fenêtre glissante, bloque le full refresh sur les grandes tables	Ne sait pas ce qu est le late-arriving data

1Why incremental models

Discriminating question

What problem do dbt incremental models solve?

Problem — fully rebuilding a 1 billion row table on every dbt run is expensive in time and compute
Solution — only process new rows or modified rows since the last run
Example — fct_events table: 500M historical rows. Every day, 1M new rows arrive. Processing 1M instead of 501M = 500x less compute
Risk — if misconfigured, an incremental model can miss rows or create duplicates

2The 4 incremental strategies

Discriminating question

What are the different dbt strategies for incremental models?

-- Strategy 1 : append (default)
-- Adds new rows, does not modify existing ones
{{ config(materialized='incremental') }}
SELECT *
FROM {{ ref('stg_events') }}
{% if is_incremental() %}
WHERE event_date > (SELECT MAX(event_date) FROM {{ this }})
{% endif %}

-- Strategy 2 : merge (upsert)
-- INSERT new rows + UPDATE existing ones
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge'
) }}
SELECT * FROM {{ ref('stg_orders') }}
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

-- Strategy 3 : delete+insert
-- Deletes rows in the window and reinserts them
{{ config(
    materialized='incremental',
    unique_key=['order_id', 'date'],
    incremental_strategy='delete+insert'
) }}

3Merge strategy: when and how

Discriminating question

When do you use merge instead of append? What is the risk if unique_key is incorrectly defined?

Append — for immutable data (events, logs). A row once created never changes
Merge — for data that changes (order status, customer profile). Requires a unique_key
Incorrect unique_key risk — if multiple rows share the same key, the merge keeps only one arbitrarily. Silent data loss
Composite key — often required: unique_key=['order_id', 'date'] if data is partitioned by date

4Handling late-arriving data

Discriminating question

What is late-arriving data? How do you handle it in an incremental model?

-- Problem: past events arrive late
-- Ex: a mobile device in offline mode syncs events from 3 days ago

-- Solution: reprocess a sliding window of N days
{{ config(
    materialized='incremental',
    unique_key='event_id'
) }}

SELECT *
FROM {{ ref('stg_events') }}
{% if is_incremental() %}
-- Reprocess the last 3 days to capture late arrivals
WHERE event_date >= (
    SELECT DATEADD('day', -3, MAX(event_date))
    FROM {{ this }}
)
{% endif %}

Late-arriving data — data that arrives in the pipeline after the expected date
Sliding window — reprocess the last N days rather than only since the MAX. More costly but correct

5Full refresh: when to use it

Discriminating question

In which cases do you force a full refresh on an incremental model?

# Force a full refresh manually
dbt run --full-refresh --select fct_orders

# Cases where full refresh is necessary:
# 1. Logic change that affects historical data
# 2. Adding a new calculated column
# 3. Bug discovered in past data
# 4. Strategy migration (append -> merge)

# Configuration: block full refresh in production
{{ config(
    materialized='incremental',
    full_refresh=false  # blocks dbt run --full-refresh on this table
) }}

Block full refresh — on very large tables (TB+), an accidental full refresh can be very costly
Migration process — for historical changes, use a controlled backfill in date-range batches

6Incremental optimization on Snowflake

Discriminating question

How do you optimize the performance of a dbt incremental model on Snowflake?

{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',
    cluster_by=['order_date', 'region'],  # clustering on Snowflake
    on_schema_change='append_new_columns',
    snowflake_warehouse='TRANSFORM_WH_S',
    merge_exclude_columns=['created_at']  # do not update created_at
) }}

cluster_by — pre-sort data so the merge is faster on large tables
merge_exclude_columns — avoid overwriting columns that should not change (created_at, inserted_at)
on_schema_change — append_new_columns adds new columns without a full refresh

-- dbt incremental: strategies
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',  -- merge, append, delete+insert, insert_overwrite
    on_schema_change='sync_all_columns'  -- handle schema changes
) }}

SELECT order_id, customer_id, amount, status, updated_at
FROM {{ source('raw', 'orders') }}
{% if is_incremental() %}
    WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
    -- For Snowflake: WHERE updated_at > (SELECT DATEADD('day',-1,MAX(updated_at)) FROM {{ this }})
    -- Safety window of 1 day for replication delays
{% endif %}

-- Check freshness after a run
-- SELECT MAX(updated_at) FROM {{ this }} -- should be close to NOW()

Safety window — always include an overlap (1-2h or 1 day) in the incremental filter to capture data delayed from the source. Do not filter exactly on MAX(updated_at)
Merge vs append strategy — merge: upsert, requires a unique_key. append: only adds new rows (faster but risk of duplicates on rerun). delete+insert: deletes the partition then reinserts
on_schema_change — sync_all_columns automatically adds new columns. fail (default): blocks if the schema changes. Choose based on source maturity
Forced full refresh — dbt run --full-refresh fully recreates the table. Use after a major logic change or to fix historical data
Partition pruning with incremental — on BigQuery/Snowflake, filter on the partition column in the incremental condition. Avoids scanning the entire source table

7Level grid

Level	Mastery	GO signal	NO-GO
Mid-level	Append and merge strategy, is_incremental(), unique_key	Has configured a merge model with unique_key, understands is_incremental()	Does not know what a dbt incremental model is
Senior	Late-arriving data, full refresh strategy, warehouse optimization	Handles late-arriving data with a sliding window, blocks full refresh on large tables	Does not know what late-arriving data is

Vous recrutez un Analytics Engineer dbt ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Reserver un appel