1. Was ist die Medaillon-Architektur?
Medaillon-Architektur ist ein Daten-Design-Pattern, das dein Lakehouse in drei aufeinanderfolgende Schichten gliedert: Bronze (roh), Silver (bereinigt) und Gold (business-ready). Jede Schicht verbessert die Datenqualität und bringt dich näher zum Geschäftswert.
Die Kernidee
Bronze
Roh, wie angeliefert
Silver
Bereinigt, konform
Gold
Geschäftsbereit
Warum nicht einmalig bereinigen?
Weil sich Anforderungen ändern. Rohdaten im Bronze-Layer erlauben Reprocessing, wenn Geschäftslogik sich wandelt. Teams, die Bronze überspringen, müssen oft neu ingestieren, wenn Stakeholder „die Daten vor dem Filter" sehen wollen.
Wann du die Medaillon-Architektur nutzen solltest:
Viele Datenquellen
Wenn du aus 10+ Quellen mit unterschiedlichen Formaten, Schemata und Qualitäten ingestierst.
Unterschiedliche Konsumenten
Wenn Data Scientists Rohdaten brauchen, Analysten saubere Daten und Dashboards Aggregate.
Sich ändernde Anforderungen
Wenn Geschäftslogik oft wechselt und du historische Daten neu verarbeiten können musst.
Compliance-Anforderungen
Wenn du Audit-Trails, Datenlineage und Nachweise brauchst, wie Daten zu jedem Zeitpunkt aussahen.
Aus der Praxis
Bei Medaillon geht es nicht um den Namen, sondern um das Prinzip: Rohdaten nicht verlieren, Qualität schrittweise verbessern und die richtige Abstraktion für den richtigen Konsumenten liefern. Nenne deine Layer „raw/staging/marts" oder „landing/curated/consumption" – das Pattern zählt.
2. Die drei Schichten erklärt
Jede Schicht hat Zweck, Owner und Qualitätsniveau. Dieses Denkmodell macht Medaillon wirksam.
| Layer | Zweck | Qualitätslevel | Konsumenten |
|---|---|---|---|
| 🥉 Bronze | Rohdaten exakt landen | Keines – alles behalten | Data Engineers, Debugging |
| 🥈 Silver | Bereinigen, deduplizieren, Schemata konform machen | Validiert, typisiert, konsistent | Data Scientists, Advanced Analysts |
| 🥇 Gold | Geschäftliche Aggregate und Kennzahlen | Business-abgenommen, dokumentiert | Dashboards, Reports, Anwendungen |
Schlüsselprinzipien für jede Transition:
Bronze zu Silver
Bereinigen und konform machen
Datenduplikate entfernen, Datentypen casten, Schema erzwingen, ungültige Records filtern, Formate standardisieren (Datum, Währung, Codes).
Silver zu Gold
Aggregieren und anreichern
Tabellen joinen, Business-KPIs berechnen, Geschäftslogik anwenden, dimensionale Modelle erstellen, für Abfragepattern optimieren.
Pro Tipp
Überspringe Silver nicht
Von Bronze direkt zu Gold zu springen ist verlockend, aber Silver ist der Ort der Datenqualität. Ohne Silver duplizierst du Bereinigung in jedem Gold-Table – Änderungen werden teuer und fehleranfällig.
3. Bronze-Layer Deep Dive
Bronze ist dein „Datenlake" im wahrsten Sinne: alles landet hier, exakt wie es ankam. Ziel ist Haltbarkeit und Nachvollziehbarkeit, nicht Sauberkeit.
Bronze sollte haben
- • Rohdaten exakt wie empfangen (JSON, CSV, Parquet)
- • Ingestion-Metadaten (Timestamp, Source File, Batch ID)
- • Append-only Writes (keine Updates oder Deletes)
- • Partitionierung nach Ingestion-Datum
- • Lange Aufbewahrung (Monate bis Jahre)
Bronze sollte NICHT haben
- • Schema-Enforcement (lass schlechte Daten rein)
- • Daten-Transformationen
- • Deduplizierungslogik
- • Geschäftslogik oder Berechnungen
- • Zugriff durch Business-User
Struktur einer Bronze-Tabelle:
Beispiel: Bronze-Orders-Tabellenschema
-- 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)
Füge jeder Zeile Ingestion-Metadaten hinzu
Timestamp, Quelldatei, Batch-ID. Brauchst du fürs Debugging und Reprocessing.
Nutze Append-only Writes
Nie UPDATE oder DELETE in Bronze. Korrekturen sind neue Records mit neuem Timestamp.
Nach Ingestion-Datum partitionieren
Erleichtert Reprocessing bestimmter Zeiträume und Retention-Management.
Günstig halten
Komprimierte Formate (Parquet, ORC) nutzen und kalte Storage-Tiers für ältere Partitionen.
4. Silver-Layer Deep Dive
Silver ist der Ort der eigentlichen Arbeit. Hier liegt die Enterprise-Source-of-Truth für saubere, validierte Entitätsdaten.
Aufgaben des Silver-Layers:
Schema-Enforcement
Typen casten, NOT NULL erzwingen, Formate validieren. Schlechte Records in Quarantäne-Tabellen schreiben.
Deduplizierung
Duplikate entfernen. Business Keys + Timestamp nutzen, um die neueste Version zu behalten.
Standardisierung
Daten auf ISO-Datum, Basiswährung, standardisierte Codes normalisieren.
Data-Quality-Checks
Automatisierte Tests: Null-Raten, Eindeutigkeit, referentielle Integrität, Wertebereiche.
Beispiel: Silver-Orders-Transformation (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 cleanedAus der Praxis
Silver ist der Ort, an dem die meisten Teams unterinvestieren. Sie sprinten zu Gold und duplizieren Bereinigung überall. Investiere in Silver – es zahlt sich in jedem Downstream-Modell aus.
5. Gold-Layer Deep Dive
Gold ist der Ort des Business-Value. Das sind die Tabellen, die Stakeholder wirklich abfragen. Denke an dimensionale Modelle, Metriken und Use-Case-spezifische Aggregate.
Typische Gold-Patterns:
Dimensionale Modelle (Star Schema)
Fact-Tabellen (Events, Transaktionen) umgeben von Dimensionen (Kunden, Produkte, Zeit). Optimiert für BI und Ad-hoc-Queries.
Beispiel:
fact_orders ← dim_customers, dim_products, dim_dateVoraggregierte Kennzahlen
Tägliche/wöchentliche/monatliche Rollups für Dashboards. Schnellere Queries, geringere Compute-Kosten.
Beispiel:
daily_revenue_by_region, weekly_active_users, monthly_churn_ratesFeature Tables (ML)
Vorgefertigte Features für ML-Modelle. Point-in-Time korrekt, versioniert.
Beispiel:
customer_features, product_embeddings, user_activity_signalsBeispiel: Gold-Fact-Tabelle (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_dayGold-Prinzip
Für Queries optimieren
Nach häufigen Filterspalten (Datum, Region) partitionieren. Nach Join-Keys clustern.
Gold-Prinzip
Geschäftslogik dokumentieren
Jede Gold-Tabelle braucht klare Definitionen der Metriken.
Gold-Prinzip
Sorgfältig versionieren
Änderungen in Gold können Dashboards brechen. Nutze semantische Versionierung oder Aliasse.
6. Implementierungsmuster
Medaillon funktioniert auf jeder modernen Plattform. So setzt du es mit gängigen Stacks um.
| Plattform | Bronze | Silver/Gold | Format |
|---|---|---|---|
| Databricks | Unity Catalog | Delta Lake + dbt | Delta |
| Snowflake | RAW-Datenbank | dbt + Snowflake | Native Tabellen |
| BigQuery | raw_-Dataset | dbt + BQ | Native Tabellen |
| AWS (Open) | S3 + Glue | Spark + dbt | Iceberg/Hudi |
Ordner/DB-Struktur:
# Typische Namenskonvention
catalog/
├── bronze/
│ ├── raw_orders
│ ├── raw_customers
│ ├── raw_products
│ └── raw_events
├── silver/
│ ├── orders # Bereinigte Orders
│ ├── customers # Bereinigte Kunden
│ ├── products # Bereinigte Produkte
│ └── events # Bereinigte Events
├── gold/
│ ├── dim_customers # Dimension: Kunden
│ ├── dim_products # Dimension: Produkte
│ ├── dim_date # Dimension: Datum
│ ├── fact_orders # Fakt: Orders
│ └── agg_daily_sales # Aggregat: täglicher Umsatz
└── quarantine/
├── orders_failed # Records, die Validierung failen
└── events_failedPro Tipp
Getrennte Datenbanken/Schemas nutzen
Nutze nicht nur Präfixe (raw_, silver_, gold_). Verwende getrennte DBs/Schemas, um unterschiedliche Zugriffsrechte, Storage-Policies und Retention-Regeln pro Layer anzuwenden.
7. Best-Practice-Checkliste
In Bronze nie löschen
Append-only Writes. Korrekturen = neuer Record. Bronze ist dein Audit-Trail.
Stark in Silver investieren
Hier lebt Datenqualität. Dedupe, Schema-Enforcement und Standardisierung müssen sitzen.
Gold einfach halten
Gold-Tabellen müssen leicht querybar sein. Pre-Join, pre-aggregieren, für Konsumenten optimieren.
Gold dokumentieren
Jede Gold-Tabelle braucht: Owner, Beschreibung, Spaltendefinitionen, Refresh-Plan, SLA.
Inkrementell verarbeiten
Nur neue/geänderte Daten verarbeiten. Full-Refresh ist teuer und langsam bei Scale.
Schlechte Records quarantänen
Schlechte Daten nicht still droppen. In Quarantäne-Tabellen zur Untersuchung leiten.
Auf jeder Schicht testen
DQ-Checks bei Bronze → Silver (Schema), Silver → Gold (Business-Regeln), Gold (Metriken).
Zugriff pro Layer steuern
Bronze: nur Data Engineers. Silver: Data-Team. Gold: Business-User und Dashboards.
Aus der Praxis
Teams scheitern an Medaillon meist, weil sie es als einmalige Migration sehen statt als laufende Architektur. Jede Schicht braucht Ownership, Pflege und kontinuierliche Verbesserungen.
8. Häufige Fragen
Was ist die Medaillon-Architektur?
Die Medaillon-Architektur ist ein Daten-Design-Pattern mit drei Schichten: Bronze (Rohdaten), Silver (bereinigt und konform) und Gold (geschäftliche Aggregate). Sie strukturiert den Lakehouse so, dass Datenqualität schrittweise steigt.
Was unterscheidet Bronze, Silver und Gold?
Bronze enthält rohe, unveränderte Daten. Silver enthält bereinigte, deduplizierte, konforme Daten mit Standardschemata. Gold enthält geschäftliche Aggregate und Metriken für Dashboards und ML-Modelle.
Wann sollte ich die Medaillon-Architektur einsetzen?
Wenn du viele Quellen hast, Datenqualität stufenweise verbessern musst, Batch und Streaming unterstützen willst oder unterschiedliche Konsumenten bedienst.
Ist die Medaillon-Architektur nur für Databricks?
Nein. Das Pattern funktioniert auf Snowflake, BigQuery, Redshift oder Open-Source mit Delta Lake, Apache Iceberg oder Apache Hudi. Roh → Bereinigt → Aggregiert gilt überall.
Visualisiere deine Medaillon-Architektur
Erstelle klare Diagramme für Bronze-, Silver- und Gold-Layer. Dokumentiere Datenflüsse, Transformationen und Ownership in Minuten.