Datenmodellierung im Lakehouse: Welches Modell passt wann?
Die Kernaussagen auf einen Blick.
- Datenmodellierung im Lakehouse bedeutet nicht, ein Modell für alles zu wählen. Entscheidend ist, welches Muster zu welchem Datenprodukt passt: Star Schema, Wide Table, Data Vault, SCD, 3NF oder Nested Modeling.
- Delta-Features wie Liquid Clustering, Deletion Vectors, Column Mapping und Time Travel verändern die alte DWH-Rechnung. Speicher ist weniger entscheidend. Wichtiger werden Semantik-Layer, Query-Kosten und Betrieb.
- Vor der Modellierung sollten drei Fragen beantwortet werden: Wer nutzt das Datenprodukt? Welcher Semantik-Layer steht darüber? Und kann das Team das gewählte Muster dauerhaft betreiben?
- Mein Vorschlag: Entscheidet pro Datenprodukt, nicht für die ganze Plattform. Silver sollte meist 3NF-nah bleiben, Gold je nach Konsument Star oder Wide Table nutzen. Data Vault und SCD Typ 2 gehören nur dorthin, wo Audit oder fachliche Historie den Aufwand rechtfertigen. Nested Modeling ist die eigene Entscheidung für JSON, App-Events, IoT und Logs.
Inhaltsverzeichnis
Warum Datenmodellierung im Lakehouse anders entschieden werden muss
Der Bronze- und Silver-Layer im Lakehouse sind gebaut, die Pipelines laufen, die ersten Dashboards ziehen aus Delta. Dann kommt die Frage, die in vielen Teams ohne gemeinsame Grundlage diskutiert wird: Wie modellieren wir Silver und Gold? Der eine möchte eine große denormalisierte Tabelle, weil Delta ohnehin schnell scannt. Der Zweite möchte klassisch Star bauen, weil Power BI das erwartet. Der Dritte schlägt Data Vault 2.0 vor, weil in absehbarer Zeit ein Audit ansteht. Und niemand redet über die App-Events, die als JSON reinkommen und das Schema wöchentlich ändern.
Diese Muster wiederholen sich bei jeder DWH-zu-Lakehouse-Migration und beim ersten Analytics-Rollout auf mehreren Quellsystemen.
Welche Muster brauchen wir wirklich, und welche gehören auf welchen Layer? Welche Kimball-Regeln gelten weiter, und welche Entscheidungen ändern sich durch Delta? Wie halten wir BI-Semantik-Layer, Feature-Serving und ML-Trainingsdaten auf einer gemeinsamen Basis? Wann ist Denormalisierung sinnvoll? Wann braucht es konsistente Stammdaten? Und wann rechtfertigt eine Audit-Anforderung den Data-Vault-Aufwand?
Datenmodellierung im Lakehouse ist keine Grundsatzentscheidung zwischen Kimball, Inmon oder einem anderen Ansatz. Wichtiger ist die Frage, welches Modell zum konkreten Anwendungsfall passt: Reporting, Historisierung, Audit, Machine Learning oder Self-Service Analytics.
Lakehouse-Funktionen wie Time Travel, Change Data Feed, Liquid Clustering und Column Mapping verändern einige klassische DWH-Entscheidungen. Dieser Überblick zeigt die wichtigsten Modellierungsansätze und hilft einzuordnen, wann welches Muster sinnvoll ist.
Was ist Datenmodellierung im Lakehouse?
Datenmodellierung im Lakehouse beschreibt, wie fachliche Objekte in Silver und Gold für BI, Analytics und ML aufgebaut werden: als 3NF-naher Silver mit zentralen Stammdaten, als dimensionales Star Schema, als denormalisierte Wide Table, als Data Vault 2.0 mit Hubs, Links und Satellites, als historisierte Dimension über Slowly Changing Dimensions oder als semi-strukturiertes Modell mit STRUCT, ARRAY, MAP und Variant.
Der klassische Kontext ist Ralph Kimballs dimensionale Modellierung aus den 1990ern für relationale MPP-Warehouses mit teurem I/O und knappem Speicher. Data Vault 2.0 von Dan Linstedt erweitert diesen Rahmen um Audit-Anforderungen und historische Nachvollziehbarkeit. Beide Ansätze sind im Lakehouse nicht überholt. Sie müssen nur anders bewertet werden. Und semi-strukturierte Daten aus App-Events, IoT-Payloads und Cloud-Logs verlangen eine eigene Modellierung, die im klassischen DWH nie sauber gelöst war.
Im Delta Lakehouse verändert sich die Rechnung. Speicher ist günstig, Compute elastisch, und Delta-Features übernehmen Aufgaben, die klassisch das Modell selbst leisten musste. Storage-Kosten fallen in den Hintergrund, Query-Latenz und Passung zum Semantik-Layer rücken in den Vordergrund.
Dieser Artikel ersetzt nicht die Layer-Architektur des Lakehouse. Wie sich Rohdaten, Konformität und Business-Aggregation über die Medaillon-Architektur mit Bronze, Silver und Gold verteilen, klären wir im Überblick zur Medallion-Architektur. Datenmodellierung findet in Bronze, Silver und Gold statt. Hier liegt der Fokus auf den Mustern für Silver und Gold.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was verändert Delta Lake an klassischer Datenmodellierung?
Vier Delta-Features verändern, wie Modellierung im Lakehouse bewertet wird.
Liquid Clustering ersetzt Z-Ordering und Partitionierung durch eine dynamische Cluster-Strategie auf beliebigen Spalten. Tabellen müssen bei Cluster-Änderungen nicht komplett neu geschrieben werden. Star Schemas und Fact-Tabellen profitieren direkt: Fact-Tables lassen sich auf High-Cardinality-Spalten wie customer_id oder transaction_ts clustern. Die Optimierung hängt dadurch weniger stark an klassischer Partitionierung oder Z-Ordering. Details im Überblick zu Liquid Clustering.
Deletion Vectors machen Updates und Deletes ohne Datei-Rewrites möglich. Gelöschte Zeilen werden als Metadaten markiert, der Compaction-Prozess entfernt sie später physisch. SCD Typ 2 kann dadurch günstiger werden, weil Updates weniger vollständige Datei-Rewrites auslösen. Details zur Mechanik im Überblick zu Deletion Vectors.
Column Mapping erlaubt Schema-Evolution ohne Datei-Rewrites. Spalten können umbenannt oder gelöscht werden, ohne Millionen Delta-Files anzufassen. Wide Tables und semi-strukturierte Modelle profitieren spürbar, weil sich denormalisierte und nested Strukturen häufiger fachlich ändern als schmale Dimensionen im Star Schema.
Time Travel liefert Zugriff auf frühere Tabellenstände. Für Debugging, Reproduktion und kurzfristige Rückblicke kann Time Travel reichen. Fachliche Historie über Jahre ersetzt es aber nicht.
Welche Modellierungsmuster gibt es im Lakehouse?
Dieser Überblick ordnet die wichtigsten Muster ein und zeigt, wo sie im Lakehouse sinnvoll sind.
| Muster | Löst welches Problem | Wann es relevant wird |
|---|---|---|
| Star Schema | Dimensionale Fact/Dimension-Trennung im Gold-Layer mit Surrogatschlüsseln, informativen PK/FK-Metadaten und Passung zum Semantik-Layer | Power BI Import-Mode als Hauptkonsument, VertiPaq-Effizienz und stabile Fachlogik mit klar getrennten Kennzahlen und Dimensionen |
| One Big Table (Wide Tables) | Denormalisierte Tabelle für Datenprodukte, die BI und ML gemeinsam nutzen, kompatibel mit Genie Ontology, dbt-Semantic und Cube | BI und ML greifen auf denselben Datensatz zu, Semantik-Layer erwartet eine breite Tabelle, Column Mapping unterstützt Schema-Evolution |
| Data Vault 2.0 | Nachvollziehbare Historie einzelner Attribute mit Hubs, Links und Satellites, Raw Vault vs. Business Vault und Point-in-Time-Tables | Regulatorische Audit-Anforderung (BaFin, MDR, AI Act), hohe Änderungsfrequenz der Quellsysteme, Vault-erfahrenes Team |
| Slowly Changing Dimensions | Historisierte Dimensionen mit , Effective/End-Date-Mustern und Attribut-Hash-Trigger | Historie in Dimensionen, wenn Reports den Stand zum damaligen Zeitpunkt brauchen |
| 3NF im Silver-Layer | Silver-Layer mit zentral gepflegten Stammdaten, damit mehrere Gold-Modelle dieselben Zahlen zeigen | Mehrere Dashboards und Datenprodukte auf derselben Silver-Basis, Konsistenzfragen zwischen Reports |
| Nested Modeling | Semi-strukturierte Modellierung mit STRUCT, ARRAY, MAP und Variant für JSON-Ingestion aus App-Events, IoT und Logs | Verschachtelte Quellen mit häufigen Schema-Wechseln, wenn JSON-Parsing in jedem Query zu teuer wird |
Drei Punkte sind vor der Modellwahl wichtig.
Der erste Punkt ist der Layer. 3NF und Nested Modeling gehören vor allem in den Silver-Layer. Star Schema und Wide Tables sind typische Muster für den Gold-Layer. Data Vault kann im Silver oder als Business Vault im Gold liegen. SCD ist kein eigenes Gesamtmodell, sondern ein Muster für historisierte Dimensionen im Star Schema. Die Muster ergänzen sich also über Bronze, Silver und Gold. Sie sind nicht alle Alternativen auf derselben Ebene.
Der zweite Punkt ist der spätere Semantik-Layer. Power BI im Import-Mode passt besonders gut zu Star-Geometrie und VertiPaq. Genie Ontology, dbt Semantic Layer und Cube funktionieren oft besser auf breiteren Modellen. Deshalb sollte die Modellwahl im Gold-Layer den späteren Konsumenten kennen. Erst das Modell bauen und danach den Semantik-Layer klären, ist die falsche Reihenfolge.
Der dritte Punkt ist der Betrieb. Small Files, OPTIMIZE-Rhythmus und Column Mapping entscheiden, ob ein Modell produktiv funktioniert oder dauerhaft Kosten erzeugt. Kein Muster läuft stabil, wenn Dateigrößen, Schemaänderungen und Wartung nicht mitgedacht werden.
Star Schema, Wide Table, Data Vault oder 3NF: Was passt wann?
Die Entscheidung sollte pro Datenprodukt getroffen werden. Fünf Fragen helfen bei der Entscheidung: Welcher Semantik-Layer nutzt das Modell? Wie hoch ist die Änderungsfrequenz? Welche Audit-Anforderung gibt es? Wie hoch ist der Query-Latenz-Anspruch? Und kann das Team das Muster betreiben?
| Kriterium | Star Schema | Wide Table | Data Vault 2.0 | 3NF-Silver | Nested Modeling |
|---|---|---|---|---|---|
| Welcher Semantik-Layer nutzt das Modell? | Power BI Import, klassische BI-Tools | Genie Ontology, dbt-Semantic, Cube | keine native Passung, downstream Star oder Wide | speist Star oder Wide im Gold | speist flache Gold-Modelle |
| Änderungsfrequenz | moderat, planbare Dimensionen | mittel, Column Mapping hilft | hoch, viele Quell-Wechsel | moderat, Stammdaten-nah | hoch, Schema-Evolution häufig |
| Audit-Anforderung | Time Travel + Unity Catalog reicht meist | Time Travel + Lineage | nachvollziehbare Historie auf Attribut-Ebene | Time Travel + Lineage | Rescue-Column + Lineage |
| Query-Latenz-Anspruch | mittel, Star-Joins auf Delta ok | niedrig, ein Scan reicht | hoch, viele Joins nötig | hoch, viele Joins im Gold-Aufbau | mittel, Column Pruning auf STRUCT |
| Kann das Team das Muster betreiben? | breit verfügbar | wächst | spezialisiert | breit verfügbar | wächst |
Kein Muster ist grundsätzlich richtig. In vielen produktiven Lakehouses koexistieren 3NF-nahe Silver-Layer, Star-Marts für Semantik-Layer, Wide Tables für Analytik- und ML-Workloads, punktuelle Vault-Strukturen für auditierte Bereiche, historisierte Dimensionen für Vertragslaufzeiten und Nested-Modelle für App-Events. Wichtig ist, dass diese Mischung bewusst geplant wird und nicht zufällig entsteht.
Wie spielen die Muster in Silver und Gold zusammen?
Ein produktives Lakehouse kombiniert mehrere Muster über Bronze, Silver und Gold. Ein realistisches Zielbild sieht meist so aus:
- Silver-Layer: zentral gepflegte Stammdaten in 3NF-naher Modellierung, damit spätere Gold-Modelle auf derselben Grundlage rechnen. Semi-strukturierte Quellen wie App-Events oder IoT-Payloads liegen als STRUCT/ARRAY im Silver und werden erst im Gold gezielt flach modelliert. Wo Nachvollziehbarkeit schon im Silver entscheidend ist, tritt Raw Vault als Alternative zum 3NF-Silver auf.
- Gold-Layer: Star-Marts für klassische BI mit Power BI, Wide Tables für BI+ML-Shared-Datensätze und Semantik-Layer wie Genie Ontology oder dbt-Semantic. SCD Typ 2 rechtfertigt sich dort, wo die Historie fachlich modelliert werden muss, etwa bei Vertragslaufzeiten mit Preis-Änderungen. In auditierten Bereichen kann ein Business Vault dazukommen.
- Übergreifend: Time Travel und Unity Catalog Lineage decken viele Nachvollziehbarkeitsanforderungen ab, bevor Vault als eigenes Muster nötig wird. Column Mapping hilft bei Schemaänderungen über mehrere Muster hinweg, und Liquid Clustering optimiert Zugriffe unabhängig von der klassischen Star-Geometrie.
Wie die Modellierung dann in ausführbaren Pipelines materialisiert wird, zeigen wir im Überblick zu Declarative Pipelines auf Databricks.
Grenzen der Datenmodellierung im Lakehouse
Die Musterliste nimmt die Modellierungsentscheidung nicht ab. Fünf Grenzen sollten vor der Auswahl klar sein.
Small Files bleiben ein zentrales Betriebsrisiko. Streaming-Ingestion und häufige Micro-Batches können Millionen kleiner Delta-Dateien erzeugen. Ohne regelmäßige Compaction leidet jedes Muster: Star, Wide, Vault und Nested gleichermaßen. OPTIMIZE sollte deshalb als feste Betriebsaufgabe eingeplant werden, bevor das erste produktive Modell live geht.
Jeder Semantik-Layer bringt eigene Anforderungen mit. Power BI im Import-Mode passt besonders gut zu Star-Schema-Geometrie und VertiPaq. Wide Tables können funktionieren, brauchen aber klare Metrikdefinitionen und Governance im Semantik-Layer. Genie Ontology, dbt Semantic Layer und Cube arbeiten oft besser mit breiteren Modellen. Die Modellwahl im Gold-Layer sollte deshalb den späteren Konsumenten kennen.
Die Erfahrung des Teams begrenzt die Modellwahl. Data Vault 2.0 ohne erfahrenes Team endet schnell in einer schwer wartbaren Hub-Satellite-Struktur. Wide Tables ohne klare Ownership führen zu unterschiedlichen Metrikdefinitionen. Nested Modeling ohne Schema-Hints und Monitoring bricht bei jedem größeren Payload-Wechsel.
Iceberg ändert die technische Optimierung, aber nicht die Grundfrage. Iceberg arbeitet mit Hidden Partitioning und Partition Evolution über Metadaten. Delta setzt auf Liquid Clustering. Die Entscheidung zwischen Star, Wide, Vault, SCD, 3NF und Nested bleibt trotzdem dieselbe. Es ändern sich die Optimierungsbausteine unter dem Modell, nicht die fachliche Modellierungsfrage. Wie sich die Formate im Lakehouse einordnen, zeigen wir im Überblick zu Iceberg.
Migrationen bringen alte Modellierungsentscheidungen mit. Ein bestehendes DWH mit Kimball-Star und komplexen SCD-Typ-2-Mustern lässt sich nicht einfach in ein Wide-Table-Modell überführen. Die Zielmodellierung muss zur Migrationsstrategie passen. Wie Warehouse-Migrationen aussehen, ordnen wir im Überblick zur Lakehouse-Migration ein.
Fazit
Datenmodellierung im Lakehouse ist keine Plattform-weite Grundsatzentscheidung, sondern eine Wahl pro Datenprodukt zwischen Star, Wide Table, Data Vault, SCD, 3NF und Nested Modeling.
Datenmodellierung wird wichtig, sobald Silver und Gold produktiv genutzt werden und mehrere Datenprodukte, Teams oder Konsumenten darauf aufbauen. Wer aus DWH-Gewohnheit überall Star Schema baut oder aus Lakehouse-Euphorie überall One Big Table nutzt, entscheidet am Bedarf vorbei.
Besonders relevant ist die Frage bei DWH-Migrationen, mehreren Datenprodukten, gemischten Konsumenten aus BI, ML und Feature-Serving, Audit-Anforderungen oder vielen semi-strukturierten Quellen.
Teams mit einem ersten BI-Anwendungsfall brauchen keinen Modellierungsbeschluss für die ganze Plattform. Wichtiger ist dann, dass Bronze und Silver sauber verantwortet und verstanden werden.
Mein Vorschlag: Entscheidet pro Datenprodukt. Silver eher 3NF-nah, Star Schema für klassische BI im Gold-Layer, Wide Tables für gemeinsame BI- und ML-Datensätze, Data Vault und SCD Typ 2 nur bei klarer Audit- oder Historisierungsanforderung, Nested Modeling für App-Events, IoT-Payloads und Logs.
Am Ende sollte klar sein, welches Modell zu welchem Datenprodukt, welchem Konsumenten und welchem Betriebsmodell passt.
Entscheidet pro Datenprodukt: Silver eher 3NF-nah, Star Schema für klassische BI im Gold-Layer, Wide Tables für gemeinsame BI- und ML-Datensätze, Data Vault und SCD Typ 2 nur bei klarer Audit- oder Historisierungsanforderung.
Macht eure Modellierungsstrategie Datenprodukte klarer oder nur komplexer?
Ob eure Modellierungsstrategie Datenprodukte klarer macht oder unnötige Komplexität erzeugt, lässt sich in einem Data & AI Assessment prüfen.
- welche Silver- und Gold-Datenprodukte sich für Star, Wide, Data Vault, SCD, 3NF oder Nested Modeling eignen
- welche Risiken bei Semantik-Layer, Governance und Betrieb vor dem Ausbau geklärt werden sollten
- welcher Modellierungs- und Migrationsansatz zu eurer Plattform passt
FAQ
Ja. Kimball-Regeln greifen im Gold-Layer weiter, wenn ein klassischer BI-Semantik-Layer wie Power BI der Hauptkonsument ist. Was sich ändert, ist die Optimierungs-Argumentation. Die klassische Star-Schema-Optimierung ist mit Delta, Liquid Clustering und günstigem Storage nicht mehr das einzige Argument. Die Passung zum Semantik-Layer wird zum Hauptargument.
