Medallion-Architektur-Diagramm: Bronze-, Silber- und Gold-Schicht

Jede Datenplattform wächst irgendwann zu einem Sumpf heran: fünf Tabellen namens orders, niemand ist sicher, welche Finance nutzt, und ein Dashboard ist kaputt, weil jemand upstream einen Bug behoben hat. Die Medallion-Architektur ist eine einfache Antwort auf dieses Durcheinander. Sie gliedert ein Lakehouse in drei Schichten, Bronze, Silber und Gold, jede mit einem klaren Vertrag darüber, wie vertrauenswürdig ihre Daten sind und wer sie nutzen darf.

Die Idee ist beliebt, weil sie leicht zu erklären ist, und wird oft falsch angewendet, weil sie leicht zu erklären ist. Dieser Beitrag behandelt, was jede Schicht enthält und was nicht, wie Daten zwischen ihnen fließen, Datenqualitätsprüfungen, Neuverarbeitung, Governance, die typischen Fallstricke und wann du das Muster gar nicht brauchst, mit einem Diagramm, das du anpassen kannst.

Die drei Schichten auf einen Blick

Der Name stammt von Databricks, dessen Dokumentation die Schichten als roh, validiert und angereichert beschreibt. In der Praxis:

Lies die Schichten als Qualitätsvertrag, nicht als Zahl von Verarbeitungsschritten. Bronze verspricht Vollständigkeit, Silber Korrektheit und Gold Nützlichkeit für ein benanntes Publikum.

Bronze: alles behalten, nichts ändern

In Bronze landen die Rohdaten: Dateien aus dem Objektspeicher, Kafka-Topics, Change-Data-Capture-Streams aus operativen Datenbanken, Exporte aus SaaS-Tools. Die Regeln:

• Nur anhängen. Aktualisiere oder lösche Bronze-Datensätze im normalen Betrieb nie.
• Minimales Parsen. Databricks empfiehlt, die meisten Felder in Bronze als String, Variant oder Binärwert zu speichern, damit eine unerwartete Schemaänderung upstream keine Daten verwirft.
• Metadaten ergänzen: Ingestion-Zeit, Quellsystem, Dateiname oder Topic-Offset. Du brauchst sie fürs Debugging und für Replays.
• Lange genug aufbewahren, um neu aufbauen zu können. Die Aufbewahrung in Bronze bestimmt, wie weit zurück du Silber und Gold nach einem Bugfix neu berechnen kannst.

Bronze enthält alles, auch personenbezogene Daten, die du später lieber nicht kopiert hättest. Beschränke den Zugriff auf Pipelines und erwäge, sensible Felder beim Ingest zu tokenisieren oder zu verschlüsseln. Das DSGVO-Datenmapping-Diagramm hilft, nachzuverfolgen, wohin personenbezogene Daten fließen.

Silber: korrekt machen

In Silber steckt der größte Teil des Engineering-Aufwands:

• Felder parsen und typisieren, Zeitstempel auf UTC normalisieren und Einheiten und Codes vereinheitlichen.
• Datensätze deduplizieren, die doppelt angekommen sind, was bei jeder At-least-once-Quelle passiert.
• Änderungen anwenden. Bei Change-Data-Capture-Quellen Inserts, Updates und Deletes in eine Tabelle mit dem aktuellen Stand mergen.
• Schlüssel vereinheitlichen, damit ein Kunde dieselbe Kennung hat, ob er aus dem CRM oder aus dem Billing-System kommt.
• In Quarantäne stellen statt verwerfen. Zeilen, die die Validierung nicht bestehen, landen mit dem Grund in einer Quarantänetabelle, wo jemand sie sehen kann.

Ein typischer Silber-Merge mit Delta Lake oder Apache Iceberg in Spark SQL behält nur die neueste Version jeder Bestellung:

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Datenqualitätsregeln gehören an diese Grenze. Databricks-Pipelines etwa deklarieren sie als Expectations, die warnen, die betroffenen Zeilen verwerfen oder das Update fehlschlagen lassen:

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

Welches Tool du auch nutzt: Mach die Regeln sichtbar und zähl die Zeilen, die sie ablehnen.

