Un modèle de conception de données en couches qui affine progressivement les données brutes en insights propres et prêts pour le métier, en passant par les couches Bronze, Silver et Gold.
Principes de conception
L'architecture Medallion repose sur un ensemble de principes d'ingénierie pratiques qui reflètent les besoins réels des équipes data :
- Découplage, Séparer les données en couches préserve la flexibilité. Les changements dans un système source ne se répercutent pas en cascade sur votre couche de reporting.
- Reporting opérationnel et analytique, Les équipes applicatives ont souvent besoin d'insights en temps quasi réel à partir des données opérationnelles, qui peuvent à leur tour servir à améliorer les systèmes opérationnels eux-mêmes.
- Rétention historique, Les équipes doivent conserver les données pendant des années, pour l'analyse de tendances, l'amélioration de la qualité et la capacité de recharger ou retraiter lorsque les pipelines changent.
- Intégration, Les questions métier vivent rarement dans un seul système. Combiner des données de plusieurs sources en perspectives intégrées est une raison fondamentale de l'existence de l'architecture.
- Duplication pour la performance, Différentes équipes ont des schémas de lecture et des exigences de performance différents. Dupliquer les données entre les couches (par ex. une table Gold résumée à côté d'une table Silver détaillée) est intentionnel, pas du gaspillage.
Pourquoi diviser les données en couches ?
Le principe reflète la pensée classique du data warehouse (Inmon, Kimball, Data Vault). Medallion offre à ces idées de séparation des responsabilités un foyer moderne et natif au lakehouse. Les équipes ont besoin de données historiques pour l'audit et le rechargement, de vues intégrées pour l'analytique et de lectures optimisées pour la performance pour le reporting, souvent simultanément. Le découpage en couches rend chaque préoccupation gérable indépendamment.
Les trois couches
🟤 Bronze, Brut, « as-is » La zone d'atterrissage. Les données sont ingérées telles quelles, immuables, et stockées dans leurs formats d'origine (CSV, JSON, Parquet) avant d'être converties en Delta. Enrichies de métadonnées comme les horodatages d'ingestion et les libellés de source. Prend en charge le batch et le streaming, et est précieuse pour le débogage et les rechargements historiques.
⚪ Silver, Nettoyé et filtré Les règles de qualité des données sont appliquées ici : correction des dates, suppression des caractères spéciaux, correction des erreurs de format. L'historisation est généralement gérée avec SCD2. La structure reste orientée source mais est interrogeable et utilisée par les équipes d'analytique opérationnelle. Les colonnes sont renommées pour la lisibilité et de légères conformations aux standards d'entreprise sont appliquées.
🟡 Gold, Raffiné au niveau métier Les données sont harmonisées et intégrées entre les sources, généralement modélisées selon le style dimensionnel Kimball (faits et dimensions). Les règles métier complexes, les calculs et les enrichissements vivent ici. La sortie consiste en produits de données prêts à consommer, avec rétrocompatibilité et contrats de données pour les utilisateurs en aval.
Exemple pratique : analyse unifiée du ROI publicitaire
La question métier : Une entreprise e-commerce en croissance veut comprendre l'impact des dépenses marketing sur l'ensemble des canaux. Le projet : une analyse de ROI unifiée pour des campagnes publicitaires multicanales.
Sources de données : Facebook Ads and Google Ads.
Exigences de reporting : Coût, impressions, clics, ventilés par annonce, campagne, attribution (fenêtre d'un jour) et données démographiques (âge, genre, appareil, plateforme).
Bronze : tout charger
Facebook Insights expose 134 champs plus des combinaisons de paramètres supplémentaires. Google Ads expose 329 champs. La recommandation est simple : charger tout ce que les API renvoient.
- Inconvénient : Plus de stockage utilisé, mais le stockage est bon marché.
- Avantage : Vous évitez la classique « Ce rapport est génial ! Pouvez-vous juste ajouter ce champ supplémentaire ? » conversation.
Les transformations à ce stade sont minimales : supprimer les enregistrements corrompus ou inutilisables, convertir au format Delta, enrichir de métadonnées (source, horodatage d'ingestion) et partitionner par date uniquement si le volume de données devient un goulot d'étranglement.
Silver : trois options de modélisation
C'est ici que se prennent les vraies décisions de conception. Facebook et Google utilisent des noms de champs différents pour les mêmes concepts, cost_micros vs spend, ad_group vs adset, segments.age_range vs age, et certains champs n'existent tout simplement pas sur les deux plateformes.
Option 1, deux tables sources distinctes Conservez une table silver Facebook et une table silver Google, chacune nettoyée et renommée selon une convention de nommage commune. Simple à construire, préserve la nuance des sources, mais nécessite un join ou une union plus tard.
Option 2, une table ads unifiée Mappez les deux sources dans une seule table partagée au niveau Silver. Plus simple pour les consommateurs en aval. Important : documentez clairement les décisions de mapping, adset et ad_group ne sont pas des concepts identiques.
Option 3, Data Vault Modélisez les entités en Hubs, les relations en Links et les métriques en Satellites. Plus modulaire et meilleur pour suivre l'évolution des relations dans le temps. Le mieux adapté aux plateformes de données d'entreprise complexes et durables.
Gold : deux options de service
Option A, modèle dimensionnel (Kimball) Construisez une table Fact_Ad_Performance jointe à des tables de dimensions. Propre, bien comprise par les outils BI et facile à découper. C'est l'approche la plus courante.
Option B, One Big Table (OBT) Dénormalisez tout dans une seule table large. Plus facile pour les analystes et le reporting self-service, aucun join nécessaire.
Défis
Gouvernance des données, Tout stocker dans Bronze peut devenir un problème RGPD. Les droits d'accès nécessitent des politiques claires, surtout lorsque les tables silver contiennent des données personnelles issues de plusieurs systèmes sources.
Le facteur humain, Medallion est un cadre de nommage, pas un règlement. Sans accords d'équipe documentés sur ce qui appartient à chaque couche, l'architecture se dégrade en incohérence et en pipelines fantômes.
Points clés à retenir
- Chargez tout vers Bronze, le stockage est bon marché, mais il coûte cher de manquer un champ plus tard.
- Silver doit nettoyer et conformer ; Gold doit modéliser et intégrer, résistez à la tentation de fusionner ces responsabilités.
- Les choix de modélisation au niveau Silver (tables plates vs Data Vault) ont des conséquences durables en aval.
- Documentez vos contrats de couche. La cohérence entre les équipes dépend d'accords écrits et partagés.
L'architecture Medallion paraît simple sur un diagramme, mais les vraies décisions de conception, surtout au niveau de la couche Silver, peuvent avoir des conséquences durables. Si vous voulez réfléchir à la bonne approche pour votre situation, n'hésitez pas à réserver un rendez-vous.
