One Big Table im Lakehouse: Wann Wide Tables sinnvoll sind

Eine One Big Table ist eine breite, denormalisierte Tabelle. Sie enthält Kennzahlen und die wichtigsten Dimensionsattribute in einer gemeinsamen Struktur. Statt einer schmalen fact_sales, die auf Kundendimension, Produktdimension und Datumsdimension verweist, enthält eine fact_sales_wide viele dieser Attribute direkt. Die Wide Table kann 80, 150 oder 300 Spalten haben.

Eine fact_sales_wide mit rund 150 Spalten (Grain: eine Zeile pro Position, Liquid Clustering auf kunde_id und datum) enthält dann Kern-Fakten (sale_id, datum, menge, umsatz, rabatt), denormalisierte Kunden-Attribute (kunde_id, kunde_name, kunde_region, kunde_typ, kunde_wert_klasse), denormalisierte Produkt-Attribute (produkt_id, produkt_name, produkt_kategorie, produkt_marke, produkt_ean) und Zeit-Attribute (jahr, quartal, monat) direkt in der Tabelle.

Der Grundgedanke: alle für die Analyse nötigen Daten in einer breiten, denormalisierten Tabelle zusammenführen. Der klassische Anwendungsfall ist ein Datensatz, den mehrere Gruppen gleichzeitig nutzen: BI für Dashboards, ML für Features und Data Science für Analysen.

Eine spezielle Wide-Table-Variante ist das Activity Schema, geprägt von Ahmed Elsamadisi und der Narrator-Community. Es modelliert alle Business-Ereignisse als eine einzige Aktivitäts-Tabelle mit fester schmaler Grundstruktur: customer, timestamp, activity, feature_json. Der Datensatz wächst stärker über Zeilen als über Spalten. Activity Schema ist eine Sonderform der Wide Table und ersetzt eine klassische OBT nicht.

Auf Delta verändert sich die technische Bewertung von Wide Tables gegenüber älteren columnaren Warehouses. Parquet komprimiert wiederholte Attribut-Werte effizient. Eine customer_region-Spalte mit fünf Ausprägungen und Millionen Zeilen kostet dank Dictionary Encoding wenig Storage. Liquid Clustering ermöglicht bis zu vier Cluster-Keys auf High-Cardinality-Spalten, wie die Databricks-Doku zu Liquid Clustering festhält, und ersetzt Z-Ordering und Partitionierung. Column Mapping macht Rename-Operationen ohne File-Rewrite möglich. Diese drei Bausteine machen Wide Tables auf Delta praktikabler als früher.

Wie sich Wide Tables gegen Nested-Modelle mit STRUCT und ARRAY abgrenzen, zeigen wir im Überblick zu Nested Modeling im Delta.

Der Semantik-Layer ist der wichtigste Grund, warum One Big Table heute wieder anders bewertet wird. Drei Ansätze sind hier besonders relevant: Genie Ontology auf Databricks, dbt Semantic Layer und Cube.

Genie Ontology ist die Databricks-eigene Semantik-Schicht für AI/BI-Genie. Der Konfigurations-Kern besteht aus Datasets im Unity Catalog, Beispiel-SQL-Queries, SQL-Ausdrücken für die Business-Semantik und Textanweisungen zur Terminologie der Organisation. Der Semantik-Layer sitzt oberhalb der Tabellen und nutzt Metadaten, Beispielabfragen und definierte SQL-Ausdrücke. Bei einer Wide Table werden Business-Metriken wie aktive_kunden_l30d oder customer_lifetime_value im Genie Space als SQL-Ausdruck definiert und bleiben aus den Tabellen-Spalten heraus. Die Wide Table liefert die Datenbasis. Der Semantik-Layer definiert, wie daraus Kennzahlen berechnet werden.

Der dbt Semantic Layer folgt derselben Logik mit anderer Technik. Die dbt-Semantic-Layer-Doku bringt den Kern auf den Punkt: doppelte Kodierung entfällt, weil Metriken zentral auf bestehenden Modellen definiert und Joins automatisch aufgelöst werden. MetricFlow ist die Rechen-Engine dahinter, Metriken werden im dbt-Projekt definiert und über die Semantic Layer APIs von BI-Tools, Notebooks und Custom-Anwendungen konsumiert. Die dbt-Doku macht keine Vorgabe zur Modellform darunter: eine Wide Table funktioniert genauso wie ein Star Schema.

Cube ist die Open-Source-Variante mit denselben Prinzipien: eine Semantik-Schicht über der Datenbank, die Metriken zentral definiert und über REST-, GraphQL- und SQL-APIs an BI-Tools und Anwendungen ausliefert. Cube wird oft im „Headless BI“-Kontext genannt und funktioniert auf Delta-Tabellen wie auf klassischen Warehouses.

