Medallion-Architektur: Bronze, Silber, Gold und die Regeln dazwischen

Drei Namen reichen nicht, weil ein Name nur sagt, wo ein Objekt liegt. Woraus es liest, steht im Code. „Wir haben Bronze, Silber, Gold.“ Diesen Satz hört ein Data & AI Berater zu Beginn vieler Projekte. Der Satz stimmt meist. Die Schemas heißen so, und das Zielbild zeigt drei Kästen mit Pfeilen.

Der Auftrag kommt meist vor einem größeren Schritt. Das Team will neue Berichte bauen, einen Agenten anbinden oder das Warehouse umziehen. Vorher soll jemand prüfen, ob der Code die Schichten einhält. Snowflake nimmt dem Team diese Prüfung nicht ab. Die Plattform kennt Datenbanken, Schemas und Rechte, aber keine Schichten.

Die Abkürzungen entstehen einzeln, und jede hat einen Grund. Ein Bericht braucht schnell ein Feld und liest es aus Bronze. Eine Formel wird kopiert, weil die Sicht in Gold gerade umgebaut wird. Jede Abkürzung für sich ist klein. Zusammen nehmen sie den Namen ihre Bedeutung. Dann bricht eine Änderung an den Rohdaten einen Bericht, mit dem niemand gerechnet hat.

Damit fällt auch das Versprechen der Architektur. Mit jeder Schicht soll die Qualität der Daten steigen. Ob sie das tut, lässt sich messen, mit Regeln wie im Kapitel Datenqualität messen. Der Berater beginnt deshalb nicht beim Zielbild. Er beginnt bei den Abhängigkeiten im Code. Die Tabelle zeigt, wonach er dort sucht. Es sind typische Muster, keine Befunde aus einem Projekt.

In Bronze gehören die Rohdaten, in Silber die bereinigten und verknüpften Daten, in Gold die Tabellen für Berichte. Bekannt gemacht hat die drei Namen Databricks. Die Dokumentation dort nennt die Medallion-Architektur ein Muster, das Daten logisch ordnet, und kennt sie auch als Multi-Hop-Architektur. Microsoft Fabric führt denselben Aufbau als empfohlenen Ansatz und verweist für die Definition auf Azure Databricks. Das ist der Stand November 2026.

Im Deutschen liest man auch Medaillon-Architektur, im Englischen Medallion Architecture mit Bronze, Silver und Gold. Die Idee ist älter als der Name. Ein klassisches Data Warehouse kennt Staging, Core und Data Mart. Die Empfehlungen von dbt nennen die Schichten Staging, Intermediate und Marts. Die Namen wechseln, die Richtung bleibt: unten roh, oben auswertbar.

Für die Prüfung genügen dem Berater drei Überschriften nicht. Er fragt das Team je Schicht nach einem Satz: was hineingehört und was nicht. Bronze übernimmt die Daten eins zu eins, ohne Logik. Silber setzt Datentypen, einheitliche Namen, Schlüssel und Historie. Gold liefert Fakten und Dimensionen mit benannter Granularität und rechnet jede Kennzahl einmal. Aus diesen Sätzen werden später Regeln. Die Tabelle unter der Kurzantwort fasst sie zusammen.

Mit einer Datenbank oder einem Schema je Schicht, denn eine eingebaute Medallion-Funktion hat Snowflake nicht. Die Dokumentation spricht von einem Vokabular, mit dem viele Teams die Schichten ihrer Pipeline benennen. Die Bausteine dafür sind allgemein: Eine Datenbank fasst Schemas zusammen, ein Schema Tabellen und Sichten. Welches davon Bronze heißt, entscheidet das Team.

