Medallion-Architektur: der Leitfaden zu Bronze, Silver und Gold

Die Medallion-Architektur ist ein Entwurfsmuster, das Daten in einem Lakehouse in drei aufeinander aufbauende Schichten ordnet, Bronze, Silver und Gold, mit jeweils höherer Qualität, mehr Struktur und größerer fachlicher Nutzbarkeit. Bekannt gemacht hat sie Databricks als empfohlene Praxis für Delta Lake; inzwischen ist sie ein verbreiteter Standard für Datenplattformen auf Apache Iceberg, Apache Hudi und vergleichbaren offenen Tabellenformaten.

Was ist die Medallion-Architektur?

Im Kern ist die Medallion-Architektur eine mehrstufige Pipeline. Daten laufen von der Quelle durch eine Reihe von Verarbeitungsstufen, und jede Stufe wird als dauerhafte, abfragbare Schicht abgelegt statt als flüchtiger Zwischenschritt. Genau diese Dauerhaftigkeit unterscheidet sie von klassischen ETL-Pipelines: Jede Schicht ist ein vollwertiger Datensatz, der sich unabhängig abfragen, überwachen und regeln lässt.

Der Name „Medallion“ spielt darauf an, dass jede Schicht eine höhere Güteklasse darstellt, so wie Bronze-, Silber- und Goldmedaillen im Sport. Das Bild ist eingängig und hat zur Verbreitung des Musters beigetragen. Manche Organisationen erweitern es, etwa um eine Landezone vor Bronze oder um eine Platinum-Schicht für stark verdichtete Berichte an die Geschäftsführung. Die dreischichtige Form bleibt aber die kanonische.

Grundsätzlich ist das Muster unabhängig vom Speicherformat, es entfaltet seine Stärke jedoch dort, wo die Speicherschicht ACID-Transaktionen, Schema-Evolution und Time Travel beherrscht. Deshalb wird es meist zusammen mit offenen Tabellenformaten wie Delta Lake, Apache Iceberg und Apache Hudi genannt, die genau das auf Cloud-Objektspeicher leisten.

Die Bronze-Schicht: Rohdaten bewahren

Die Bronze-Schicht ist die Landezone für alle Rohdaten aus den Quellsystemen. Sie nimmt die Daten genau so auf, wie sie ankommen: kein erzwungenes Schema, keine Bereinigung von Duplikaten, keine Transformation. Sie ist bewusst als reine Anfüge-Schicht angelegt, Datensätze kommen hinzu und werden nie geändert oder gelöscht. Diese Unveränderlichkeit macht sie zum maßgeblichen historischen Nachweis über alles, was die Organisation je empfangen hat.

Typisch für Bronze sind CDC-Ereignisse aus Datenbanken (Change Data Capture), API-Antworten, Logdateien, CSV-Exporte, Streaming-Datensätze aus Apache Kafka oder Azure Event Hubs und jedes andere Quellformat. Zu jedem Datensatz kommen Metadaten der Ingestion, etwa Zeitstempel, Kennung des Quellsystems und Laufnummer der Pipeline, sodass sich alles lückenlos prüfen lässt.

Weil Bronze-Daten ungeprüft sind, enthalten sie unter Umständen Nullwerte, fehlerhafte Datensätze, doppelte Ereignisse, Schema-Drift und andere Qualitätsprobleme. Das ist gewollt. Die Bronze-Schicht ist ein Sicherheitsnetz: Wenn nachgelagerte Transformationen Fehler haben oder sich fachliche Regeln ändern, können Teams jederzeit aus Bronze neu aufbereiten, ohne erneut aus den Quellsystemen zu laden.

Daten sollten nach ihrer Entstehung so schnell wie möglich in Bronze landen. Partitioniert wird hier fast immer nach dem Datum der Ingestion oder dem Zeitpunkt des Eingangs, nicht nach fachlichen Schlüsseln. Die Aufbewahrung richtet sich nach den regulatorischen Vorgaben; in vielen Branchen müssen Rohdaten sieben Jahre oder länger vorgehalten werden.

Die Silver-Schicht: bereinigt und vereinheitlicht

Die Silver-Schicht macht aus rohen Bronze-Daten saubere, geprüfte und vereinheitlichte Datensätze. Hier liegt der Großteil der Data-Engineering-Arbeit: Duplikate entfernen, Nullwerte behandeln, Typen umwandeln, Formate für Datum, Währung und Kennungen vereinheitlichen, fachliche Regeln anwenden und jene leichten Transformationen vornehmen, die Daten auch ohne Fachwissen abfragbar machen.

