Die Raumstation: Medallion-Architektur als Herzstück der Lakehouse-Mission
- Databricks
- Databricks
- 7 Min Lesezeit
Dr. Andreas Wagner
Die Medallion-Architektur stellt ein prominentes Design Pattern in der modernen Entwicklung von Datenplattformen dar und dient als Blueprint für die logische Organisation von Daten innerhalb eines vereinheitlichten Data Lakehouse. Der Begriff wurde von Databricks um 2019 populär gemacht und kurz nach der Veröffentlichung von Delta Lake als Kernkomponente der sich entwickelnden „Lakehouse“-Vision eingeführt. Seit seiner Einführung hat sich der Begriff branchenweit durchgesetzt.
Stellen Sie sich eine Raumstation vor: Sie ist kein monolithischer Block, sondern ein präzise aufgebautes System bestehend aus spezialisierten Modulen – jedes mit einer klar definierten Aufgabe, jedes auf das nächste angewiesen. Genau so funktioniert auch die Medallion-Architektur. Ihre drei Schichten – Bronze, Silver und Gold – sind die Module der Raumstation. Jede Ebene erhöht die Verlässlichkeit, die semantische Dichte und den geschäftlichen Nutzen der Daten, ohne dabei die Verbindung zu den ursprünglichen Rohdaten zu verlieren.
Inhaltsverzeichnis
Wie in einer echten Raumstation übernimmt jedes Modul eine klar definierte Aufgabe – und kein Modul übernimmt die Arbeit eines anderen. Die Medallion-Architektur erfordert daher eine strikte Trennung der technischen Zuständigkeiten über ihre drei Hauptschichten hinweg:
Die Bronze-Ebene ist die Andockstation der Raumstation: Hier landen alle eingehenden Datenströme – aus Transaktionsdatenbanken, externen SaaS-Anwendungen, Real-Time-Message-Queues wie Kafka oder Datei-Uploads. Das Grundprinzip: alles erfassen, nichts transformieren. Originalgetreue Wiedergabe, ohne Ausnahme. Die Daten werden genauso geschrieben, wie sie im Quellsystem vorliegen, wobei ursprüngliche Strukturen, verschachtelte semi-strukturierte Daten und Schemata erhalten bleiben. Um vollständige Nachvollziehbarkeit und eine spätere Neuverarbeitung zu gewährleisten, werden jedem Datensatz beim einfügen Systemmetadaten hinzugefügt, wie z. B. Ingestion-Timestamps, Prozess-IDs und Quellsystem-Identifikatoren. Bronze-Tabellen sind in der Regel Append-Only und immutable (unveränderlich), d.h. sobald Daten einmal geschrieben wurden, werden diese nicht verändert. Sie dienen als Single-Source-of-Truth, aus der alle nachgelagerten Schichten systematisch zu jedem beliebigen Zeitpunkt neu erstellt werden können, ohne die operativen Quellsysteme erneut abfragen zu müssen.
Im Verarbeitungslabor der Raumstation werden die angelieferten Rohdaten in Ordnung gebracht. Die Silver-Ebene transformiert den Rohmaterialstrom in eine bereinigte, konforme und einheitliche Unternehmenssicht. Die hier angewandten Transformationen sind deterministisch und standardisiert und konzentrieren sich auf:
- Harmonisierung und Weiterentwicklung von Schemata
- Deduplizierung redundanter Datensätze
- Standardisierung von Namenskonventionen und Datenformaten
- Behandlung/Korrektur fehlender bzw. falscher Werte
- Verknüpfung unterschiedlicher Daten-Bestände, um eine integrierte Sicht zu ermöglichen
Im Einklang mit dem modernen Data-Engineering-Paradigma priorisiert die Silver-Schicht in der Regel einen ELT-Ansatz. Es wird nur eine „gerade ausreichende“ Bereinigung angewendet, um eine konsistente Darstellung der zentralen Geschäftseinheiten (wie konforme Ansichten von Kunden, Transaktionen oder Produkten) zu präsentieren. Sie nutzt häufig die dritte Normalform (3NF) oder Data-Vault-Architekturen, um eine möglichst umfassende Integration, Auditierbarkeit und die Schaffung erster Qualitätssicherungsmassnahmen zu ermöglichen. Hierdurch wird sichergestellt, dass bei einer Wiederverwendung der Daten keine Qualitätsmängel in verschiedene Use-Cases multipliziert werden.
Die Kommandozentrale ist das Herzstück der Raumstation – der Ort, von dem aus Entscheidungen getroffen werden. Die Gold-Ebene aggregiert die vorbereiteten Daten aus dem Silver-Modul und stellt sie für spezifische Nutzungszwecke bereit. Diese Ebene ist explizit auf Lesezugriffe optimiert und auf Reporting, Self-Service-BI sowie Modelle für Machine Learning zugeschnitten. In den Gold-Tabellen werden komplexe Business-Logiken, Berechnungen und Aggregationen angewendet. Um die Abfrageleistung zu maximieren und den Bedarf an Tabellenverknüpfungen zur Laufzeit zu minimieren, werden die Daten i.d.R. denormalisiert. Die Gold-Ebene nutzt oftmals Star-Schemas nach Kimball (mit stark strukturierten Fakten- und Dimensionstabellen) oder für die Ausführungsgeschwindigkeit optimierte Data Marts nach Inmon.
Das Zusammenspiel der Module: Multi-Hop-Architecture als Prinzip
Daten durchlaufen die Raumstation Modul für Modul – deshalb spricht man auch von einer Multi-Hop-Architecture. Dies bringt den Vorteil, dass für jeden Datenfluss ein explizites Zwischenergebnis produziert wird, dass für weitere Prozesse verwendet werden kann, wodurch potenziell eine Vervielfältigung von Business-Logiken verhindert/reduziert werden kann. Ausserdem wird eine Trennung von Verantwortlichkeiten (Separation of Concerns) geschaffen, wodurch jede Schicht eine deutlich homogenere Summe an Aufgaben übernimmt.
Mit jeder Schicht bzw. mit jedem „Hop“ steigt der Bearbeitungsaufwand, der in die Daten investiert wird, sowohl was Rechenkapazitäten angeht, also auch Aufwände bzgl. Entwickler-Kapazitäten. Aus diesem Grund müssen die Aufwände im Verlauf des Datenflusses immer stärker begründet werden, im Idealfall durch langlebige, rentable Use-Cases und einer breiten Nutzerschaft der Daten. Während auf die Bronze-Daten nur wenige spezialisierte Entwickler:innen (z.B. Data Engineers) Zugriff haben, können auf die Silver-Daten auch schon einige (fortgeschrittene) Analyst:innen zugreifen.
Medallion: Mehr als ein Marketing-Begriff
Die mehrschichtige Architektur, die sich hinter dem Begriff Medallion verbirgt, ist nicht gänzlich neu. Moderne Datenplattformen haben einen mehrstufigen Verfeinerungsansatz übernommen, der bereits seit mindestens Ende der 1990er Jahre existiert. In der Vergangenheit haben Data-Warehouse-Architekt:innen ähnliche physische Grenzen geschaffen und die aufeinanderfolgenden Stufen als „Rohdaten“- („Integrations“- oder „verarbeitete“) und „Präsentations“- („verfeinerte“) Schichten bezeichnet.
Bei dieser Architektur war allerdings oftmals die Problematik vorhanden, dass ein zentrales Team diese betreut und entwickelt hat und die Nutzer ausschliesslich auf die finalen Outputs (Data Marts) zugreifen konnten/durften.
Hierdurch entstand ein Engpass beim zentralen Team für die Entwicklung neuer Anforderungen und dadurch lange Wartezeiten bei den Stakeholdern. Dies hat den Aufbau eigener Datenbestände (Silos) in den Fachabteilungen gefördert. Denn die Fachbereiche waren oftmals nicht auf 100% aufbereitete Daten angewiesen, v.a. nicht dann, wenn Proof of Concepts (PoC) oder andere experimentelle Projekte angestossen werden sollten. Etwas weniger aufbereitete Daten waren oftmals um ein Vielfaches besser als keine Daten zu haben. Die Medallion-Architektur modernisiert diese langjährige Praxis und optimiert sie speziell für die dezentrale Skalierung und die offenen Speicherformate der Cloud-nativen Lakehouse-Ära.
2. Ressourcenplanung an Bord: Speicher-Volumen und TCO
Ein häufiges Missverständnis bei der Budgetierung lautet: „Drei Schichten bedeuten eine Verdreifachung der Speicherkosten (Raw * 3).“ Diese isolierte Sichtweise greift zu kurz und vernachlässigt das physische Verhalten strukturierter Datenströme sowie die Gesamtwirtschaftlichkeit einer modernen Cloud-Architektur.
Warum das Datenvolumen im Verlauf schrumpft
Tatsächlich nimmt das reine physische Speichervolumen mit jeder Veredelungsstufe drastisch ab.
- Bronze fungiert als unbereinigter Auffangbehälter und speichert die ungefilterte Flut an Eingangsdaten (z. B. sekündliche IoT-Temperatursignale über Monate hinweg).
- Silver konsolidiert den CDC-Strom. Anstatt jede historische Änderung aufzubewahren, werden Duplikate entfernt und Zustände bereinigt zusammengefasst.
- Gold speichert hochgradig verdichtete und aggregierte Kennzahlen auf Stunden-, Tages- oder Routenebene.
Das Speicherprofil verhält sich somit wie eine Pyramide: Die hochreinen Gold-Tabellen machen in der Praxis oft weniger als 5 % des ursprünglichen Bronze-Volumens aus. Es gilt also keineswegs eine pauschale Verdreifachung des Volumens.
TCO-Betrachtung: Speicherung vs. Compute und Personal
Der isolierte Blick auf die Festplattenkosten ignoriert die eigentlichen Treiber der TCO (Total Cost of Ownership – Gesamtkosten des Betriebs):
- Speicherplatz ist billig: Cloud-Objektspeicher (z. B. Azure Blob Storage oder AWS S3) stellt mit Kosten von ca. 0,02 USD pro Gigabyte und Monat einen zu vernachlässigenden Kostenfaktor dar.
- Compute (Rechenleistung) ist extrem teuer: Müssten BI-Analyst:innen und Data Scientists ihre Abfragen jedes Mal direkt auf unbereinigten, rohen Bronze-Daten ausführen, würden bei jeder Ausführung enorme Rechenkosten für temporäre Filterung, Typkonvertierung und Deduplizierung anfallen. Die Medallion-Architektur spart bares Geld, indem sie rechenintensive Standard-Transformationen nur einmalig beim Übergang in die Silver-Schicht ausführt und diese Ergebnisse persistiert.
- Mitarbeiterkapazitäten schonen: Wenn Daten bereits sauber strukturiert in Silver und Gold bereitstehen, entfällt das repetitive Schreiben von SQL-Reinigungslogiken in nachgelagerten Systemen. Dies spart wertvolle Arbeitszeit bei Analytics Engineers und Fachanwendern.
- Resistenz und Sicherheit durch Redundanz: Das bewusste Vorhalten der Schichten schafft eine robuste Ausfallsicherheit. Sollte eine Transformation fehlerhaft sein oder ein Quellsystem ausfallen, kann die Pipeline ab der Bronze-Ebene unabhängig und historisch korrekt rekonstruiert werden, während nachgelagerte Anwendungen auf Basis der Silver- und Gold-Stände ungestört weiterarbeiten.
Andreas & Yvonnes Databricks-Guide
Möchten Sie alle wichtigen Informationen auf einen Blick?
Laden Sie sich jetzt den kostenlosen Guide zur SAP Databricks!
3. Missionstakt: Batch-Prozessierung vs. Echtzeit-Datenströme
Die Medallion-Architektur wurde historisch für die Batch-Prozessierung (stapelweise Verarbeitung) entworfen. Auch im Jahr 2026 bleibt die tägliche oder stündliche Batch-Verarbeitung der unangefochtene Standard in Unternehmen – sie reicht für über 90 % aller betriebswirtschaftlichen Szenarien (wie Finanz-Reportings, Bestandsabgleiche und SLA-Abrechnungen) vollkommen aus.
Für jene Use-Cases, die zwingend Echtzeit-Geschwindigkeit erfordern (z. B. die sofortige GPS-basierte Routen-Warnung bei Temperaturabweichungen während der Fahrt), muss die Architektur jedoch nicht verworfen werden. Real-Time-Verarbeitungen werden pragmatisch als zielgerichtete Ergänzung in den Gesamtablauf integriert:
- Der IoT-Strom schreibt über schlanke Streaming-Pipelines kontinuierlich in die Bronze-Tabelle.
- Während Standard-Tabellen im Batch aktualisiert werden, können Echtzeit-Anforderungen über inkrementelle Materialized Views (materialisierte Sichten) oder strukturierte Micro-Batches direkt auf denselben physischen Tabellen aufsetzen. Dadurch bleibt die Architektur homogen und wartbar, ohne dass unnötige Komplexität auf Szenarien übertragen wird, die kein Real-Time benötigen.
4. Andocken erlaubt: Medallion trifft auf Data Mesh
In modernen Enterprise-Datenplattformen ist der Übergang zwischen der Medallion-Architektur und dem Data Mesh-Paradigma (dezentrale Organisation von Daten nach Fachdomänen) fließend. Diese Konzepte stehen sich nicht im Weg – sie sind vollkommen kompatibel.
Historisch wurden DWH-Daten meist nach logischen Zuständigkeiten strukturiert (z. B. getrennte Speicherbereiche für Finance, Marketing, HR oder Logistik). Diese klassische Strukturierung deckt sich exakt mit dem Domain-Ownership-Prinzip des Data Mesh.
Bronze-Layer vs. Source-Aligned Data Product
Versteht man den Bronze-Layer einer Domäne nicht nur als passiven Data Dump, sondern wendet bereits dort fundamentale, nicht-betriebswirtschaftliche Basis-Operationen an (wie eine formale Konvertierung in das Delta-Format, technische Deduplizierung oder die Zuweisung globaler Metadaten), ist der Unterschied zu einem Source-Aligned Data Product (quellnahes Datenprodukt) de facto nicht mehr vorhanden. Dies gilt umso mehr, wenn man berücksichtigt, dass eine Medallion-Architektur nicht zwingend von einem zentralen IT-Team verantwortet werden muss, sondern dezentral in den Domänen betrieben werden kann.
Gold-Layer vs. Consumer-Aligned Data Product
Der Unterschied zwischen klassischen Data Marts, Gold-Layer-Outputs oder Consumer-Aligned Data Products (konsumentenorientierten Datenprodukten) ist rein begrifflicher Natur. Alle beschreiben geschäftsfertig aufbereitete, semantisch reiche Daten, die für den Endverbrauch optimiert sind.
Der fundamentale Unterschied liegt nicht im finalen Output, sondern in der Freigabe-Philosophie. In klassischen DWH-Ansätzen durften Fachanwender ausschließlich auf die fertigen Gold-Marts zugreifen, was die bekannten Entwicklungs-Engpässe bei der IT erzeugte. Die Medallion-Architektur im Lakehouse bricht dieses Silo auf, indem sie fortgeschrittenen Nutzern und Daten-Wissenschaftlern gezielten Lesezugriff auf die bereinigten Zwischenergebnisse (die Silver-Schicht) gewährt. Das vereint die Flexibilität eines dezentralen Data Mesh mit der strukturellen Verlässlichkeit einer klassischen Datenplattform.
5. Fazit und Architektur-Empfehlung
Die Medallion-Architektur ist weit mehr als ein theoretisches Ordnungssystem – sie ist das pragmatische Fundament für Skalierbarkeit, Vertrauen und Wirtschaftlichkeit im modernen Daten-Ökosystem.
Für Ihre Architektur-Roadmap leiten wir drei Empfehlungen ab:
- Kein Direktzugriff auf Rohdaten: Verwehren Sie Fachbereichen den Zugriff auf den Bronze-Layer, um die Entstehung von Schatten-IT und widersprüchlichen Kennzahlen zu verhindern.
- Silver als Innovations-Plattform freigeben: Stellen Sie Ihren fortgeschrittenen Analysten und Data Scientists den bereinigten Silver-Layer für experimentelle PoCs zur Verfügung, um den zentralen IT-Flaschenhals der Vergangenheit endgültig zu eliminieren.
- Holistische Kostenplanung: Betrachten Sie Speicher- und Compute-Kosten als Einheit. Die bewusste Redundanz persistenter Zwischenschichten senkt Ihre Cloud-Kosten durch vermiedene Doppel-Berechnungen drastisch.
Ihre Architektur ist individuell – Lassen Sie uns ins Gespräch kommen CTA
Die Strukturierung Ihrer Datenflüsse entscheidet maßgeblich über die Performance und Akzeptanz Ihrer BI- und AI-Plattform. Gemeinsam analysieren wir Ihre bestehende SAP-Landschaft und entwerfen eine Raumstation, die hält – auch wenn die Mission länger dauert als geplant.
Ihre Datenstrategie ist individuell – Ihre Beratung sollte es auch sein.
Die Wahl zwischen diesen Methoden hängt von unzähligen Faktoren ab: Ihrer bestehenden Systemlandschaft, Ihren Unternehmenszielen und Ihrer Datenkultur. Eine Standardantwort gibt es nicht.
Lassen Sie uns unverbindlich darüber sprechen, welcher Weg für Sie der richtige ist.
Kontaktieren Sie uns für ein persönliches Gespräch.
