Rohdaten aus ERP, CRM, IoT-Sensoren und Webanwendungen sind selten sofort für Berichte oder Machine Learning geeignet. Das Muster der medallion architecture schafft dafür eine klare Verarbeitungskette mit Bronze-, Silver- und Gold-Schicht. Ich zeige, wie die Ebenen funktionieren, welche Daten dort hingehören, wie ein Lakehouse praktisch aufgebaut wird und an welchen Stellen Teams häufig unnötige Komplexität erzeugen.
Ein klares Schichtenmodell macht Lakehouse-Daten verlässlicher
- Bronze bewahrt eingehende Daten möglichst unverändert auf.
- Silver bereinigt, validiert, vereinheitlicht und verbindet die Daten.
- Gold liefert fachlich zugeschnittene Tabellen für BI, Berichte und Entscheidungen.
- Jede Schicht braucht eigene Regeln für Qualität, Zugriff, Aufbewahrung und Überwachung.
- Das Modell ist ein Designmuster, keine starre Pflicht mit genau drei physischen Speichern.
Was hinter dem Schichtenmodell steckt
Ein Lakehouse verbindet die günstige, flexible Speicherung eines Data Lakes mit den strukturierten Abfragemöglichkeiten eines Data Warehouses. Die Medallion-Struktur teilt diesen Datenbestand nach dem Grad seiner Aufbereitung. Mit jeder Stufe steigen Struktur, Verlässlichkeit und fachliche Nähe, während die Rohdaten als Beleg und Ausgangspunkt erhalten bleiben.
Das ist mehr als eine Ordnerstruktur. Die Schichten legen fest, wer Daten verändern darf, welche Qualitätsregeln gelten und für welche Nutzung ein Datensatz freigegeben ist. Aus meiner Erfahrung entsteht der größte Nutzen nicht durch die Namen Bronze, Silver und Gold, sondern durch die eindeutigen Verantwortlichkeiten dahinter.
| Schicht | Typische Aufgabe | Geeignet für |
|---|---|---|
| Bronze | Rohdaten aufnehmen und nachvollziehbar speichern | Datenengineering, Wiederholungen, Audits, Fehleranalyse |
| Silver | Daten bereinigen, prüfen, standardisieren und integrieren | Analysen, Data Science, gemeinsame Fachdatenmodelle |
| Gold | Daten für konkrete Geschäftsfragen modellieren und aggregieren | Dashboards, Kennzahlen, Managementberichte, operative Anwendungen |
Bronze bleibt möglichst nah an der Quelle
In Bronze landen beispielsweise JSON-Ereignisse aus einem Webshop, CSV-Dateien aus einem ERP-System oder Messwerte aus einer Produktionsanlage. Ich speichere dort normalerweise den Originalinhalt, ergänzt um technische Metadaten wie Quelle, Ladezeitpunkt, Dateiname und Batch-ID.
Fehlerhafte Datensätze werden in dieser Schicht nicht einfach überschrieben. Sie können markiert oder in einen Quarantänebereich verschoben werden. So bleibt später nachvollziehbar, welche Daten tatsächlich geliefert wurden und ob ein Fehler bereits an der Quelle entstanden ist.
Silver schafft verlässliche Fachdaten
Die Silver-Schicht entfernt Dubletten, vereinheitlicht Datums- und Währungsformate, prüft Pflichtfelder und führt Daten aus mehreren Quellen zusammen. Aus „DE“, „Deutschland“ und „Germany“ kann beispielsweise ein einheitlicher Länderwert werden. Ungültige Datensätze erhalten eine klare Behandlung, statt still aus dem System zu verschwinden.
Hier entsteht meist das wichtigste gemeinsame Datenfundament. Ein Kunde, eine Bestellung oder ein Produkt sollte in Silver nach klar dokumentierten Regeln definiert sein. Das verhindert, dass jedes Berichtsteam eigene Filter und eigene Kundenzahlen entwickelt.
Gold beantwortet konkrete Geschäftsfragen
Gold ist keine zweite Kopie von Silver, sondern eine auf Nutzung optimierte Darstellung. Typisch sind Tabellen wie Monatsumsatz, Lieferzeit je Region oder aktive Kunden je Produktgruppe. Die Daten sind oft aggregiert und damit leichter sowie günstiger abzufragen.
Ich würde Gold immer an einem konkreten Verbraucher ausrichten. Ein Dashboard braucht andere Tabellen als ein Prognosemodell. Wer versucht, eine einzige Gold-Tabelle für alle Zwecke zu bauen, produziert meist ein schwer verständliches Kompromissmodell.
So fließen Daten durch Bronze, Silver und Gold
Der typische Ablauf beginnt mit der Aufnahme aus Quellsystemen und endet bei einer Kennzahl, die ein Fachbereich verwenden kann. Zwischen den Ebenen liegen kontrollierte Transformationen. Entscheidend ist, dass jede Verarbeitung wiederholbar und nachvollziehbar bleibt.
Beispiel aus dem Onlinehandel
Ein Webshop liefert Bestellungen, ein CRM Kundendaten und ein Logistiksystem Versandereignisse. In Bronze werden die drei Datenströme zunächst getrennt und mit ihren technischen Eingangsinformationen gespeichert.
In Silver werden Kundennummern abgeglichen, Zeitstempel auf eine gemeinsame Zeitzone gebracht und doppelte Bestellungen erkannt. Danach lassen sich Bestellung, Kunde und Versand zu einem belastbaren Fachdataset verbinden. In Gold entsteht daraus etwa eine Tabelle mit Umsatz, Retourenquote und durchschnittlicher Lieferzeit pro Monat und Region.
Transformationen sollten eine klare Richtung haben
Eine gute Pipeline verarbeitet Daten grundsätzlich von Bronze nach Silver und von Silver nach Gold. Direkte Sonderwege von Bronze in mehrere Berichte wirken anfangs schnell, führen aber langfristig zu unterschiedlichen Definitionen derselben Kennzahl.
Rückwärtsabhängigkeiten sind ein Warnsignal. Wenn Silver plötzlich eine bereits aggregierte Gold-Tabelle benötigt, ist das Datenmodell meist falsch geschnitten. Für Ausnahmen kann es technische Gründe geben, sie sollten aber dokumentiert und nicht zum normalen Arbeitsweg werden.
Welche Qualitätsregeln jede Schicht braucht
Die drei Ebenen haben unterschiedliche Qualitätsziele. Bronze muss vor allem vollständig, unverändert und auffindbar sein. Silver muss fachlich konsistent und prüfbar werden. Gold muss zusätzlich verständlich, stabil und für den vorgesehenen Zweck schnell abfragbar sein.
| Prüfung | Bronze | Silver | Gold |
|---|---|---|---|
| Vollständigkeit | Ist die Lieferung angekommen? | Sind Pflichtfelder vorhanden? | Sind die Kennzahlen vollständig berechnet? |
| Duplikate | Aufbewahren und markieren | Nach fachlicher Regel bereinigen | Keine doppelten Geschäftsvorfälle |
| Schema | Quellschema dokumentieren | Standardisiertes Schema erzwingen | Stabiles Verbrauchsschema anbieten |
| Zugriff | Stark eingeschränkt | Für Analyse- und Data-Science-Teams | Für berechtigte Fachanwender und BI-Werkzeuge |
Für jede Tabelle sollten mindestens Besitzer, Zweck, Aktualisierungsrhythmus, Datenquelle und fachliche Definition dokumentiert sein. Bei sensiblen Informationen kommen Rollenrechte, Maskierung und Protokollierung hinzu. Besonders wichtig ist, dass Gold nicht automatisch frei von Datenschutzrisiken ist, nur weil die Daten aggregiert wurden.
Lesen Sie auch: Azure Data Warehouse - Wann es sich wirklich lohnt
Qualität messbar machen
Ich empfehle, für wichtige Tabellen wenige, aber konkrete Regeln festzulegen. Dazu gehören etwa ein maximaler Anteil fehlender Kundenschlüssel, erlaubte Wertebereiche für Beträge oder eine definierte Aktualitätsgrenze. Eine Regel wie „Daten müssen aktuell sein“ hilft niemandem; „höchstens 60 Minuten Verzögerung“ ist dagegen prüfbar.
Fehler sollten sichtbar werden, ohne die gesamte Pipeline unnötig zu stoppen. Kritische Verstöße können einen Lauf abbrechen, weniger wichtige Probleme landen in einer Quarantäne oder einem Qualitätsbericht. So bleibt der Betrieb stabil und trotzdem transparent.
So lässt sich das Muster in einem Lakehouse umsetzen
Die technische Umsetzung kann mit verschiedenen Plattformen erfolgen, etwa mit Spark, SQL, Delta-Tabellen oder verwalteten Lakehouse-Diensten. Die Werkzeuge sind zweitrangig. Wichtiger ist, dass das Team zuerst Datenverträge und Verantwortlichkeiten festlegt und erst danach Pipelines baut.
- Quellen inventarisieren: Erfasse Systeme, Formate, Eigentümer, Ladefrequenzen und erwartete Datenmengen.
- Bronze definieren: Lege Speicherpfade oder Schemata fest und speichere technische Metadaten sowie die Rohdaten.
- Silver modellieren: Beschreibe Schlüssel, Datentypen, Standardwerte, Dublettenregeln und fachliche Beziehungen.
- Gold nach Nutzung bauen: Erstelle getrennte Datenprodukte für Berichte, operative Abfragen oder Machine Learning.
- Tests einrichten: Prüfe Schema, Anzahl Datensätze, Aktualität, Wertebereiche und Referenzen bei jedem Lauf.
- Lineage überwachen: Halte fest, welche Quelle eine Tabelle speist und welche Berichte von ihr abhängen.
Bei großen Datenmengen lohnt sich inkrementelle Verarbeitung. Dabei werden nur neue oder geänderte Datensätze verarbeitet, statt jeden Tag alles neu zu laden. Für Korrekturen und verspätet eintreffende Ereignisse braucht die Pipeline Regeln für Replay, Backfill und idempotente Läufe. Idempotent bedeutet, dass ein wiederholter Lauf nicht zu doppelten Ergebnissen führt.
Physisch müssen die drei Ebenen nicht zwingend in drei getrennten Lakehouses liegen. Je nach Plattform reichen getrennte Schemata oder Speicherbereiche. Separate Umgebungen werden vor allem dann sinnvoll, wenn Sicherheit, Skalierung oder Verantwortlichkeiten eine stärkere Trennung verlangen.
Wo das Modell an Grenzen stößt
Die Schichten lösen kein grundsätzliches Datenqualitätsproblem. Wenn Quellsysteme widersprüchliche Kundennummern liefern oder Geschäftsregeln unklar sind, verschiebt die Struktur das Problem nur an eine besser sichtbare Stelle. Genau das ist trotzdem nützlich, denn die Ursache lässt sich in einer getrennten Bronze-Schicht leichter untersuchen.
Ein weiterer Nachteil sind zusätzliche Speicher- und Verarbeitungskosten. Dieselben Informationen können in mehreren Formen vorliegen. Bei kleinen Datenmengen oder einem einzigen stabilen Quellsystem wäre ein einfaches relationales Modell möglicherweise die bessere Wahl.
Auch die Begriffe werden manchmal zu dogmatisch verwendet. Nicht jede Tabelle muss alle drei Stationen durchlaufen, und nicht jede Analyse braucht Gold. Ein Data-Science-Team kann für explorative Arbeit direkt mit einer gut dokumentierten Silver-Tabelle arbeiten. Die Entscheidung sollte vom Verwendungszweck und vom Änderungsrisiko abhängen.
Besonders problematisch ist eine Gold-Schicht, die nur aus unzähligen Spezialtabellen besteht. Dann wird das Lakehouse unübersichtlich und jede neue Frage erfordert eine weitere Pipeline. Besser sind wenige stabile Kerndatenprodukte mit klaren Kennzahlen und ergänzende, bewusst kurzlebige Auswertungen.
Woran ich eine tragfähige Umsetzung erkenne
Eine gute Architektur erkennt man nicht daran, dass drei Ordner mit passenden Namen existieren. Sie funktioniert, wenn ein Analyst eine Kennzahl bis zur Quelle zurückverfolgen kann, ein Fehler reproduzierbar bleibt und verschiedene Berichte auf derselben fachlichen Definition aufbauen.
- Bronze-Daten sind unverändert, versioniert und auffindbar.
- Silver-Tabellen besitzen dokumentierte Schlüssel und überprüfbare Qualitätsregeln.
- Gold-Daten sind auf konkrete Nutzer und Entscheidungen zugeschnitten.
- Fehlerhafte Datensätze werden sichtbar behandelt und nicht still gelöscht.
- Zugriffe, Aufbewahrung und personenbezogene Daten sind je Schicht geregelt.
- Pipeline-Läufe, Aktualität und Datenqualität werden automatisch überwacht.
Mein wichtigster Rat lautet deshalb, klein zu starten. Ein sauber dokumentierter Datenfluss für einen Geschäftsprozess ist wertvoller als ein großes Bronze-Silver-Gold-Schaubild ohne Besitzer, Tests und klare Nutzer. Wenn jede Schicht eine erkennbare Aufgabe erfüllt, wird aus dem Muster ein belastbares Fundament für Datenanalyse und Datenbanken.