Silver-Tabellen bilden in der Regel fachliche Entitäten ab: Kunden, Bestellungen, Produkte, Transaktionen, Ereignisse. Sie stellen je Entität eine einzige gültige Fassung dar, ohne Duplikate und mit aufgelösten Widersprüchen nach festgelegter Zusammenführungslogik. Auf dieser Schicht wird das Schema durchgesetzt: Datensätze, die die Prüfung nicht bestehen, wandern in eine eigene Fehlertabelle, statt still verworfen oder verfälscht zu werden.

Kennzeichnend für Silver ist, dass die Daten der Quelldomäne noch nahe stehen. Sie sind bereinigt und geprüft, aber noch nicht verdichtet oder auf einen bestimmten fachlichen Zweck zugeschnitten. Eine Silver-Kundentabelle enthält alle bekannten Merkmale eines Kunden, keine vorgefilterte Auswahl für eine einzelne Kampagne. Erst diese Allgemeinheit erlaubt es, aus einer Silver-Tabelle mehrere Gold-Datensätze mit ganz verschiedenen Zwecken abzuleiten.

Silver ist auch der richtige Ort für die Logik langsam veränderlicher Dimensionen (Slowly Changing Dimensions, SCD). Ändert ein Kunde seine Anschrift oder wird ein Produkt neu eingeordnet, hält die Silver-Schicht diese Historie über SCD-Muster vom Typ 1, 2 oder 4 fest. Mit offenen Tabellenformaten wie Apache Iceberg lässt sich SCD-Logik über MERGE-Anweisungen umsetzen, die geänderte Datensätze atomar einfügen oder aktualisieren und die Historie über Time Travel erhalten.

Die Gold-Schicht: fachlich nutzbar

Die Gold-Schicht enthält Daten, die Fachbereiche, Analystinnen und Analysten, Data Scientists und Anwendungen unmittelbar nutzen können. Gold-Datensätze sind für konkrete Auswertungen gebaut: Dashboards für die Geschäftsführung, Attributionsmodelle im Marketing, Finanzberichte, Feature Stores für Machine Learning und Data Products für Kunden.

Anders als Bronze und Silver sind Gold-Tabellen nicht allgemein gehalten. Eine einzige Silver-Kundentabelle kann Dutzende Gold-Datensätze speisen, jeden anders zugeschnitten für ein anderes Publikum. In Gold greift die letzte fachliche Logik: Verdichtungen, Verknüpfungen über Domänen hinweg, abgeleitete Kennzahlen, Einschränkung auf den relevanten Zeitraum und die Aufbereitung für Werkzeuge wie Power BI, Tableau oder Looker.

Gold-Datensätze werden meist auf Abfrageleistung hin optimiert: durchdachte Partitionierung, Clustering nach häufig verknüpften Schlüsseln und vorberechnete, teure Verdichtungen. Weil Gold aus Silver abgeleitet ist, lässt es sich bei geänderter fachlicher Logik jederzeit neu erzeugen; aufwendige Nachladeprozesse für historische Gold-Daten braucht niemand.

Gold ist die Oberfläche, auf der die Fachbereiche arbeiten, und damit aus Sicht der Data Governance die wichtigste Schicht. Zugriffsrichtlinien, Sicherheit auf Zeilenebene und das Maskieren einzelner Spalten greifen üblicherweise hier. Zertifizierungen und Vertrauenssignale hängen an Gold-Datensätzen und sagen den Nutzern, wie belastbar die Daten sind.

Umsetzung: die wichtigen Entscheidungen

Wer die Medallion-Architektur einführt, steht vor einigen Grundsatzfragen. Die erste: ein einziges Speicherkonto für alle drei Schichten oder je Schicht ein eigenes. Getrennte Konten trennen Zugriffe schärfer und erhöhen den Betriebsaufwand. Die meisten beginnen mit einem Konto und regeln den Zugriff über Ordner oder Namensräume.

Die zweite betrifft die Orchestrierung. Verbreitet sind Apache Airflow, Databricks Workflows, Azure Data Factory und dbt für die Transformationslogik. dbt wird für Silver und Gold zunehmend eingesetzt, weil sein modellbasierter Ansatz gut zum Muster passt und seine Lineage-Dokumentation sich in Datenkataloge wie Dawiso einfügt.

