1. Qu’est-ce que l’architecture medallion ?
L’architecture medallion est un modèle qui structure votre lakehouse en trois couches progressives : Bronze (brut), Silver (nettoyée) et Gold (prête pour le métier). Chaque couche améliore la qualité des données et rapproche de la valeur business.
L’idée clé
Bronze
Brut, tel que reçu
Silver
Nettoyé, conformé
Gold
Prêt pour le métier
Pourquoi ne pas nettoyer une seule fois ?
Parce que les règles changent. Garder le brut en Bronze permet de retraiter quand la logique métier évolue. Les équipes qui sautent Bronze doivent souvent ré-ingérer quand on leur demande « les données avant ce filtre ».
Quand utiliser l’architecture medallion :
Multiples sources
Quand vous ingérez 10+ sources avec formats, schémas et qualités différentes.
Consommateurs variés
Quand les data scientists veulent du brut, les analystes du propre, et les dashboards des agrégats.
Exigences mouvantes
Quand la logique métier change souvent et que vous devez retraiter l’historique.
Besoins de conformité
Quand vous devez tracer, conserver la lignée et prouver l’état des données à tout moment.
Retours terrain
L’important n’est pas le nom mais le principe : ne jamais perdre le brut, améliorer la qualité par étapes, fournir la bonne abstraction au bon public. Vous pouvez appeler vos couches « raw/staging/marts » ou « landing/curated/consumption » : le pattern reste le même.
2. Les trois couches expliquées
Chaque couche a un rôle, un propriétaire et un niveau de qualité. Ce cadre rend l’architecture efficace.
| Couche | Objectif | Niveau de qualité | Consommateurs |
|---|---|---|---|
| 🥉 Bronze | Déposer le brut tel quel | Aucun – on garde tout | Data engineers, debug |
| 🥈 Silver | Nettoyer, dédupliquer, conformer les schémas | Validé, typé, cohérent | Data scientists, analystes avancés |
| 🥇 Gold | Agrégats et métriques métier | Validé métier, documenté | Dashboards, rapports, apps |
Principes clés pour chaque transition :
Bronze vers Silver
Nettoyer et conformer
Retirer les doublons, caster les types, appliquer le schéma, filtrer les enregistrements invalides, standardiser les formats (dates, devises, codes).
Silver vers Gold
Agrégations et enrichissement
Joindre les tables liées, calculer les métriques métier, appliquer la logique métier, créer des modèles dimensionnels, optimiser pour les patterns de requêtes.
Astuce
Ne sautez pas Silver
Aller directement de Bronze à Gold est tentant, mais Silver est là où vit la qualité. Sans Silver, la logique de nettoyage est recopiée partout en Gold : les changements deviennent coûteux et risqués.
3. Focus sur la couche Bronze
Bronze est votre « data lake » au sens strict : tout atterrit ici tel que reçu. L’objectif est durabilité et traçabilité, pas propreté.
Bronze doit contenir
- • Données brutes telles que reçues (JSON, CSV, Parquet)
- • Métadonnées d’ingestion (timestamp, fichier source, batch ID)
- • Écritures append-only (jamais de mise à jour/suppression)
- • Partitionnement par date d’ingestion
- • Rétention longue (mois à années)
Bronze ne doit pas contenir
- • Enforcement de schéma (laisser entrer le mauvais)
- • Transformations
- • Logique de déduplication
- • Logique métier ou calculs
- • Accès pour les utilisateurs métier
Structure d’une table Bronze :
Exemple : schéma de table Bronze orders
-- Bronze: raw_orders CREATE TABLE bronze.raw_orders ( -- Ingestion metadata _ingested_at TIMESTAMP, _source_file STRING, _batch_id STRING, -- Raw payload (store as-is) raw_payload STRING, -- JSON string, unparsed -- Or if structured: order_id STRING, -- Not validated yet customer_id STRING, order_date STRING, -- Could be any format amount STRING, -- Could have currency symbols status STRING ) PARTITIONED BY (_ingested_at::DATE)
Ajouter des métadonnées d’ingestion
Timestamp, fichier source, batch ID. Indispensable pour le debug et le retraitement.
Utiliser l’append-only
Jamais de UPDATE ou DELETE en Bronze. Une correction = un nouvel enregistrement avec nouveau timestamp.
Partitionner par date d’ingestion
Facilite le retraitement ciblé et la gestion de la rétention.
Rester économique
Formats compressés (Parquet, ORC) et stockage froid pour les partitions anciennes.
4. Focus sur la couche Silver
Silver est là où le travail réel se fait. C’est votre source de vérité entreprise pour des données propres et validées.
Responsabilités de la couche Silver :
Enforcement de schéma
Caster les types, imposer NOT NULL, valider les formats. Les enregistrements invalides vont dans une table de quarantaine.
Déduplication
Retirer les doublons. Utiliser les clés métier + timestamp pour conserver la dernière version.
Standardisation
Normaliser les dates en ISO, les devises en base, les codes aux valeurs standard.
Contrôles qualité
Tests automatiques : taux de null, unicité, intégrité référentielle, plages de valeurs.
Exemple : transformation Silver orders (dbt)
-- models/silver/orders.sql
WITH source AS (
SELECT * FROM {{ source('bronze', 'raw_orders') }}
WHERE _ingested_at >= CURRENT_DATE - INTERVAL '7 days'
),
deduplicated AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY order_id
ORDER BY _ingested_at DESC
) as row_num
FROM source
),
cleaned AS (
SELECT
-- Cast and validate types
CAST(order_id AS BIGINT) AS order_id,
CAST(customer_id AS BIGINT) AS customer_id,
-- Standardize date format
TO_DATE(order_date, 'YYYY-MM-DD') AS order_date,
-- Clean amount (remove currency symbols)
CAST(REGEXP_REPLACE(amount, '[^0-9.]', '') AS DECIMAL(10,2)) AS amount,
-- Normalize status to uppercase
UPPER(TRIM(status)) AS status,
-- Keep lineage
_ingested_at,
_batch_id
FROM deduplicated
WHERE row_num = 1
AND order_id IS NOT NULL
)
SELECT * FROM cleanedRetours terrain
Silver est la couche où beaucoup d’équipes sous-investissent. Elles courent vers Gold et recopient la logique de nettoyage partout. Investissez dans Silver : cela paie sur chaque modèle en aval.
5. Focus sur la couche Gold
Gold est là où vit la valeur métier. Ce sont les tables réellement requêtées par les parties prenantes. Pensez modèles dimensionnels, métriques et agrégats orientés usage.
Patterns fréquents en Gold :
Modèles dimensionnels (star schema)
Tables de faits (événements, transactions) entourées de dimensions (clients, produits, temps). Optimisé pour la BI et l’ad hoc.
Exemple :
fact_orders ← dim_customers, dim_products, dim_dateMétriques pré-agrégées
Rollups journaliers/hebdomadaires/mensuels pour les tableaux de bord. Requêtes plus rapides, coûts moindres.
Exemple :
daily_revenue_by_region, weekly_active_users, monthly_churn_ratesFeature tables (ML)
Features pré-calculées pour les modèles de machine learning. Correctes en point-in-time, versionnées.
Exemple :
customer_features, product_embeddings, user_activity_signalsExemple : table de faits Gold (dbt)
-- models/gold/fact_orders.sql
WITH orders AS (
SELECT * FROM {{ ref('silver_orders') }}
),
customers AS (
SELECT * FROM {{ ref('dim_customers') }}
),
products AS (
SELECT * FROM {{ ref('dim_products') }}
)
SELECT
-- Surrogate key
{{ dbt_utils.generate_surrogate_key(['o.order_id']) }} AS order_key,
-- Foreign keys to dimensions
c.customer_key,
p.product_key,
d.date_key,
-- Degenerate dimensions
o.order_id,
o.status,
-- Measures
o.quantity,
o.unit_price,
o.quantity * o.unit_price AS line_total,
o.discount_amount,
-- Audit columns
o._ingested_at AS source_loaded_at,
CURRENT_TIMESTAMP AS dbt_loaded_at
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
LEFT JOIN products p ON o.product_id = p.product_id
LEFT JOIN {{ ref('dim_date') }} d ON o.order_date = d.date_dayPrincipe Gold
Optimiser pour les requêtes
Partitionner sur les colonnes de filtre fréquentes (date, région). Cluster sur les clés de jointure.
Principe Gold
Documenter la logique métier
Chaque table Gold doit décrire clairement ses métriques.
Principe Gold
Versionner avec soin
Les changements en Gold peuvent casser les dashboards. Utilisez versioning sémantique ou alias.
6. Modèles d’implémentation
L’architecture medallion fonctionne sur toute plateforme moderne. Voici comment l’implémenter avec les stacks courants.
| Plateforme | Bronze | Silver/Gold | Format |
|---|---|---|---|
| Databricks | Unity Catalog | Delta Lake + dbt | Delta |
| Snowflake | Base RAW | dbt + Snowflake | Tables natives |
| BigQuery | Dataset raw_ | dbt + BQ | Tables natives |
| AWS (Open) | S3 + Glue | Spark + dbt | Iceberg/Hudi |
Structure dossiers/base :
# Convention de nommage typique
catalog/
├── bronze/
│ ├── raw_orders
│ ├── raw_customers
│ ├── raw_products
│ └── raw_events
├── silver/
│ ├── orders # Commandes nettoyées
│ ├── customers # Clients nettoyés
│ ├── products # Produits nettoyés
│ └── events # Événements nettoyés
├── gold/
│ ├── dim_customers # Dimension : clients
│ ├── dim_products # Dimension : produits
│ ├── dim_date # Dimension : date
│ ├── fact_orders # Fait : commandes
│ └── agg_daily_sales # Agrégat : ventes quotidiennes
└── quarantine/
├── orders_failed # Enregistrements rejetés
└── events_failedAstuce
Séparer bases/schemas
Ne vous contentez pas de préfixes (raw_, silver_, gold_). Utilisez des bases ou schémas distincts pour appliquer droits d’accès, politiques de stockage et rétention propres à chaque couche.
7. Checklist de bonnes pratiques
Ne jamais supprimer en Bronze
Écritures append-only. Une correction = un nouvel enregistrement. Bronze est votre piste d’audit.
Investir dans Silver
La qualité vit ici. Déduplication, enforcement de schéma et standardisation doivent être solides.
Garder Gold simple
Les tables Gold doivent être faciles à requêter. Pré-joins, pré-agrégations, optimisation pour le consommateur.
Tout documenter en Gold
Chaque table Gold doit avoir : propriétaire, description, définition des colonnes, fréquence, SLA.
Traiter en incrémental
Ne traiter que le nouveau/changé. Les full refresh coûtent cher à l’échelle.
Mettre les données invalides en quarantaine
Ne pas supprimer silencieusement. Router vers une table de quarantaine pour investigation.
Tester à chaque couche
Tests qualité Bronze → Silver (schéma), Silver → Gold (règles métier), Gold (métriques).
Contrôler l’accès par couche
Bronze : data engineers. Silver : équipe data. Gold : utilisateurs métier et dashboards.
Retours terrain
Les équipes en difficulté voient souvent la medallion comme une migration ponctuelle, pas une architecture continue. Chaque couche doit avoir un owner, de la maintenance et des améliorations régulières.
8. Questions fréquentes
Qu’est-ce que l’architecture medallion ?
Un modèle qui organise les données en trois couches : Bronze (brut), Silver (nettoyé et conformé) et Gold (agrégats métier). Il améliore la qualité progressivement dans le lakehouse.
Quelle différence entre Bronze, Silver et Gold ?
Bronze : données brutes. Silver : données nettoyées, dédupliquées, conformées. Gold : agrégats et métriques métier pour dashboards et modèles ML.
Quand utiliser l’architecture medallion ?
Quand vous avez plusieurs sources, besoin d’améliorer la qualité par étapes, de supporter batch/streaming, ou de servir divers consommateurs.
Est-ce réservé à Databricks ?
Non. Le pattern fonctionne sur Snowflake, BigQuery, Redshift ou des stacks open source (Delta Lake, Apache Iceberg, Apache Hudi). Brut → Nettoyé → Agrégé reste valable partout.
Visualisez votre architecture medallion
Créez des diagrammes clairs montrant les couches Bronze, Silver et Gold. Documentez flux, transformations et ownership en quelques minutes.