Gold: nützlich machen

Gold-Tabellen werden für Konsumenten gebaut: ein Sternschema fürs Finance-Reporting, Tagesumsatz nach Region fürs Management-Dashboard, Kundenmerkmale für ein Churn-Modell. Jede Gold-Tabelle sollte einen Owner, eine dokumentierte Definition und ein Aktualitätsziel haben. Metrikdefinitionen wie „aktiver Kunde“ oder „Nettoumsatz“ gehören hierher, einmal geschrieben, nicht in jedem Dashboard neu implementiert.

In Gold wird auch für Geschwindigkeit denormalisiert und aggregiert. Silber behält das Detail; Gold beantwortet Fragen.

Batch, Streaming oder beides

Die Schichten schreiben keine Latenz vor. Jeder Schritt kann als nächtlicher Batch, als stündlicher inkrementeller Job oder als kontinuierlicher Stream mit Checkpoints laufen. Viele Teams streamen aus den Quellen nach Bronze und Silber, damit Daten innerhalb von Minuten aktuell sind, und aktualisieren Gold-Aggregate nach einem Zeitplan, der dazu passt, wie oft jemand hinschaut. Verarbeite inkrementell, wo immer es geht: Nur die seit dem letzten Lauf neuen Bronze-Daten zu lesen, hält die Kosten flach, während die Daten wachsen.

Neuverarbeitung und Historie

Weil Bronze unveränderlich ist, lässt sich ein Bug in der Silber-Logik beheben: Code korrigieren, die betroffenen Silber-Partitionen aus Bronze neu aufbauen, dann Gold neu aufbauen. Tabellenformate wie Delta Lake und Iceberg ergänzen Snapshots, sodass du eine Tabelle im Stand von gestern abfragen, eine Änderung prüfen oder einen fehlerhaften Load zurückrollen kannst. Plane das von Anfang an ein: Halte Transformationen deterministisch und partitioniere Tabellen so, dass der Neuaufbau eines Monats nicht den Neuaufbau von allem bedeutet.

Governance pro Schicht

Leg jede Schicht in ein eigenes Schema in deinem Katalog, zum Beispiel ops.bronze, ops.silver und ops.gold, das Layout, das Databricks in seinem eigenen Beispiel verwendet. Vergib dann Zugriff pro Schicht: Pipelines schreiben Bronze, Engineers und Analysten lesen Silber, und der Großteil des Unternehmens liest nur Gold. Lineage über die Schichten hinweg beantwortet die Frage, die während eines Incidents alle stellen: Welche Dashboards hängen von dieser kaputten Quelle ab?

Fallstricke

• Drei als Regel behandeln. Manche Quellen brauchen mehr Schritte, manche weniger. Es zählt der Vertrag, nicht die Zahl der Schritte.
• Geschäftslogik in Silber. Silber sollte von vielen Konsumenten wiederverwendbar sein. Logik, die einem einzigen Report dient, gehört nach Gold.
• Gold als Abladeplatz. Ohne Owner füllt sich Gold mit Einmal-Tabellen, die niemand pflegt. Überprüfe sie und leg sie still.
• Alles dreimal kopieren. Große Roh-Datensätze in drei Formen zu speichern, kostet echtes Geld. Beschränke Silber auf die Spalten und die Historie, die wirklich gebraucht werden.
• Quarantäne weglassen. Stillschweigend verworfene Zeilen sind der Grund, warum Zahlen abdriften, ohne dass es jemand merkt.

Wann Medallion zu viel ist

Wenn deine Daten bequem in ein Cloud Data Warehouse passen und aus einer Handvoll Quellen kommen, brauchst du vielleicht gar kein Lakehouse. Die verbreitete dbt-Konvention aus Staging, Intermediate und Marts drückt dieselbe Idee zunehmender Verfeinerung innerhalb eines Warehouse aus:

Die Namen sind weniger wichtig als die Disziplin: Rohdaten bleiben unangetastet, es gibt eine saubere Version jeder Entität und zweckgebundene Tabellen mit Ownern.

Das Medallion-Diagramm

So liest du es:

