Ce hub relie toutes les notes sur la structuration d’un projet dbt — couches, nommage, matérialisation, YAML, fonctionnalités modernes et patterns d’analytique marketing. La cohérence des conventions importe plus que tout choix spécifique ; ces notes proposent un cadre de référence opiniâtre et éprouvé, fondé sur l’audit de projets dépassant 400 modèles.
Prérequis
- Concepts dbt de base (modèles, refs, sources, tests)
- SQL à un niveau intermédiaire
- La notion de DAG (graphe acyclique orienté)
Ordre de lecture
Commencez par l’architecture :
- Architecture trois couches dbt — Le pattern base → intermediate → marts. Pourquoi l’ordre alphabétique correspond à l’ordre de la lignée. Quand les trois couches sont nécessaires par rapport à quand base + marts suffisent.
- Patterns de la couche base dbt — Ce qui appartient aux modèles base (renommage, cast, déduplication, unnesting) et ce qui n’y a pas sa place (logique métier, jointures, agrégations).
- Patterns de la couche intermediate dbt — Ce qui appartient à la couche intermediate (jointures, logique métier, fonctions fenêtre). La contrainte critique : ne jamais réduire le grain.
- Nommage centré sur les entités pour les modèles intermediate dbt — Le cas opiniâtre pour nommer les modèles intermediate d’après les entités, pas d’après les transformations. Le pattern
int__customer__customer_lj_order. - Patterns de la couche mart dbt — Ce qui appartient aux marts (agrégations pour la consommation, formatage spécifique au consommateur). Le principe selon lequel chaque mart sert un consommateur spécifique.
Puis les décisions au niveau du projet :
- Structure et nommage d’un projet dbt — Disposition des dossiers, convention de nommage avec double underscore, organisation YAML (pattern par répertoire), configuration
dbt_project.yml, et ce qui va dans les macros, seeds, snapshots et tests. - Matérialisation par défaut dbt : les tables partout — Le cas contre les vues et l’éphémère comme valeurs par défaut. Pourquoi le stockage est bon marché et la visibilité pour le débogage ne l’est pas.
- Modèles incrémentiels dans dbt — Quand passer de table à incrémentiel, quelles stratégies utiliser et comment gérer les données en retard.
Fonctionnalités dbt modernes qui méritent d’être adoptées :
- Taxonomie des tests dbt — Tests génériques, tests singuliers, tests unitaires (dbt 1.8+) et contrats. L’intensité des tests doit augmenter vers les bords du DAG.
- Mécanique des contrats de modèle dbt — Contrats de schéma pour les marts exposés publiquement. Comportement fail-fast au moment du build.
- Groupes et modificateurs d’accès dbt — Propriété et contrôle d’accès. Vaut la peine d’être utilisé même dans les projets individuels pour la documentation, la pérennité et les frontières architecturales imposées.
Pour l’analytique marketing en particulier
Si vous construisez des pipelines d’analytique marketing, ces notes couvrent des patterns spécifiques au domaine :
- Patterns de reporting publicitaire dbt — Patterns UNION cross-plateformes, normalisation spécifique aux plateformes, le package dbt_ad_reporting
- Hub de sessionisation GA4 — Modélisation des données d’événements GA4 dans dbt, logique de sessionisation, stratégies incrémentielles pour GA4
- Patterns d’attribution SQL — Attribution au premier contact, dernier contact et multi-touch en SQL
Documentation des conventions
Rédigez les conventions par écrit. Un fichier CONTRIBUTING.md à la racine du projet dbt documentant les conventions de nommage, la stratégie de matérialisation et les responsabilités par couche rend ces conventions accessibles à tous ceux qui travaillent dans le projet.