Nested Data Modeling im Delta Lake: JSON, STRUCT oder Variant?

App-Events, IoT-Payloads und Cloud-Logs haben oft dasselbe Problem: Sie liefern verschachteltes JSON mit vielen Feldern, von denen viele selten gefüllt sind, und das Schema ändert sich regelmäßig. Wer diese Daten ins Lakehouse lädt und erst im Query entscheidet, wie sie gelesen werden, zahlt doppelt. Einmal durch wiederholtes JSON-Parsing in Abfragen. Und ein zweites Mal, weil nachgelagerte Tabellen und Reports bei Schemaänderungen instabil werden.

Star Schema, Wide Tables und Data Vault ordnen wir in der Datenmodellierung im Lakehouse für den Delta-Gold-Layer ein. Semi-strukturierte Quellen kommen dort nicht vor. Für semi-strukturierte Daten braucht es eine eigene Modellierungsentscheidung. Welche Felder bleiben verschachtelt? Welche werden flach modelliert? Und welche gehören in eine Variant-Spalte?

Ab wann ist ein EXPLODE in jeder Abfrage teurer als eine flache Tabelle, die schon beim Ingest vorbereitet wird? Wie verhindert _rescued_data, dass neue Felder den Stream brechen, ohne dass die Spalte unbemerkt voll läuft? Wann trägt eine Variant-Spalte für CloudTrail besser als eine typisierte STRUCT-Definition? Warum werden BI- und Semantik-Layer schwer nutzbar, sobald der Silver-Layer zu tief verschachtelt ist?

Die Modellierungsentscheidung fällt pro Feldgruppe. Eine Event-Tabelle kann Kontextdaten als STRUCT behalten und wichtige Felder wie event_type, revenue oder product_id zusätzlich flach speichern. Der Fehler wäre, alle JSON-Felder nach derselben Regel zu behandeln.

Diese Entscheidung wirkt sich direkt auf Bronze, Silver und Gold aus. Bronze hält das Roh-JSON und erzwingt nur das nötigste Schema. Silver flacht Arrays für Aggregate, materialisiert Kernfelder aus STRUCTs und behält die Sub-Strukturen dort, wo Downstream-Konsumenten sie brauchen. Gold liefert das aggregierte, semantisch klare Endprodukt ohne JSON-Blobs und ohne tief verschachtelte Strukturen. Die Regel dahinter: alles, was BI klassisch aggregiert und dessen Konsumenten die Struktur ignorieren, gehört flach in den Gold-Layer. Alles mit Downstream-Iteration über Sub-Records, hoher Schema-Change-Rate oder klar getrennter Semantik bleibt nested. Praktisch wird es ab mehr als drei Ebenen schwierig. Viele BI-Tools und Semantik-Layer werden dann unübersichtlich oder schwer nutzbar.

STRUCT-Zugriff ist meist günstig. Parquet legt jedes Sub-Feld eines STRUCT als eigene Spalte ab; das Dremel-Encoding kodiert Verschachtelungs-Tiefe über Repetition und Definition Levels (Apache-Parquet-Spec zu Nested Encoding). Wenn nur context.user.id gebraucht wird, kann die Engine gezielt dieses Unterfeld lesen, statt die gesamte Struktur zu verarbeiten. Column Pruning und Data Skipping funktionieren auf Nested-Feldern.

ARRAY-Explode kann teuer werden. EXPLODE vervielfacht die Zeilenanzahl abhängig von der Länge des Arrays und braucht vor Aggregation meist eine GROUP BY-Zusammenführung. Kombiniert mit einem WHERE-Filter auf ein STRUCT-Feld innerhalb des Arrays wird der Query-Plan schnell mehrstufig. Die praktische Regel: EXPLODE möglichst im Gold-Layer vorbereiten und nicht jedes Mal in interaktiven BI-Abfragen ausführen.

MAP ist flexibel, hat aber Nachteile: weniger Column Pruning, weniger Statistiken und oft zusätzliche Casts beim Zugriff auf einzelne Keys. Für dichte MAPs mit 20 stabilen Keys ist ein STRUCT die bessere Wahl.

JSON als STRING ist meist die teuerste Option, sobald Felder regelmäßig abgefragt werden. Jede Abfrage, die ein Sub-Feld braucht, parst den kompletten JSON-Blob neu, entweder mit from_json und expliziter Schema-Angabe oder mit :-Path-Notation. Bei Query-Frequenz jenseits von Ad-hoc wird der CPU-Overhead sichtbar. Variant schließt diese Lücke: flexibler als STRUCT, aber deutlich besser abfragbar als ein reiner JSON-STRING.

Nested Schemas ändern sich, und Delta liefert vier Modi für den Umgang mit neuen Feldern via cloudFiles.schemaEvolutionMode (Databricks Docs zu Auto Loader Schema-Evolution). addNewColumns erweitert das Schema, pausiert den Stream und erzwingt einen kontrollierten Restart. So können Downstream-Tabellen bewusst angepasst werden. addNewColumnsWithTypeWidening erweitert das Schema und kann bestimmte Typen verbreitern (Integer zu Long); Unpassendes landet in _rescued_data. rescue hält das Schema stabil und schreibt neue oder unpassende Felder in _rescued_data. failOnNewColumns bricht bei neuen Feldern ab und passt für Umgebungen mit strengem Change Management.

Column Mapping (delta.columnMapping.mode = 'name') kann Umbenennungen in verschachtelten Feldern ermöglichen, ohne die Dateien neu zu schreiben. Ein context.user.email kann zu context.user.email_address werden, ohne dass die Parquet-Dateien neu geschrieben werden. Die physische Speicherung bleibt stabil, während die logischen Feldnamen geändert werden können. Wie Column Mapping mit Time Travel und Change Data Feed zusammenspielt, klären wir im Überblick zum Change Data Feed.

Für den Betrieb ist entscheidend: addNewColumns als Default-Modus mit Alert-Mechanismus auf die pausierten Streams. Schema-Hints als festgelegtes Zielschema für die bewusst geplanten Felder. _rescued_data mit Monitoring auf die Rest-Rate. So bleibt das Modell anpassbar, ohne Schemaänderungen unkontrolliert durchlaufen zu lassen.

Nested Modeling ist hilfreich, erzeugt aber typische Probleme, wenn nicht klar entschieden wird, welche Felder nested bleiben und welche flach werden.

Die größten Probleme sind selten rein technisch. Meist fehlt eine klare Modellierungsregel. Nested Modelle brauchen mehr Modellierungs-Disziplin als flache Tabellen, weil die Entscheidung pro Feldgruppe fällt und dokumentiert werden muss. Ein Silver-Modell ohne Schema-Hints und ohne Monitoring von _rescued_data bleibt langfristig instabil. Es verschiebt das Schema-Problem in die Zukunft, bis der nächste Firmware-Wechsel den Ingest bricht.