Die dritte betrifft Data Observability. Jede Schicht braucht automatische Qualitätsprüfungen: Bronze überwacht Vollständigkeit der Ingestion und SLAs für den Eingang von Dateien, Silver die Einhaltung des Schemas, Nullwertquoten und referenzielle Integrität, Gold die Stimmigkeit von Kennzahlen, erwartete Zeilenzahlen und SLAs zur Aktualität.

Governance über alle Schichten

Aus Sicht der Governance ist es einer der größten Vorzüge der Medallion-Architektur, dass die drei Schichten natürliche Prüfpunkte für Data Lineage schaffen. Jede Transformation von Bronze nach Silver und von Silver nach Gold ist eine ausdrückliche Datenbewegung, die sich in einem Metadatensystem festhalten lässt.

Hier liegt der Wert von Plattformen wie Dawiso. Der Datenkatalog von Dawiso erlaubt es Datenteams, die Tabellen jeder Schicht zu dokumentieren, Lineage auf Spaltenebene über die Übergänge Bronze nach Silver und Silver nach Gold zu verfolgen und diese Lineage den Fachbereichen zu zeigen. Sieht eine Gold-Kennzahl falsch aus, lässt sie sich über den Lineage-Graphen bis zu dem Bronze-Datensatz oder der Silver-Regel zurückverfolgen, die das Problem eingebracht hat.

Dawiso unterstützt auch Tagging und Klassifizierung je Schicht. Bronze-Tabellen tragen Quellsystem und Schutzbedarf, Silver-Tabellen die Dokumentation ihrer Bereinigungsregeln und ihrer Verantwortlichkeit, Gold-Datensätze eine Zertifizierung mit Qualitätswerten und die Verknüpfung zu den Begriffen im Business Glossary (Fachglossar), die sie abbilden.

Databricks, Apache Iceberg und Apache Hudi

Databricks hat das Muster als empfohlene Praxis für Delta Lake eingeführt und baut es weiter aus, unter anderem mit Delta Live Tables (DLT), einem deklarativen Rahmen für Medallion-Pipelines mit eingebauten Bedingungen an die Datenqualität und automatischer Abhängigkeitsverfolgung.

Apache Iceberg hat sich als starke Alternative zu Delta Lake etabliert, besonders dort, wo mehrere Engines auf denselben Tabellen arbeiten, etwa Spark, Trino, Flink und Snowflake. Die Katalogabstraktion von Iceberg und seine Unterstützung für verborgene Partitionierung, Schema-Evolution und Löschungen auf Zeilenebene passen gut zu den Transformationen, die jede Schicht verlangt.

Apache Hudi wird häufig dort eingesetzt, wo in Bronze und Silver sehr viele Aktualisierungen anfallen. Mit Copy-on-Write und Merge-on-Read bietet es zwei Speicherarten, zwischen denen Teams je nach Schicht zwischen Schreiblatenz und Leseleistung abwägen können.

Bewährte Praxis für die Medallion-Architektur

Teams, die die Medallion-Architektur im großen Maßstab erfolgreich betreiben, halten es meist ähnlich:

• jede Schicht als Produkt führen, mit benannten Konsumenten, SLAs und klarer Verantwortung
• automatische Überwachung der Datenqualität von Anfang an einplanen, nicht später nachrüsten
• Lineage und fachliche Logik während der Entwicklung dokumentieren, nicht danach
• der Versuchung widerstehen, Schichten zu überspringen: Was das Auslassen von Silver an Aufwand spart, zahlt man bei Governance und Fehlersuche fast immer doppelt zurück
• für jede Silver- und Gold-Tabelle vor der Produktivsetzung einen benannten Owner, einen dokumentierten Zweck und ein SLA zur Aktualität verlangen
• in Bronze und Silver auf Streaming setzen, wo es nahezu in Echtzeit sein muss, und Batch für die rechenintensiven Verdichtungen in Gold aufheben

Das Muster ist keine starre Vorschrift, sondern ein Satz von Grundsätzen. Teams sollten es an ihren Kontext anpassen: Zahl der Schichten, Feinheit der Qualitätsprüfungen und Werkzeugwahl richten sich nach Größe, Reifegrad und Anwendungsfällen. Entscheidend ist, dass die Grundsätze durchgehalten werden: Rohdaten bewahren, Qualität schrittweise steigern, klare Oberflächen für den Konsum.