Datenplattform-Guide

Medaillon-Architektur

Bronze, Silver, Gold – das Muster, mit dem du chaotische Daten schnell ingestest, sie schrittweise bereinigst und business-fertige Datensätze bereitstellst. Dieser Guide zeigt, wie du die Medaillon-Architektur ohne Over-Engineering umsetzt.

22 Min LesezeitFür Data- & Platform-EngineersMit Codebeispielen

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.

LayerZweckQualitätslevelKonsumenten
🥉 BronzeRohdaten exakt landenKeines – alles behaltenData Engineers, Debugging
🥈 SilverBereinigen, deduplizieren, Schemata konform machenValidiert, typisiert, konsistentData Scientists, Advanced Analysts
🥇 GoldGeschäftliche Aggregate und KennzahlenBusiness-abgenommen, dokumentiertDashboards, 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:

1

Schema-Enforcement

Typen casten, NOT NULL erzwingen, Formate validieren. Schlechte Records in Quarantäne-Tabellen schreiben.

2

Deduplizierung

Duplikate entfernen. Business Keys + Timestamp nutzen, um die neueste Version zu behalten.

3

Standardisierung

Daten auf ISO-Datum, Basiswährung, standardisierte Codes normalisieren.

4

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 cleaned

Aus 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_date

Voraggregierte 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_rates

Feature Tables (ML)

Vorgefertigte Features für ML-Modelle. Point-in-Time korrekt, versioniert.

Beispiel:

customer_features, product_embeddings, user_activity_signals

Beispiel: 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_day

Gold-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.

PlattformBronzeSilver/GoldFormat
DatabricksUnity CatalogDelta Lake + dbtDelta
SnowflakeRAW-Datenbankdbt + SnowflakeNative Tabellen
BigQueryraw_-Datasetdbt + BQNative Tabellen
AWS (Open)S3 + GlueSpark + dbtIceberg/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_failed

Pro 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.