Alle drei Semantik-Layer können grundsätzlich auf unterschiedlichen Tabellenformen arbeiten. Eine gut modellierte Wide Table macht die Metrikdefinition aber oft einfacher, weil viele Joins bereits materialisiert sind. Bei einem Star Schema mit vielen Joins muss der Semantik-Layer die Joins nachbauen, bei einer OBT sind sie schon materialisiert.

Ein zweiter Effekt kommt durch Natural-Language-Abfragen dazu. LLM-basierte Text-to-SQL-Systeme wie Databricks Genie liefern auf Single-Table-Abfragen deutlich verlässlichere Ergebnisse als auf Multi-Join-Modellen. Eine Wide Table mit Semantik-Layer kann Natural-Language-Abfragen dadurch einfacher machen als ein Modell mit vielen Joins.

Denormalisierung braucht zusätzlichen Speicher. Entscheidend ist aber, wie groß dieser Aufschlag in der Praxis wirklich ist.

In einem Star Schema steht customer_region einmal in der Kundendimension. In einer Wide Table steht dieselbe Information in vielen Millionen Zeilen. Das wirkt zunächst teuer, wird in Parquet aber oft deutlich kompakter gespeichert. Werte mit niedriger Kardinalität, etwa Region, Status oder Kategorie, lassen sich sehr gut komprimieren und werden nicht millionenfach als voller Text abgelegt.

Der Aufschlag kann trotzdem relevant sein. Ein Fivetran-Benchmark auf TPC-DS-Daten zeigt eine denormalisierte Tabelle mit rund 60 GB gegenüber etwa 30 GB im normalisierten Star Schema. Wie groß der Unterschied ausfällt, hängt vor allem davon ab, welche Attribute wiederholt werden. Niedrig-kardinale Werte bleiben meist gut beherrschbar, hoch-kardinale Werte wie IDs, Freitexte, Events oder Sensorwerte treiben den Speicher stärker nach oben.

Deshalb sollte der Speicheraufschlag pro Datenprodukt mit echten Daten geprüft werden. Aus dem Modell allein lässt sich der Effekt nur grob abschätzen.

Delta-Features können den Betrieb breiter Tabellen erleichtern. Liquid Clustering verbessert Pruning entlang wichtiger Filterspalten und kann die Kompression unterstützen. Predictive Optimization kann OPTIMIZE und VACUUM automatisieren und die Tabelle über die Zeit kompakt halten. Wie Liquid Clustering im Detail arbeitet, klären wir im Überblick zu Liquid Clustering.

Zwei Kostenpunkte bleiben wichtig: MERGE-Operationen können teurer werden, wenn Attributänderungen viele Zeilen betreffen. Backfills können aufwendig werden, wenn Spalten umbenannt oder Attribute neu aufgebaut werden müssen. Column Mapping kann solche Änderungen teilweise entschärfen.

Der zweite wichtige Konsument einer Wide Table ist häufig ML. Seit der Unity-Catalog-Integration kann der Databricks Feature Store normale Delta-Tabellen nutzen, sofern sie einen Primary-Key-Constraint haben. Dadurch kann dieselbe Wide Table sowohl BI-Reports als auch Feature Engineering unterstützen.

Eine Tabelle mit customer_id als Primary Key und event_date als Zeitspalte kann zum Beispiel Grundlage für Power BI sein und gleichzeitig Features für Training oder Batch Scoring liefern. BI und ML greifen damit auf dieselbe fachliche Datenbasis zu.

Wichtig ist: Wenn die Tabelle als Feature-Quelle dienen soll, müssen Primary Key und Zeitlogik von Anfang an mitgedacht werden. Für Zeitreihen-Features braucht es eine saubere Zeitspalte, damit Modelle beim Training den Feature-Stand zum damaligen Ereigniszeitpunkt sehen und keine späteren Informationen nutzen.

Zwei Grenzen bleiben: Für Online-Feature-Serving braucht es weiterhin eine Veröffentlichung in einen Online Store. Und sehr breite Feature-Tabellen können bei häufigen MERGE-Operationen teuer werden. Für viele Fälle ist deshalb ein geplanter Batch-Job über Workflows oder Lakeflow sinnvoller als laufende Streaming-Merges.

Wide Tables sind kein Universalmodell. Sie können Konsum vereinfachen, verschieben aber Komplexität in Governance, Semantik und Change Management. Star Schema oder Data Vault bleiben in vielen Fällen die bessere Grundlage.

Wie Data Vault auf Delta aussieht, zeigen wir im Überblick zu Data Vault auf Delta.