dbt et le lakehouse

Résumé

dbt ne stocke rien et ne calcule rien : il génère du SQL que le moteur exécute, via un adapter. Ce qu’on peut faire dépend donc du couple moteur / format de table. Le point central : la stratégie merge d’un modèle incrémental exige un format de table transactionnel (Iceberg, Delta). Sur un lac de fichiers Parquet seuls, il reste append ou insert_overwrite par partition. Les versions de dbt et le support des moteurs évoluent vite : cette note sépare les principes, stables, des statuts datés, à revérifier.

Prérequis

dbt — Fondamentaux (adapter, matérialisations, stratégie incrémentale) et Data lake vs lakehouse (format de table, catalogue).

Principes durables

Quelle stratégie incrémentale selon la couche

Entrée : un modèle incrémental, clé id.

Table cible :  (1, Alice, 30), (2, Bob, 41)
Lot du jour :  (2, Bob, 42),   (3, Chloé, 28)

Configuration	Résultat
Lakehouse + merge	(1, Alice, 30), (2, Bob, 42), (3, Chloé, 28) : 3 lignes, Bob mis à jour
Lac pur + append	4 lignes, Bob en double (41 et 42)
Lac pur + insert_overwrite	Réécriture de toute la partition concernée (de toute la table sans partition_by)

Avec dbt-spark, merge n’est accepté que pour Delta, Iceberg ou Hudi ; append et insert_overwrite ne dépendent pas du format (documentation dbt, configurations Spark, consultée le 24 octobre 2026).

Points d’attention sur Iceberg

• delete+insert n’est pas toujours atomique : selon l’adapter, c’est une suppression puis une insertion en deux étapes, et la transaction multi-instructions dépend du moteur. Préférer merge.
• Le comportement physique d’un merge (copy-on-write ou merge-on-read) est une propriété de la table, pas de dbt.
• Les catalogues Iceberg peuvent ne pas gérer tous les objets de la même façon (les vues, un create table as atomique) ; le support varie selon le catalogue et le moteur.

Snapshots dbt et time travel : deux notions distinctes

	Time travel du format de table	Snapshot dbt
Ce qu’il restitue	L’état technique de la table à un instant passé	L’historique de lignes capturé à chaque exécution de dbt snapshot
Durée	Limitée par la rétention des versions	Aussi longue que la table de snapshot
Limite	Disparaît à l’expiration des versions	Ne voit que ce qui existe quand le snapshot tourne : un changement survenu et annulé entre deux exécutions est perdu

Exemple : le client 1 passe de Toulouse à Lyon. Un snapshot dbt produit deux lignes. Les bornes dbt_valid_from et dbt_valid_to viennent de la colonne updated_at de la source (stratégie timestamp) ou de l’heure du run (stratégie check), et la dbt_valid_to de l’ancienne ligne est égale à la dbt_valid_from de la nouvelle. La question « ville du client 1 au 1er juin » trouve sa réponse dans le snapshot ; avec le seul time travel, elle disparaît dès que la version correspondante est expirée.

Orchestration et maintenance

dbt ne planifie rien et ne fait pas la maintenance du format de table. Un orchestrateur doit relancer les exécutions en cas de conflit de commit sur le catalogue, et planifier la compaction et l’expiration des snapshots (voir Maintenance d’un lakehouse).

Statuts datés, à revérifier

Données périssables

Statuts relevés dans la documentation dbt le 22 octobre 2026 (versions, dates de support, couverture des adapters). À revérifier avant toute décision : passer à la v2, catalogs.yml, DuckDB et Iceberg.

dbt 1.x et dbt v2 (relevé du 22 octobre 2026)

Aspect	dbt Core 1.x	dbt v2
Distribution	dbt-core 1.x, licence Apache 2.0, moteur Python	Deux distributions : Fusion (licence dbt) et dbt OSS (Apache 2.0), moteur Rust partagé
Installation	pip install dbt-core + un adapter	pip install dbt donne Fusion par défaut ; dbt-oss pour l’open source strict
Dépôt	Dépôt dbt Core historique	Le dépôt dbt-labs/dbt regroupe désormais v1 et v2, d’après les notes de version
Support	1.12 sorti le 16 juillet 2026 ; 1.11 en support critique jusqu’au 18 décembre 2026	Voir la documentation de dbt v2
Cohabitation	Manifest v12	Fusion produit un manifest v12 compatible avec dbt Core

La documentation indique que les nouvelles capacités arriveront à terme uniquement dans v2. L’outil dbt-autofix corrige automatiquement une partie des avertissements de dépréciation ; Fusion valide plus strictement que Core 1.x.

Couverture des moteurs ouverts (relevé du 22 octobre 2026)

Moteur	Adapter 1.x
Spark	dbt-spark
Trino	dbt-trino
DuckDB	dbt-duckdb
ClickHouse	dbt-clickhouse

Les stratégies incrémentales prises en charge par chaque adapter sont listées par la documentation dbt (Incremental strategy) ; la page ne couvre pas tous les adapters communautaires : vérifier la page de l’adapter retenu.

Le statut sous v2 des adaptateurs Spark, Trino et DuckDB (authentification et macros à compléter pour Trino) est à revérifier. DuckDB écrit dans Iceberg via un catalogue REST ; la configuration catalogs.yml exige dbt v2 et l’option use_catalogs_v2, et la documentation demande DuckDB 1.5.4 ou plus pour écrire dans certains catalogues.

Notes liées

• Data lake vs lakehouse : les concepts.
• Écosystème lakehouse, formats, catalogues et moteurs : formats de table, catalogues, moteurs.
• Slowly Changing Dimensions, types 0 à 3 : le type 2 que les snapshots dbt implémentent.
• Lakehouse auto-hébergé sur Scaleway : moteurs déployables et compatibilité dbt.
• Choisir entre lake, lakehouse et warehouse : adapters des éditeurs et maintenance.
• dbt Incremental Models vs Snowflake Dynamic Tables : stratégies incrémentales côté entrepôt.
• dbt — Fondamentaux : les bases.
• MOC Data Engineering : carte du vault.