• Quellen links: Änderungsdaten aus Postgres, Events aus Kafka und ein CRM-Export.
• Drei farbige Rahmen sind die Schichten. Bronze enthält Rohdateien, Silber bereinigte Tabellen und einen Quarantänespeicher, Gold Geschäftstabellen.
• Kanten zwischen den Rahmen sind Pipeline-Schritte, beschriftet mit dem, was sie tun: parsen, deduplizieren, mergen, aggregieren.
• Konsumenten rechts: BI-Dashboards und ein Feature Store für Machine Learning lesen nur aus Gold.
• Der Markdown-Block listet den Vertrag jeder Schicht.

Datenplattformen zeichnen, in denen man sich zurechtfindet

• Färbe die Schichten ein. Bronze, Silber und Gold bleiben gerade deshalb im Gedächtnis, weil sie visuell sind; nutze die Farben.
• Beschrifte jeden Schritt mit seiner Operation, nicht nur mit einem Pfeil. „Deduplizieren und mergen“ sagt einem Reviewer, wo er nach einem Bug suchen muss.
• Zeig, wer was liest. Zugriff pro Schicht ist eine Designentscheidung, und das Diagramm sollte klarmachen, dass Dashboards nie Bronze lesen.
• Zeichne den Quarantänepfad ein. Er zeigt Reviewern, wohin abgelehnte Daten gehen.

Die größere Pipeline rund um das Lakehouse behandelt das Datenpipeline-Architekturdiagramm, die Streaming-Quellen das Kafka-Architekturdiagramm und die ML-Konsumenten das MLOps-Architekturdiagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge als Quellen einen Postgres-Node und einen Kafka-Node aus dem Daten-Pack hinzu, außerdem ein Externes System aus dem C4-Modell-Pack für das CRM.
3. Füge drei Rahmen-Nodes aus dem Basis-Pack namens Bronze, Silver und Gold hinzu, passend eingefärbt.
4. Füge in Bronze eine Objektablage aus dem Daten-Pack für Rohdateien hinzu. Füge in Silber einen Datenlager-Node für bereinigte Tabellen und eine Objektablage für die Quarantäne hinzu. Füge in Gold einen weiteren Datenlager-Node für Geschäftstabellen hinzu.
5. Füge als Konsumenten einen Kasten aus dem Basis-Pack für BI-Dashboards und einen Merkmalsspeicher aus dem ML-Pack hinzu.
6. Beschrifte die Kanten mit jedem Schritt und füge einen Markdown-Block aus dem Basis-Pack mit den Regeln der Schichten hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist die Medallion-Architektur? Eine Art, ein Lakehouse in drei Schichten zunehmender Qualität zu gliedern: Bronze für Rohdaten, wie sie ankommen, Silber für bereinigte und vereinheitlichte Daten und Gold für geschäftsfertige Tabellen, die für bestimmte Zwecke gebaut sind.

Was ist der Unterschied zwischen Silber und Gold? Silber enthält korrekte, wiederverwendbare Daten auf Detailebene, eine Tabelle pro Entität oder Event-Typ. Gold enthält Tabellen, die für einen Zweck geformt sind, etwa Aggregate, Sternschemata oder ML-Features, mit Owner und Definitionen.

Sollten Bronze-Daten jemals verändert werden? Nicht im normalen Betrieb. Bronze ist append-only, damit du alles downstream neu aufbauen kannst. Ausnahmen sind gesetzliche Löschanfragen und Aufbewahrungsfristen, die einen eigenen Prozess brauchen.

Ist die Medallion-Architektur nur etwas für Databricks? Nein. Der Name stammt von Databricks, aber das Muster funktioniert mit jedem Lakehouse oder Warehouse: Delta Lake, Apache Iceberg, Snowflake oder BigQuery, mit Spark, dbt oder anderen Tools.

Brauche ich immer drei Schichten? Nein. Nutze so viele Schritte, wie deine Quellen brauchen. Wichtig sind eine unangetastete Rohkopie, eine saubere Version jeder Entität und zweckgebundene Tabellen mit Ownern.

Kostenlos starten — ein Seat, keine Kreditkarte.