Medallion-Architektur: Bronze, Silver und Gold als Qualitäts-Verträge, mit Beispiel und Grenzen
Bronze, Silver und Gold sind schnell angelegt: verlässlich werden sie erst mit klaren Qualitäts-Verträgen, Verantwortlichkeiten und Leserechten pro Schicht.
Die Kernaussagen auf einen Blick.
- Die Medallion-Architektur organisiert Lakehouse-Daten in drei Schichten: Bronze für Rohdaten, Silver für bereinigte Daten, Gold für konsumfertige Sichten.
- Das Modell wirkt auf den ersten Blick einfach, erfordert aber für jede Schicht klare Regeln zu Qualität, Verantwortung und Nutzung.
- Vor der Umsetzung der ersten Pipelines sollten drei Punkte festgelegt werden: Schichten-Zuschnitt, Qualitäts-Vertrag pro Schicht und Leserechte der Konsumenten.
- Mein Vorschlag: Für jede Schicht Qualitätsanforderungen, Verantwortlichkeiten und zulässige Nutzungsformen dokumentieren und mit einer einzigen Strecke von der Quelle bis zum Report starten.
Inhaltsverzeichnis
Warum Bronze, Silver und Gold allein noch keine Architektur ergeben
Im Plattform-Review sind die Kataloge klar in Bronze, Silver und Gold gegliedert. Die Struktur entspricht auf den ersten Blick dem üblichen Medallion-Modell. Zwei Vertriebsberichte greifen dennoch direkt auf Bronze-Daten zu, weil der vorgesehene kuratierte Weg nicht rechtzeitig verfügbar war. Eine Domäne dedupliziert ihre Kundendaten in Silver, eine andere Domäne führt dieselbe Bereinigung dagegen erst in der Gold-Schicht durch. Entsprechend ist nicht eindeutig geklärt, welche Tabelle als verbindliche Grundlage für die Umsatzkennzahl gilt.
Diese Situation tritt häufig auf, sobald mehrere Teams auf dasselbe Lakehouse bauen. Die technische Struktur ist schnell angelegt, während verbindliche Regeln für Qualität und Nutzung oft fehlen.
Was muss eine Tabelle erfüllen, damit sie Silver heißen darf? Welches Team ist verantwortlich, wenn sich eine Gold-Kennzahl unerwartet verändert? Unter welchen Bedingungen dürfen Analysten direkt auf Bronze-Daten zugreifen? Braucht jede Quelle alle drei Schichten?
An diesen Fragen entscheidet sich, ob das Schichtenmodell tatsächlich verlässliche Daten schafft oder lediglich technische Ebenen benennt. Bronze, Silver und Gold sollten deshalb als klar definierte Qualitätsstufen verstanden werden und nicht nur als Verzeichnisnamen.
Was ist die Medallion-Architektur?
Die Medallion-Architektur ist ein Modell zur schrittweisen Organisation und Aufbereitung von Daten innerhalb eines Lakehouse. Sie führt Daten durch drei aufeinander aufbauende Schichten: Bronze enthält die weitgehend unveränderten Daten aus den Quellsystemen. Silver stellt bereinigte, vereinheitlichte und systemübergreifend abgestimmte Daten bereit. Gold enthält fachlich modellierte Daten für konkrete Berichte, Analysen und KI-Anwendungen. Im Deutschen wird der Begriff teilweise auch als Medaillon-Architektur verwendet, daneben als Multi-Hop-Architektur, weil Daten mehrere Stationen durchlaufen; beide Bezeichnungen beschreiben dasselbe Schichtenmodell.
Databricks hat den Begriff seit etwa 2019 wesentlich geprägt und verbreitet, im englischen Original als medallion architecture. Der Hersteller beschreibt sie als Datendesign-Muster mit drei Qualitätsstufen, mit dem Ziel, die Datenqualität von Schicht zu Schicht schrittweise zu verbessern. Das Muster ist plattformneutral und wird ebenso in Microsoft Fabric oder anderen Lakehouse-Umgebungen eingesetzt.
Das Modell ordnet Datenqualität konkreten Verarbeitungsschritten und Verantwortlichkeiten zu. Für jede Schicht lässt sich definieren, welchen Qualitätszustand Nutzer dort erwarten können. Qualitätsprobleme lassen sich dadurch einer konkreten Schicht und Verantwortung zuordnen. Es legt jedoch weder das konkrete Datenmodell noch Berechtigungen oder Ownership automatisch fest.
Wie das Data Lakehouse Speicher, offene Formate und Konsum zusammenbringt, zeigen wir im Überblick zum Lakehouse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was leisten Bronze, Silver und Gold?
Jede Schicht sollte als verbindlich definierte Qualitätsstufe verstanden werden: Sie beschreibt, welche Eigenschaften die Daten erfüllen und wer für deren Einhaltung verantwortlich ist. Microsoft Learn beschreibt die drei Ebenen als Stufen, deren Struktur und Qualität schrittweise zunehmen, je weiter die Daten Richtung Konsum wandern.
Bronze → Silver → Gold: Datenqualität in drei Stufen.
Drei Schichten mit steigender Qualität und Aggregation. Bronze hält Rohdaten append-only; Silver validiert und standardisiert; Gold liefert business-ready Aggregate mit SLAs.
Bronze übernimmt die Daten möglichst unverändert aus den Quellsystemen. Die Schicht bewahrt den ursprünglichen Datenstand und die Ladehistorie auf und dient damit als Ausgangspunkt für Fehleranalysen und erneute Verarbeitungen: Nach einer fehlerhaften Transformation lassen sich die nachgelagerten Schichten aus Bronze neu aufbauen, ohne die Daten erneut aus den Quellen laden zu müssen.
Silver bereitet Rohdaten zu gemeinsam nutzbaren und technisch konsistenten Daten auf: Dazu gehören beispielsweise Deduplizierung, einheitliche Datentypen, abgestimmte Schlüssel und geregelte Historisierung. Silver stellt damit eine konsistente Datengrundlage für mehrere Teams und Anwendungsfälle bereit. Die fachliche Aufbereitung sollte dabei auf die notwendigen gemeinsamen Standards begrenzt bleiben. Sie sollte ausreichen, um gemeinsame und wiederverwendbare Sichten auf zentrale Geschäftsobjekte wie Kunden, Produkte und Transaktionen zu schaffen. Anwendungsspezifische Kennzahlen und Geschäftslogik werden anschließend in Gold umgesetzt.
Gold bereitet die Daten für konkrete fachliche Fragestellungen und Anwendungen auf: verbindlich definierte und fachlich freigegebene Kennzahlen, ein Star Schema fürs Reporting, Aggregate und Feature-Tabellen für Machine-Learning-Modelle. Die Schicht ist für die effiziente Nutzung durch Berichte, Analysen und Modelle optimiert: Aggregation und Verknüpfung passieren vorab, Dashboards greifen dadurch auf bereits vorbereitete Daten und Kennzahlen zu. Gold-Tabellen sollten als Datenprodukte mit klar benannten Nutzern und Verantwortlichen behandelt werden; Änderungen an Struktur oder Logik sollten daher wie Änderungen an einer produktiven Schnittstelle abgestimmt werden.
| Schicht | Qualitäts-Vertrag | Typische Ownership | Wer liest hier |
|---|---|---|---|
| Bronze | vollständig, unverändert, mit Lade-Historie | Plattform- oder Ingestion-Team | Data Engineering, Audit und Fehleranalyse |
| Silver | bereinigt, dedupliziert, abgeglichene Schlüssel | zentrales Datenteam oder Domäne | Analysten, ML-Teams, andere Domänen |
| Gold | fachlich modelliert, abgenommene Kennzahlenlogik | Datenprodukt-Owner der Domäne | BI, Reporting, AI-Anwendungen |
Die Schichten beschreiben zunächst logische Qualitätszustände; ob diese Zustände physisch materialisiert oder über Views bereitgestellt werden, muss separat entschieden werden. Physisch liegen die Tabellen auf offenen Formaten, die Transaktionen, Schema-Prüfung und den Zugriff auf frühere Datenstände (Time Travel) ermöglichen. Welche Rolle das Format darunter spielt, klären wir in den Überblicken zu Delta Lake und Apache Iceberg.
Welche Entscheidungen vor den ersten Pipelines stehen
Das Schichtenmodell beantwortet drei zentrale Betriebsfragen nicht automatisch: Wie viele Schichten, wer verantwortet sie, wer darf wo lesen. Diese Fragen sollten vor dem Aufbau produktiver Pipelines geklärt werden; spätere Änderungen werden schwieriger, sobald Berichte und Anwendungen auf den bestehenden Schichten aufbauen.
Wann reichen zwei Schichten und wann braucht es vier?
Die Einteilung in drei Schichten ist eine verbreitete Empfehlung, aber keine technische Vorgabe. In einfachen Szenarien können zwei Schichten ausreichend sein, wenn eine Quelle sauber strukturiert ankommt und nur ein Team sie konsumiert: Die Daten können dann direkt aus der Rohdatenschicht in eine konsumfertige Struktur überführt werden. Zusätzliche Stufen können sinnvoll sein, wenn weitere fachliche oder regulatorische Zustände klar voneinander getrennt werden müssen: etwa wenn Compliance-Anforderungen eine unveränderte Landing Zone vor Bronze verlangen, oder wenn zwischen Silver und Gold eine geteilte Zwischenschicht entsteht, in der Fachbereiche ihre Data Marts bauen. Gold bleibt dann auf wenige unternehmensweit abgestimmte Kennzahlen begrenzt.
Die Leitfrage ist je Strecke dieselbe: Welcher Qualitätssprung passiert hier, und wer braucht genau diesen Zustand? Eine Schicht ohne klaren Qualitätsunterschied und ohne konkrete Nutzer erzeugt meist nur zusätzlichen Aufwand. In diesem Fall sollte geprüft werden, ob sie mit einer angrenzenden Schicht zusammengeführt werden kann.
Wer verantwortet welche Schicht?
Ohne eindeutig benannte Verantwortung bleiben Qualitätsanforderungen unverbindlich. Eine mögliche Aufteilung orientiert sich an den jeweiligen Aufgaben der Schichten: Das Plattform- oder Ingestion-Team verantwortet die zuverlässige Aufnahme der Rohdaten, ein zentrales Datenteam oder die Domäne pflegt Silver, und die fachliche Verantwortung für Gold sollte bei der Domäne oder dem Team liegen, das die Kennzahlen und Geschäftslogik vertreten kann. In Katalog-Strukturen wie Unity Catalog lässt sich diese Aufteilung direkt abbilden; Zuständigkeit und Zugriff folgen derselben Logik.
Bei mehreren Fachdomänen muss zusätzlich entschieden werden, ob Silver zentral oder dezentral verantwortet wird. Größere Organisationen betreiben das Muster föderiert, mit einer eigenen Bronze-Silver-Gold-Strecke je Domäne; kuratierte Datenprodukte einer Domäne können als Eingangsquelle für andere Domänen dienen, das Schichtenmodell wird dadurch um domänenübergreifende Datenprodukte ergänzt. Voraussetzung sind gemeinsame Standards für Begriffe, Qualität und Schnittstellen. Wie ein dezentraler Zuschnitt mit Datenprodukten und föderierter Verantwortung aussieht, führen wir im Überblick zu Data Mesh aus.
Wer darf wo lesen?
Die dritte Entscheidung betrifft die zulässige Nutzung der einzelnen Schichten: Reports und Dashboards lesen aus Gold, Analysen und Modell-Training aus Silver und Gold, Bronze sollte grundsätzlich auf technische Fehleranalyse, Wiederanlauf und Audit beschränkt bleiben. Diese Trennung schützt die Verlässlichkeit der konsumierten Daten.
Nicht dokumentierte Ausnahmen schwächen die Verbindlichkeit des Schichtenmodells.
Was das Schichtenmodell im Betrieb kostet
Materialisierte Schichten erzeugen zusätzliche Datenbestände und Verarbeitungsaufwände. Dadurch entstehen Speicherbedarf, Compute-Kosten für jedes erneute Schreiben und Verarbeitungslatenz zwischen Quelle und Report. Die Speicherkosten sind dabei häufig geringer als der Aufwand für Entwicklung und Betrieb der Pipelines, zumal das Volumen je Stufe schrumpft, weil Silver dedupliziert und Gold aggregiert. Den größeren Aufwand verursachen meist die zusätzlichen Verarbeitungsstrecken: Jede Schicht benötigt Entwicklung, Monitoring und definierte Wiederanlaufverfahren. Die Schichten vermeiden im Gegenzug wiederholte Aufbereitung in jeder einzelnen Abfrage: Bereinigung und Standard-Transformationen, der klassische ETL-Schritt, laufen einmal beim Schreiben nach Silver; ohne eine gemeinsam nutzbare Silver-Schicht müssten Konsumenten dieselben Bereinigungen mehrfach auf den Rohdaten umsetzen.
Die Kritik am starren Drei-Schichten-Modell richtet sich vor allem gegen unnötige Datenkopien und zusätzliche Latenz. Actian argumentiert in einer kritischen Einordnung des Drei-Schichten-Musters, dass starr kopierte Drei-Schichten-Modelle Datenbewegung und Verzögerung erzeugen, die moderne Plattformen so pauschal nicht mehr brauchen.
Entscheidend ist deshalb ein bedarfsgerechter Zuschnitt: Schichten ohne klaren Qualitätsunterschied oder eigene Nutzer sollten zusammengeführt werden, Gold kann bei geringer Abfragelast auch über Views statt über materialisierte Tabellen bereitgestellt werden, und Aktualisierungsfrequenzen sollten je Strecke an den fachlichen Bedarf gekoppelt werden. Kontinuierliche Verarbeitung reduziert die Latenz, erhöht jedoch die laufenden Compute-Kosten; zeitgesteuerte Läufe drehen das Verhältnis um. Ein täglich genutzter Bericht muss nicht zwingend stündlich über alle Stufen neu berechnet werden; echte Echtzeit-Strecken laufen als Ergänzung in denselben Schichten.
eine Kundenumsatz-Strecke durch die Schichten
Das Modell lässt sich anhand einer Kundenumsatzstrecke verdeutlichen: Ein Unternehmen führt Aufträge aus dem ERP und Kundendaten aus dem CRM zu einer verlässlichen Umsatzsicht zusammen:
Bronze
Die Daten aus ERP und CRM werden zunächst weitgehend unverändert im Lakehouse gespeichert, mit Zeitstempel und Lade-Historie. Änderungen an der Quellstruktur lassen sich anhand der Bronze-Daten nachvollziehen, die Verarbeitung lässt sich von dort neu aufsetzen.
Silver
Kundenschlüssel aus ERP und CRM werden abgeglichen, Dubletten bereinigt und Währungen vereinheitlicht. Die aufbereiteten Tabellen dienen anschließend mehreren Teams als gemeinsame Datengrundlage, etwa dem Vertriebs-Reporting und dem Forecast-Team.
Gold
Ein fachlich abgestimmtes Umsatzmodell als Sternschema für das Reporting. Zusätzlich kann eine Feature-Tabelle für ein Churn-Modell bereitgestellt werden. Beide gelten als Datenprodukte mit benanntem Owner.
Die Konsum-Regel dazu: Power BI liest ausschließlich Gold, das Data-Science-Team arbeitet auf Silver und Gold, Bronze bleibt gesperrt für alles außer Betrieb und Audit. Dadurch lässt sich für jede Kennzahl im Dashboard nachvollziehen, aus welcher Schicht sie stammt und wer sie fachlich verantwortet.
Was die Medallion-Architektur nicht beantwortet
Das Muster strukturiert die schrittweise Aufbereitung und Qualitätssicherung innerhalb des Lakehouse. Andere Architekturentscheidungen müssen jedoch separat getroffen werden und haben im Lakehouse-Hub eigene Antworten:
- Welche Architektur zu welchem Workload-Profil passt, klären wir im Vergleich Data Warehouse vs. Data Lake vs. Lakehouse.
- Warum ein Data Lake ohne Qualitätsregeln kippt und was er trotzdem leistet, zeigen wir im zugehörigen Überblick.
- Ob Tabellen für Delta- und Iceberg-Konsumenten gleichzeitig lesbar sein können, erklären wir zu UniForm.
- Wie der Weg vom bestehenden Data Warehouse ins Lakehouse aussieht, führen wir im Konzept zur Lakehouse-Migration aus.
Eine sinnvolle Reihenfolge: Zunächst sollte die übergreifende Datenarchitektur festgelegt werden, anschließend das Tabellenformat und danach die konkrete Schichtenstruktur.
Grenzen
Die Medallion-Architektur schafft ein gemeinsames Verständnis für unterschiedliche Qualitätszustände von Daten und erleichtert die Zuordnung von Verantwortung. Für eine vollständige Datenplattform sind zusätzlich Modellierung, Governance, Qualitätssicherung und Betrieb erforderlich.
Keine fachliche Datenmodellierung
Das Muster sagt, wo modelliert wird. Wie das Gold-Modell aussieht (Sternschema, Data Vault, breite Tabellen), bleibt eine eigene Entscheidung mit Folgen für Abfragen, Historisierung und Pflege. Ohne Modellierungsentscheidungen entstehen lediglich technisch getrennte Schichten mit fachlich unklaren Daten.
Uneinheitliche Schicht-Definitionen
Was „silver-reif“ bedeutet, definiert jedes Unternehmen selbst. Ohne verbindliche Definitionen entstehen je Domäne unterschiedliche Qualitätsstandards, und die Schichtbezeichnungen verlieren dadurch ihre Aussagekraft.
Starre Drei-Schichten-Kopie
Im Data-Engineering-Umfeld wird offen diskutiert, ob Teams das starre Drei-Schichten-Modell wieder verlassen, gerade wegen Kosten und Latenz mehrfacher Kopien. Die Kritik richtet sich vor allem gegen eine starre Umsetzung und weniger gegen das Prinzip klar definierter Qualitätsstufen.
Governance nicht automatisch enthalten
Zugriffsrechte, Lineage, Klassifizierung und Freigabeprozesse regeln Katalog und Organisation. Die Schichten können Governance-Regeln unterstützen, ersetzen aber weder Katalog noch Rollen- und Freigabemodell.
Ohne Prüfung keine Verbindlichkeit
Ohne technische Prüfungen verlieren dokumentierte Qualitätsregeln im laufenden Betrieb schnell ihre Verbindlichkeit. Gültig bleiben sie, wenn die Prüfungen in den Pipelines mitlaufen und Verstöße sichtbar machen.
Als Ordnungsrahmen trägt das Muster trotz dieser Grenzen: Entscheidend sind klar definierte Qualitätszustände und Verantwortlichkeiten, weniger die Namen der Schichten.
Sobald Reports, Forecasts oder Modelle an den Schichten hängen, gehören die Verträge dokumentiert, technisch geprüft und in den Katalog-Strukturen abgebildet. Erst durch dokumentierte Regeln, automatisierte Prüfungen und klare Ownership wird daraus ein verlässliches Betriebsmodell.
Fazit
Die Medallion-Architektur schafft klar benannte Qualitätsstufen, eindeutige Zuständigkeiten und eine verlässliche Bereitstellungsschicht für BI-, Analyse- und KI-Anwendungen.
Die Medallion-Architektur ist besonders sinnvoll, wenn mehrere Teams und Anwendungen dieselbe Datenplattform nutzen und ein gemeinsames Verständnis über Datenqualität und zulässige Nutzung fehlt.
Typische Anwendungsfälle sind:
- Reports lesen direkt aus Rohdaten, weil der kuratierte Weg zu lange dauert oder fehlt.
- Jede Domäne hat ein eigenes Verständnis davon, was bereinigte Daten sind.
- Bei Qualitätsproblemen sind weder die betroffene Schicht noch die verantwortliche Person eindeutig bestimmt.
- Dieselben Quelldaten werden in mehreren Teams parallel aufbereitet.
Für einfache Szenarien mit einer Quelle und wenigen Konsumenten, etwa einem Team und einem Report, kann ein zweistufiges Modell ausreichend sein; eine zusätzliche Schicht sollte erst eingeführt werden, wenn sie einen klaren Qualitäts- oder Nutzungszweck erfüllt.
Die technische Struktur lässt sich schnell anlegen. Ob die Daten verlässlich genutzt werden können, hängt jedoch von den verbindlichen Regeln und Verantwortlichkeiten ab.
Als Einstieg eine einzelne End-to-End-Strecke von der Quelle bis zum Report umsetzen; für jede Schicht Qualitätsanforderungen, zulässige Nutzung und Verantwortlichkeit dokumentieren, bevor weitere Domänen folgen.
Schichten-Zuschnitt für euer Lakehouse klären
Ob die Medallion-Architektur eure Lakehouse-Daten ordnet oder zusätzliche Komplexität erzeugt, lässt sich in einem ersten Data-Engineering-Gespräch gut einordnen.
- Welche eurer Quellen und Datenstrecken echte Kandidaten für den ersten Schichten-Zuschnitt sind
- Welche Qualitäts-, Ownership- und Kostenrisiken vor dem nächsten Ausbau geprüft werden müssen
- Welcher Zuschnitt mit zwei, drei oder mehr Schichten für eure Workloads trägt
FAQ
Die Medallion-Architektur ist ein Designmuster für Lakehouse-Daten, das Daten in drei aufeinander aufbauenden Schichten organisiert: Bronze für unveränderte Rohdaten, Silver für bereinigte und zusammengeführte Daten, Gold für fachlich modellierte, konsumfertige Sichten. Geprägt wurde der Begriff von Databricks, das Muster wird aber plattformübergreifend eingesetzt. Jede Schicht steht für ein definiertes Qualitätsversprechen an die Konsumenten.