Für mehrstufige Pipelines aus SQL empfiehlt Snowflake Dynamic Tables. Eine Dynamic Table speichert das Ergebnis einer Abfrage und hält es aktuell. Wie aktuell, sagt der Ziel-Lag: ein Ziel für das Alter der Daten, kein Intervall. Das Muster aus der Dokumentation geht so. Bronze ist die Tabelle, in der die Rohdaten landen. Silber ist eine Dynamic Table mit TARGET_LAG = DOWNSTREAM. Gold trägt den Ziel-Lag als Zeitangabe und gibt damit den Takt vor. Streams und Tasks bleiben der Weg für Ladeschritte, deren Ablauf das Team selbst steuern will. Das ist der Stand November 2026.

Den Berater interessiert daran vor allem, wo die Logik steht. Bei Sichten, Dynamic Tables und Tasks liefert GET_DDL sie mit der Definition. Baut ein Werkzeug außerhalb von Snowflake die Tabellen, steht in der Definition nur das Ergebnis: Spalten und Datentypen. Dann gehört das SQL des Ladeschritts als Datei mit in den Export.

Ein Teil der Schichten lässt sich mit Rechten absichern. Bekommt die Rolle der Berichte nur Leserechte auf Gold, kann kein Bericht Bronze abfragen. Eine Sicht in Gold hält das nicht auf. Wer sie abfragen darf, braucht laut Dokumentation kein Recht auf die Objekte darunter. Rechte begrenzen also die Abnehmer, nicht den Code einer Schicht.

Data Vault ist ein Baumuster für die mittlere Schicht und bringt eine längere Kette mit. Statt drei Schichten sind es oft sechs, dazu kommen die Berichte. Wie diese Kette zu Bronze, Silber und Gold passt, ist eine Lesart und keine Tatsache. Verbreitet ist: Staging zählt zu Bronze, Raw Vault und Business Vault zu Silber, die Marts zu Gold. Manche zählen den Raw Vault zu Bronze.

Der Berater streitet deshalb nicht über Namen. Er schreibt die Kette so auf, wie sie im Warehouse steht. Dann legt er mit dem Team je Schicht fest, woraus sie lesen darf. Erlaubt ist nur der Weg aus der Schicht darunter. Der Zugriff liest nur aus dem Mart, Berichte lesen nur aus Datenprodukten. So gelten dieselben Regeln für drei Schichten wie für sechs.

Was einen Vault im Inneren ausmacht, steht im Kapitel Data Vault: Hubs, Links, Satelliten und die Regeln für Schlüssel und Historie. Für die Schichten zählt hier nur eines. Der Business Vault liest aus dem Raw Vault und nicht am Vault vorbei aus dem Staging.

Im Regelfall nicht: Gold liest aus Silber, und Berichte lesen aus Gold. Liest Gold an Silber vorbei, fehlen Bereinigung, Schlüssel und Historie. Dieselbe Logik entsteht dann ein zweites Mal, diesmal in Gold. Auch Databricks zieht diese Linie. Bronze ist dort für die Verarbeitung nach Silber gedacht, nicht für Analysten. Vom direkten Schreiben aus der Anlieferung nach Silber rät die Dokumentation ab, Stand November 2026.

Zwei Abkürzungen wiegen schwerer als die anderen. Verweist Produktion auf Entwicklung oder Test, gilt das als kritisch, denn dann hängt eine Zahl an Testdaten. Und wiederholt ein Abnehmer eine Formel aus Gold, gibt es bald zwei Werte für dieselbe Kennzahl. Wie man solche Kopien findet, zeigt Single Source of Truth.

Die übrigen Abkürzungen sind nicht alle Fehler. Der Berater behandelt sie als These, bis das Team sie eingeordnet hat. Er legt jede Fundstelle vor und fragt nach dem Grund. Gibt es einen, bleibt die Ausnahme im Katalog stehen: als akzeptiert, mit Begründung und dem Namen dessen, der sie bestätigt hat. Sie kostet dann keine Punkte. Gibt es keinen, wird daraus ein Thema mit Zuständigem. Die Tabelle zeigt die vier Zustände, die eine Regel im Katalog haben kann.

