Conception Moderne d'Entrepôt de Données : Couches, SCDs et Modèles Incrémentaux

Un entrepôt de données bien conçu est le fondement d'une analytics fiable. Malgré l'engouement pour les paradigmes plus récents, les principes fondamentaux de modélisation dimensionnelle, d'architecture en couches et de suivi des changements restent essentiels. Cet article couvre l'approche moderne de la conception d'entrepôt.

Architecture en Couches : Du Staging au Mart

tadata

Consommateurs — Dashboards · SQL ad hoc · features ML · Reverse ETL
Couche mart (Gold) : fct_orders, dim_customers, rpt_revenue, agg_daily_sales — Prête pour le métier, documentée, gouvernée, SLO définis
Couche intermédiaire (Silver) : int_orders_cleaned, int_customers_deduped, int_products_enriched — Nettoyée, typée, dédupliquée, logique métier appliquée
Couche staging (Bronze) : stg_shopify_orders, stg_stripe_payments, stg_hubspot_contacts — Miroir 1:1 de la source, transformation minimale, append-only

Principes de Conception par Couche

Couche	Objectif	Matérialisation	Fraîcheur	Accès
Staging (Bronze)	Miroir source brut	Incremental append / vue	Temps réel à horaire	Data engineers
Intermédiaire (Silver)	Nettoyer, dédupliquer, typer	Incremental ou table	Horaire à quotidien	Engineers + analystes
Mart (Gold)	Entités prêtes pour le business	Table (matérialisée)	Planifié (SLO)	Tous consommateurs

Comparaison des Types de Dimensions à Évolution Lente (SCD)

Type SCD	Description	Cas d'Usage	Complexité	Impact Stockage	Historique
Type 0	Aucun changement suivi	Données de référence statiques	Aucune	Minimal	Aucun
Type 1	Écraser l'ancienne valeur	Corrections, attributs non historiques	Faible	Minimal	Perdu
Type 2	Ajouter ligne avec dates de validité	Historique complet requis	Moyenne	Élevé	Complet
Type 3	Ajouter colonne pour valeur précédente	Seulement actuel + précédent	Faible	Modéré	Limité
Type 6	Hybride (1 + 2 + 3)	Besoin flag actuel + historique + précédent	Élevée	Élevé	Complet

tadata

Extrait de la fiche « DP-750 Domain 3a: Model and Ingest Data in Unity Catalog » · Demander la fiche complète

Matrice de Stratégie de Matérialisation

Stratégie	Quand Utiliser	Avantages	Inconvénients	Config dbt
View	Staging, transformations légères	Pas de coût stockage, toujours frais	Requêtes lentes	`materialized='view'`
Table	Marts, agrégations lourdes	Requêtes rapides, prévisible	Rebuild complet	`materialized='table'`
Incremental	Grandes tables de faits	Builds rapides, coût faible	Logique complexe	`materialized='incremental'`
Ephemeral	CTEs, logique réutilisable	Pas d'objet créé	Debugging plus difficile	`materialized='ephemeral'`
Snapshot	Suivi SCD Type 2	Historique automatique	Requiert clé unique + timestamp	`dbt snapshot`

Cadre de Convention de Nommage

Type d'Objet	Pattern	Exemple	Notes
Modèle staging	`stg_{source}_{entite}`	`stg_stripe_payments`	Un par table source
Modèle intermédiaire	`int_{entite}_{verbe}`	`int_orders_enriched`	Verbe décrit la transformation
Table de faits	`fct_{événement}`	`fct_orders`	Grain = un événement
Table de dimension	`dim_{entité}`	`dim_customers`	Grain = une entité
Rapport/agrégat	`rpt_{sujet}` ou `agg_{sujet}`	`rpt_monthly_revenue`	Pré-calculé pour BI
Clé de substitution	`sk_{entité}_id`	`sk_customer_id`	Auto-générée
Clé naturelle	`nk_{entité}_id`	`nk_customer_id`	Du système source
Timestamps	`{événement}_at`	`created_at`	Toujours UTC
Booléens	`is_{condition}` ou `has_{chose}`	`is_active`	Intention claire

Ressources

The Analytics Engineering Guide (dbt Labs) -- bonnes pratiques officielles dbt
Kimball Dimensional Modeling Techniques -- la référence fondamentale
Data Warehouse Toolkit (Kimball) -- le livre définitif
Stratégies de Matérialisation dbt -- documentation officielle