Medallion-Architektur: Bronze, Silver und Gold sinnvoll einsetzen
Was ist die Medallion-Architektur?
Die Medallion-Architektur, englisch Medallion Architecture, ordnet einen Datenpfad in drei logische Schichten: Bronze für rohe Eingänge, Silver für validierte Detaildaten und Gold für fachliche Datenprodukte. Das Muster wird nutzbar, wenn jeder Übergang Regeln, Verantwortliche und eine Abnahme hat.
Die Definition von Google Cloud beschreibt eine schrittweise Verbesserung von Qualität und Struktur. „Logisch“ bedeutet hier: Sie legen fest, welche Verantwortung ein Datenzustand erfüllt. Aus den drei Namen folgt keine pauschale Pflicht, jede Datei dreimal vollständig zu kopieren. Welche Tabellen, Views oder materialisierten Ergebnisse Sie dafür benötigen, entscheiden Sie anhand von Zugriff, Wiederverwendung, Aktualität und Betrieb.
Ein sinnvoller Start ist deshalb ein konkreter Nutzerjob: etwa eine verlässliche Bestellkennzahl für das Controlling. Von deren Abnahme aus planen Sie rückwärts, welche Detaildaten und unveränderten Eingänge erforderlich sind. Ordner mit Metallnamen verbessern Daten für sich allein nicht.
Bronze, Silver und Gold: Welche Aufgabe hat jede Schicht?
Bronze: Eingänge nachvollziehbar erhalten
Bronze bewahrt den aufgenommenen Rohzustand und die Informationen, mit denen Sie seine Herkunft nachvollziehen können. Dazu gehören Quelle, Ladezeit und gegebenenfalls Dateiname oder Ereignisidentität. Die Databricks-Beschreibung ordnet Bronze als Ausgangspunkt für spätere Verarbeitung und Wiederverarbeitung ein.
Unser Umsetzungsvorschlag: Bewahren Sie Inhalt und Herkunft vor fachlichen Änderungen. Prüfen Sie bei der Aufnahme zunächst, ob ein Eingang technisch verarbeitet werden kann; führen Sie umfangreiche Fachregeln im nächsten Übergang aus. Planen Sie Zugriff und Aufbewahrungsdauer ausdrücklich. Ein Rohzustand für Replay bedeutet keine unbegrenzte Aufbewahrung sämtlicher Daten.
Silver: valide Detaildaten bereitstellen
Silver liefert bereinigte und validierte Daten auf Detailebene. Typen, Schlüssel, Dubletten, fehlende Werte und Schemaänderungen gehören in diese Verarbeitung. Die Azure-Databricks-Dokumentation betont, dass Silver die Detailtreue erhält. Silver muss daher nicht bereits auf Tages- oder Kundensummen verdichtet sein.
Legen Sie fest, was eine Zeile fachlich bedeutet und welche Identität eine Dublette erkennen lässt. Trennen Sie gültige Daten von Eingängen, die eine Regel verletzen. Für wiederverwendbare Detaildaten sollen andere Teams erkennen können, welche Prüfungen abgeschlossen sind und welche Interpretation noch offen ist.
Gold: einen fachlichen Verbrauchervertrag erfüllen
Gold stellt Daten in einer Form bereit, die einen konkreten Consumer unterstützt: zum Beispiel ein BI-Modell, eine freigegebene Kennzahl oder einen auf einen Anwendungsfall zugeschnittenen Datensatz. Häufig kommen Aggregate und fachliche Modellierung hinzu, wie die Databricks-Medallion-Dokumentation erläutert.
Definieren Sie den Grain, also die Bedeutung einer Zeile, sowie Kennzahl, Zeitbezug und Ausschlüsse. Der fachliche Nutzer muss das Ergebnis abnehmen können. „Gold“ besagt ohne diesen Vertrag weder, dass jeder denkbare Fehler ausgeschlossen ist, noch dass jeder Nutzer alle Daten sehen darf. Planen Sie die Zugriffsrechte für jede Schicht separat.
Beispiel: Vom Bestellereignis zur freigegebenen Kennzahl
Das folgende vereinfachte Modell ist ein eigenes redaktionelles Beispiel mit erfundenen Identifikatoren. Es enthält keine Kundendaten oder Messwerte. Eine Quelle liefert Bestellereignisse; das Controlling benötigt die Anzahl bestätigter, aktuell nicht stornierter Bestellungen je Bestelltag.
| Eingang | Inhalt | Behandlung vor Gold |
|---|---|---|
| E1 zu Bestellung B7 | Status bestätigt, Währung EUR | Felder validieren und Ereignis in Silver übernehmen |
| E1 erneut übertragen | Identische Wiederholung | Als Dublette erkennen; keine zweite fachliche Verarbeitung |
| E2 zu Bestellung B8 | Status bestätigt, Währung fehlt | Mit Fehlergrund in Quarantäne halten, bis die Regel erfüllt ist |
| E3 zu Bestellung B7 | Späterer Status storniert, Währung EUR | Als neues Ereignis erhalten und den gültigen Bestellstatus neu bestimmen |
In Bronze bleiben die Eingänge mit Herkunft und Ladezeit nachvollziehbar. Silver unterscheidet Ereignis-ID und Bestell-ID: E1 zweimal ist eine Wiederholung; E1 und E3 sind unterschiedliche Ereignisse derselben Bestellung. Eine einfache Prüfung auf die Bestell-ID würde hier eine zulässige Statusänderung verlieren.
Für Gold zählt die Fachdefinition. Im Modell wird je Bestellung der letzte gültige fachliche Status ermittelt. B7 ist nach E3 storniert und zählt nicht mehr in die Kennzahl. E2 geht bis zu seiner Freigabe nicht ein. Eine Summe der eingegangenen Ereignisse würde eine andere Frage beantworten als die Anzahl gültiger Bestellungen.
Vereinbaren Sie zusätzlich Zeitzone, Bestelltag, Statusreihenfolge und Umgang mit rückwirkenden Änderungen. Falls das Controlling einen historischen Abschlussstand statt des aktuellen Status benötigt, braucht es eine andere Ergebnisdefinition. Diese Entscheidung gehört in den Gold-Vertrag, bevor Sie die Aggregation bauen.
Qualitätsübergaben brauchen Regeln und Owner
Wir empfehlen für jeden Übergang einen kleinen Vertrag. Er nennt Zeilenbedeutung, Schlüssel, Regel, Aktualitätsziel, Fehleraktion, zuständige Personen und Abnahmetest. Damit kann ein Consumer erkennen, was eine Schicht tatsächlich zusagt.
| Vertragsfeld | Bronze → Silver | Silver → Gold |
|---|---|---|
| Grain und Schlüssel | Ein gültiges Ereignis; Ereignis-ID mit getrennt geführter Korrekturversion | Ein Fachstand je Bestellung, daraus Kennzahl je definiertem Bestelltag |
| Regel | Erforderliche IDs, erlaubte Statuswerte, passende Typen und Währung vorhanden | Definierte Statusreihenfolge und Ausschlüsse; Wiederholung erzeugt keine zusätzliche Bestellung |
| Aktualität | Vereinbartes Zeitfenster ab Aufnahme bis gültiges Detail verfügbar ist | Vereinbartes Zeitfenster bis zum freigegebenen Bericht |
| Fehleraktion | Ungültiges Ereignis mit Inhalt und Regelverletzung isolieren | Betroffene Freigabe aussetzen und letzten gültigen Stand kenntlich machen |
| Verantwortung | Technischer Pipeline-Owner und Ansprechperson für die Quelle | Technischer Modell-Owner und fachlicher Kennzahl-Owner |
| Abnahme | E1-Wiederholung, fehlende Währung und erlaubte Statusänderung gezielt testen | Consumer bestätigt Ergebnis vor und nach Stornierung sowie Korrektur |
Ergänzen Sie einen Test mit einer neuen oder geänderten Quellspalte. Das Team muss entscheiden können, ob die Änderung kompatibel ist oder die Verarbeitung gestoppt beziehungsweise der Eingang isoliert wird. Eine Prüfung braucht einen benannten Owner, der den Befund bearbeitet; ein Fehlerzähler allein hält das Datenprodukt nicht aktuell.
Fehler isolieren und kontrolliert wiederholen
Eine verletzte Regel kann verschiedene Folgen haben. Databricks-Pipeline-Expectations können die Verletzung erfassen und die Daten weitergeben, betroffene Zeilen verwerfen oder ein Update abbrechen. Welche Aktion passt, hängt von Ihrem Vertrag ab. Verwerfen Sie fehlende oder widersprüchliche Bestellereignisse nicht stillschweigend, wenn Sie sie später fachlich klären müssen.
Für diesen Fall beschreibt Databricks ein Quarantänemuster für ungültige Datensätze. Unser vereinfachtes Betriebsmodell ergänzt die Zuständigkeit, Korrektur und erneute Abnahme:
- Fehler nachvollziehbar isolieren. Erhalten Sie Originalinhalt, Ereignis-ID, Fehlergrund, Ladezeit und Regelversion. Weisen Sie eine zuständige Person zu.
- Ursache und Korrektur festlegen. Klären Sie, ob die Quelle falsch geliefert hat oder die Regel falsch implementiert war. Erfinden Sie etwa die fehlende Währung nicht; lassen Sie den zulässigen Wert bestätigen.
- Änderung versionieren und gezielt wiederholen. Führen Sie korrigierte Daten oder Regeln nachvollziehbar durch dieselbe Prüfung. Verwenden Sie eine stabile Ereignisidentität und eine Ergebnislogik, die bei Wiederholung keine zusätzliche Bestellung erzeugt.
- Silver und Gold erneut abnehmen. Prüfen Sie den korrigierten Detaildatensatz sowie die betroffene Kennzahl. Geben Sie das Ergebnis nach dem vereinbarten Verfahren frei und schließen Sie den Befund.
Planen Sie verspätete Ereignisse ausdrücklich. Bei Structured Streaming steuern Watermarks unter anderem die Behandlung von Verspätung und die Begrenzung gespeicherten Zustands. Die gewählte Toleranz ist ein technischer und fachlicher Kompromiss. Legen Sie fest, was mit einer Stornierung außerhalb dieses Fensters passiert: etwa kontrollierte Nachverarbeitung und erneute Freigabe des betroffenen Berichtstags. Eine zusätzliche Schicht beantwortet diese Frage nicht automatisch.
Ein Muster, keine fertige Datenplattform
Medallion ordnet Datenzustände und Übergaben. Ein Lakehouse oder Data Warehouse beschreibt dagegen einen größeren technischen beziehungsweise analytischen Rahmen. Das Muster entscheidet nicht für Sie, welche fachlichen Schlüssel, Beziehungen und Historisierungsregeln das Datenmodell braucht.
Auch die organisatorische Verantwortung bleibt eine eigene Entscheidung. Die Databricks-Beschreibung sieht Medallion als mit Data Mesh kombinierbar: Fachliche Domänen können Datenprodukte verantworten und darin logische Schichten nutzen. Aus der Bezeichnung „Silver“ folgt noch kein zuständiges Team.
Technische Garantien separat prüfen. Bronze, Silver und Gold erzeugen keine ACID-Transaktion über alle Pipelines. Solche Eigenschaften hängen von der konkreten Implementierung ab. Delta Lake dokumentiert ACID-Transaktionen und konkurrierende Schreibzugriffe für Tabellen auf unterstütztem Storage. Das ist eine technische Zusage mit einem bestimmten Geltungsbereich.
Trennen Sie außerdem Replay, Time Travel und Backup. Replay verarbeitet Eingänge erneut. Time Travel liest einen erhaltenen Tabellenstand. Backup und Wiederherstellung brauchen ein eigenes Verfahren. Die Databricks-Dokumentation zur Tabellenhistorie erläutert Retentiongrenzen und warnt davor, Historie und Time Travel als langfristige Archiv- oder Backuplösung zu verwenden. Ihr Replayweg funktioniert nur, solange benötigte Eingänge und Regelversionen verfügbar sind.
Wie viel Schichtung und Aktualität brauchen Sie?
Die Azure-Databricks-Dokumentation bezeichnet Medallion als Empfehlung, nicht als Pflicht. Übernehmen Sie die Verantwortlichkeiten, die Ihr Datenprodukt braucht. Eine zusätzliche physische Stufe sollte eine eigene Aufgabe erfüllen: zum Beispiel neue Regeln, einen anderen Zugriffskreis, mehrere Consumer oder einen anderen Aufbewahrungs- und Aktualisierungsbedarf.
Wenn eine weitere Tabelle denselben Inhalt nur unter einem neuen Metallnamen speichert, fehlt die Begründung. Ein kleiner, stabiler Datenpfad mit einem Consumer kann einfacher bleiben. Umgekehrt kann eine materialisierte, validierte Detailschicht sinnvoll sein, wenn mehrere Fachmodelle sie unabhängig nutzen. Schreiben Sie Nutzen und zusätzlichen Betrieb nebeneinander auf.
Aktualität ist ebenfalls eine Anforderung. Databricks beschreibt Continuous, Triggered Incremental und Batch als unterschiedliche Verarbeitungsweisen mit Aktualitäts- und Kostentrade-offs. Benötigt Ihr Bericht nur einen freigegebenen Tagesstand, rechtfertigt das allein keinen dauerhaft laufenden Prozess. Braucht eine Anwendung laufende Updates, testen Sie die gesamte Zeit von der Aufnahme bis zum Consumer.
Planen Sie je Schicht Aufbewahrung, Materialisierung, Aktualisierung, Fehlerprüfung und zuständigen Betrieb. Unser Entscheidungskriterium: Fügen Sie eine Stufe hinzu, wenn sie einen überprüfbaren Nutzer- oder Betriebsjob erfüllt. Budgetieren Sie dabei auch Quarantäne, Nachverarbeitung und erneute fachliche Abnahme.
Wo Sie das Muster umsetzen können
Medallion ist keine exklusiv an Databricks gebundene Software. Databricks und Azure Databricks dokumentieren das Muster für ihre Lakehouse-Umgebung. Google Cloud nennt unter anderem Cloud Storage, BigQuery, Spark, Dataflow und Dataform als mögliche Bausteine für die Umsetzung.
Prüfen Sie zuerst Ihren vorhandenen Stack: Kann er rohe Eingänge nachvollziehbar erhalten, Detailregeln ausführen, Fehler isolieren und ein fachliches Modell kontrolliert bereitstellen? Kann Ihr Team die Abläufe beobachten und wiederholen? Die Antwort ergibt, welche technische Ergänzung nötig ist. Die drei Schichtnamen allein begründen keinen Produktwechsel.
Ihr Startpunkt: ein Datenprodukt mit Abnahme
Beginnen Sie mit einem Datenprodukt und einer benannten Fachperson. Schreiben Sie gemeinsam die Ergebnisdefinition auf. Wählen Sie dann eine Quelle und beschreiben Sie den Weg vom Eingang bis zum Consumer mit den benötigten Übergabeverträgen.
Unser empfohlener Pilot endet erst, wenn Sie vier Fälle nachvollziehen können: einen gültigen Eingang, eine identische Wiederholung, einen fachlichen Fehler und eine verspätete Korrektur. Prüfen Sie anschließend die Zugriffe auf Rohdaten, valide Details und das freigegebene Produkt. Halten Sie Zuständigkeiten, Aktualitätsziel, Aufbewahrung und die Gold-Abnahme in einem kurzen Betriebsblatt fest.
Wenn Sie dafür Integration, Datenmodellierung und Governance gemeinsam weiterentwickeln möchten, beschreibt die bestehende Data-to-AI Foundation von eBiz den zugehörigen Umsetzungsrahmen. Die festgelegten Verträge und Testfälle liefern dafür einen konkreten Ausgangspunkt.