An Regeln, die je ein Satz mit Zielwert sind und als Abfrage auf einem Graphen laufen. Zuerst liest ein Notebook in Snowflake die Definitionen aller Objekte aus, mit einer Rolle, die nur lesen darf. Exportiert werden Struktur und Code, keine Datensätze. Was die Rolle nicht sehen darf, fehlt im Export.

Aus dem exportierten SQL baut ABIS den Graphen: Tabellen, Sichten und Spalten als Knoten, dazu die Data Lineage zwischen Objekten und zwischen Spalten. ABIS verbindet sich dabei nicht mit Snowflake und führt dort nichts aus. Snowflake führt Abhängigkeiten auch selbst, in der Sicht OBJECT_DEPENDENCIES. Datenbewegungen über INSERT oder MERGE fehlen dort laut Dokumentation, Stand November 2026. Deshalb liest der Berater zusätzlich den Code. Wie die Regel für Gold dort als Abfrage aussieht, zeigt das Beispiel unter der Tabelle.

Dann bekommt jedes Objekt seine Schicht. Einen eingebauten Erkenner für Bronze, Silber und Gold hat ABIS nicht. Der Berater legt dafür in ABIS eine eigene Frage mit fester Antwortliste an, die Liste der Schichten. Zuerst entscheiden Regeln, zum Beispiel das Schema oder das Kürzel im Namen. Wo keine Regel greift, schlägt ein Sprachmodell die Schicht vor. Jede Zuordnung bestätigt ein Mensch.

Jetzt ist jede Regel eine Abfrage auf dem Graphen. Die Regel für Gold sucht zum Beispiel jede Kante von einem Objekt in Gold direkt nach Bronze. Derselbe Graph liefert immer dasselbe Ergebnis. Ein Agent kann diese Abfragen über den MCP-Server von ABIS stellen. Er liest dabei den Graphen, nicht die Datenbank. Je Regel zählt der erfüllte Anteil am Ziel. Daraus entsteht ein Score, zum Beispiel 81 von 100 Punkten. Die 19 Punkte bis zum Ziel verteilen sich auf Themen. Der Agent misst, der Mensch entscheidet.

Bevor das Team eine Abkürzung entfernt, zeigt die Impact-Analyse in ABIS, welche Objekte an ihr hängen. So wird aus dem Umbau kein neuer Bruch. Die Tabelle zeigt acht Regeln und einen Hinweis.

Die Prüfung zeigt, ob der Code die vereinbarten Schichten einhält. Ob die Schichten richtig geschnitten sind, entscheidet weiter das Team. Auch die Medallion-Architektur selbst ist kein Muss. Databricks nennt sie eine empfohlene Praxis und keine Pflicht. Ein kleines Warehouse kommt mit zwei Schichten aus, solange feststeht, wer aus wem lesen darf.

• Sie sieht, was die Rolle sieht. Objekte ohne Leserecht fehlen im Export. Sichere Sichten geben ihre Definition nur der Besitzerrolle heraus.
• Geprüft ist der Code, wie er ausgerollt ist. Was im Repository steht, kann davon abweichen. Logik in einem Werkzeug außerhalb von Snowflake fehlt, bis ihr SQL als Datei dazukommt.
• Berichte stehen nicht im SQL-Export. Woraus ein Bericht liest, zeigt erst sein Semantikmodell. Die Verbindung zum Objekt in Snowflake stellt ein Mensch her.
• Die Zuordnung ist eine Entscheidung. Mit einer anderen Zuordnung der Objekte ändert sich das Ergebnis. Deshalb hält der Katalog fest, wer sie bestätigt hat.
• Der Code sagt nichts über die Daten. Ob Silber sauberer ist als Bronze, zeigt erst die Messung an den Daten, Regel für Regel.
• Es ist eine Momentaufnahme. Nach jeder Änderung am Code läuft die Prüfung neu.
• Der Graph liegt lokal. ABIS speichert ihn verschlüsselt auf dem eigenen Rechner. Den Rechner verlassen nur die Aufrufe an das eingestellte Sprachmodell.