Data Lakehouse: Wann es Data Warehouse und Data Lake ablöst
Die Kernaussagen auf einen Blick.
- Ein Data Lakehouse verbindet vier Bausteine: Objektspeicher, offenes Tabellenformat, gemeinsamen Katalog und entkoppelte Engines.
- Es reduziert das Zwei-System-Problem zwischen Data Warehouse und Data Lake, weil Analytics, ML und Streaming auf derselben Datenbasis arbeiten.
- Vor der Plattformwahl steht die Data Strategy als zentrales Fundament: aus ihr folgen Format, Katalog, Berechtigungen und Engines.
- Mein Vorschlag: Klärt zuerst die Architektur und die Offenheit der vier Bausteine, danach entscheidet ihr über Plattform und Anbieter.
Inhaltsverzeichnis
Warum die Zwei-System-Architektur aus Data Warehouse und Data Lake nicht mehr trägt
Ein Team baut das dritte Vertriebsdashboard, weil das Data Warehouse die CDC-Daten nicht schnell genug in ein sauberes Reporting-Modell bekommt. Ein anderes Team trainiert ein Forecast-Modell auf denselben Daten, aber auf der Kopie im Data Lake, die zwei Tage älter ist. Am Freitagnachmittag stellt jemand die Zahl infrage. Niemand kann schnell erklären, welche Quelle gilt.
Dieses Bild wiederholt sich, sobald Unternehmen versuchen, BI, ML und Streaming auf zwei getrennten Systemen parallel zu betreiben. Das übliche Muster: Warehouse für Reporting, Lake für Data Science, dazwischen eine ETL- oder CDC-Strecke mit hoher Wartungslast.
Daraus entstehen die eigentlichen Architekturfragen:
Wer zahlt die Storage-Kosten für die Kopie zwischen Lake und Warehouse? Welche Quelle ist offiziell, wenn Finance und Data Science unterschiedliche Zahlen sehen? Welches Team garantiert, dass die Konform-Regeln im ETL nicht still von der Data-Contract-Version abweichen? Was passiert, wenn Storage und Compute eng an einen Anbieter gekoppelt sind und die Kosten steigen?
Das ist keine BI-Frage. Es ist eine Architektur-Frage.
Was ist ein Data Lakehouse?
Ein Data Lakehouse ist eine Datenplattform-Architektur, die die Analysefähigkeiten eines Data Warehouse mit der günstigen und flexiblen Speicherung eines Data Lake verbindet. Konkret: Daten liegen als offene Dateien im Objektspeicher (z. B. AWS S3, Azure ADLS, Google Cloud Storage), ein Tabellenformat wie Delta Lake, Iceberg oder Hudi macht daraus transaktionale Tabellen mit ACID, Schema-Evolution und Time Travel, ein gemeinsamer Katalog regelt Berechtigungen und Herkunft, mehrere Engines lesen und schreiben parallel.
Der Begriff stammt aus einem Paper von Armbrust, Ghodsi und Zaharia (CIDR 2021), das die Kategorie erstmals formal beschrieb. Databricks hat den Begriff stark geprägt und die Kategorie früh vermarktet.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was ist der Unterschied zwischen Data Lake und Data Warehouse?
Data Warehouse und Data Lake speichern Analysedaten unterschiedlich und sind für unterschiedliche Anforderungen gebaut.
Ein Data Warehouse ist auf strukturierte Daten, SQL-Analysen und Reporting ausgelegt. Die Daten werden beim Laden in ein festes Modell gebracht. Das sorgt für klare Kennzahlen, stabile Reports und einheitliche Datenstrukturen. Dafür ist das Warehouse weniger flexibel, wenn viele Rohdaten, neue Datenformate oder ML-Workloads dazukommen.
Ein klassischer Data Lake speichert Rohdaten flexibel im Objektspeicher, zum Beispiel als Dateien aus Systemen, Events, Logs oder externen Quellen. Das ist günstig und skalierbar, aber ohne zusätzliche Schichten oft schwer zu steuern. Es fehlen klare Modelle, Governance, zuverlässige Transaktionen und eine eindeutige Antwort darauf, welche Daten wirklich offiziell genutzt werden sollen.
Die einfache Abgrenzung: Das Data Warehouse liefert kontrollierte Kennzahlen für Reporting. Der Data Lake sammelt große und vielfältige Rohdaten für Analyse, ML und neue Use Cases. Werden beide getrennt betrieben, entstehen oft zusätzliche ETL- und CDC-Strecken zwischen den Systemen. Genau dort beginnt die Frage, welche Plattform am Ende die verbindliche Datenbasis sein soll.
Wie löst ein Data Lakehouse den Konflikt zwischen Warehouse und Lake?
Das Lakehouse bringt zentrale Warehouse-Fähigkeiten (ACID, Schema-Erzwingung, konforme Modelle) auf die Storage-Ebene des Data Lake. Rohdaten landen flexibel in Bronze. Ab Silver werden Struktur, Qualität und Schema verbindlicher, mit Schema-Evolution: Felder lassen sich ergänzen, ohne die Downstream-Logik zu brechen.
Mittlerweile setzen mehrere Anbieter die Architektur um: Databricks dokumentiert Lakehouse-Referenzbeispiele als einheitliche Plattform für Data Engineering, Data Warehousing, Streaming und AI, Snowflake bietet Iceberg Tables als Lakehouse-Modus an, AWS positioniert S3 Tables und SageMaker Lakehouse als offenen Katalog-Zugang auf S3, Microsoft Fabric und SAP Business Data Cloud folgen dem gleichen Muster.
Der wichtigste Effekt ist die Entkopplung von Storage und Compute: Derselbe Datensatz trägt Reporting, ML und Streaming, ohne dass jede Workload eine eigene Kopie in einer proprietären Storage-Engine verlangt. Storage skaliert nach TB, Compute nach Query oder Job, und beides skaliert unabhängig.
Das Data Lakehouse verlangt mehr als einen SQL-Layer über einem Data Lake und mehr als einen Objektspeicher hinter einem Warehouse. Wenn ein Anbieter Lakehouse sagt, Format und Katalog aber stark an die eigene Plattform bindet, bleibt der Wechselspielraum für Engine und Governance eng.
Wie sich die drei Architekturen im direkten Vergleich unterscheiden, klären wir im Head-to-Head zu Data Warehouse vs. Data Lake vs. Lakehouse.
Welche Bausteine braucht eine Lakehouse-Architektur?
Ein Data Lakehouse besteht aus vier Schichten: Objektspeicher, Tabellenformat, Katalog und Compute-Engine. Diese Trennung ist wichtig, weil Daten dadurch nicht fest an eine einzelne Plattform gebunden sind.
Vier Schichten, vier Designentscheidungen.
Storage, Table Format, Compute und Governance bauen aufeinander auf. Fehler in den unteren Schichten wirken sich auf alles Darüberliegende aus.
Der Objektspeicher ist die unterste Schicht. Hier liegen die Daten als Dateien, zum Beispiel in S3, ADLS oder GCS. Der Speicher ist günstig, skalierbar und unabhängig von der Engine, die später darauf arbeitet.
Das Tabellenformat macht aus diesen Dateien verlässliche Tabellen. Formate wie Delta Lake, Apache Iceberg oder Apache Hudi bringen Funktionen wie ACID-Transaktionen, Schema-Evolution, Time Travel und Metadaten für bessere Abfragen mit. Ohne diese Schicht bleibt der Data Lake vor allem eine Dateiablage.
Der Katalog steuert Governance und Orientierung. Hier werden Berechtigungen, Lineage, Suche, Ownership und teilweise Data Contracts verwaltet. Beispiele sind Unity Catalog, Apache Polaris, Iceberg REST Catalog oder AWS Glue.
Die Engines führen Abfragen, Jobs, Streaming- oder ML-Workloads aus. Dazu gehören zum Beispiel Databricks SQL und Photon, Trino, DuckDB, Dremio, Fabric Spark oder Snowflake Compute. Der Vorteil im Lakehouse ist, dass mehrere Engines auf denselben Daten arbeiten können, ohne sie vorher in ein anderes System kopieren zu müssen.
| Schicht | Aufgabe | Beispiele |
|---|---|---|
| Storage | Dateien speichern | S3, ADLS, GCS |
| Tabellenformat | Dateien als Tabellen nutzbar machen | Delta Lake, Iceberg, Hudi |
| Katalog | Governance, Berechtigungen, Lineage | Unity Catalog, Polaris, Glue |
| Engines | Daten verarbeiten und abfragen | Databricks SQL, Photon, Trino, DuckDB, Fabric Spark |
Die einfache Faustregel: Ein Lakehouse ist dann wirklich offen, wenn Daten, Tabellenformat, Katalog und Compute nicht vollständig an einen einzigen Anbieter gebunden sind.
Delta Lake, Apache Iceberg oder Hudi: welches Tabellenformat passt?
Die Tabellenformat-Schicht macht aus Dateien verlässliche Tabellen. Hier entstehen Funktionen wie ACID-Transaktionen, Time Travel, Schema-Evolution und Metadaten für schnellere Abfragen.
Im Markt sind vor allem drei Formate relevant: Delta Lake, Apache Iceberg und Apache Hudi. Alle drei arbeiten mit offenen Parquet-Dateien und zusätzlichen Metadaten. Sie lösen also ein ähnliches Grundproblem, unterscheiden sich aber in Architektur, Ökosystem und typischen Einsatzbereichen.
Delta Lake ist besonders stark im Databricks-Umfeld verankert. Es passt gut, wenn Databricks, Unity Catalog und Delta-native Workloads im Mittelpunkt stehen. Über UniForm können Delta-Tabellen zusätzlich für Iceberg-kompatible Engines lesbar gemacht werden.
Apache Iceberg hat sich stark als Cross-Engine-Format etabliert. Es wird von vielen Plattformen unterstützt, darunter Snowflake, AWS, Google, Trino und weitere Engines. Iceberg ist deshalb besonders relevant, wenn mehrere Systeme direkt auf denselben Tabellen arbeiten sollen.
Apache Hudi ist weniger sichtbar im klassischen BI- und Lakehouse-Markt, bleibt aber wichtig für CDC-, Streaming- und Upsert-lastige Szenarien.
Für die Entscheidung ist das Zusammenspiel aus Format, Katalog und Engine wichtiger als ein einzelnes Feature. In Databricks-zentrierten Landschaften mit Unity Catalog fällt die Wahl häufig auf Delta Lake mit Iceberg-Kompatibilität über UniForm. Für eine breite Cross-Engine-Architektur führt der Weg über Iceberg und den passenden Katalog.
Welche Format-Wahl konkret trägt, klären wir in den Detailartikeln zu Delta Lake, Apache Iceberg und dem UniForm-Ansatz für Interoperabilität.
Warum der Katalog das Fundament des Lakehouse ist
Der Katalog ist eine der wichtigsten Schichten im Lakehouse. Ohne ihn bleibt die Plattform eine Sammlung von Dateien und technischen Metadaten. Erst der Katalog macht daraus eine steuerbare Datenplattform mit Berechtigungen, Lineage, Suche, Audit und Data Sharing.
In einem klassischen Data Lake werden Zugriffe oft über Storage-Rechte, Bucket Policies oder ACLs geregelt. Das reicht für Rohdaten, wird aber schwierig, sobald kuratierte Tabellen, Reporting-Modelle oder Row-Level-Security ins Spiel kommen. Ein klassisches Data Warehouse löst Berechtigungen innerhalb der Warehouse-Engine. Das funktioniert gut, solange diese Engine der zentrale Zugriffspunkt bleibt.
Im Lakehouse greifen aber mehrere Engines auf denselben Speicher zu. Genau hier wird der Katalog entscheidend. Er stellt Tabellen, Berechtigungen und Metadaten zentral bereit, sodass verschiedene Workloads dieselbe Datenbasis kontrolliert nutzen können. Beispiele sind Unity Catalog im Databricks-Umfeld, Apache Polaris und der Iceberg REST Catalog für Iceberg-Architekturen oder Snowflake Horizon im Snowflake-Ökosystem.
Die Governance-Folge ist klar: Ohne Katalog entstehen schnell dieselben Probleme wie im alten Data Lake: Tabellen ohne Owner, doppelte Datenbestände, unklare Herkunft und schwer prüfbare Zugriffe. Mit einem sauber aufgebauten Katalog werden Daten auffindbar, berechtigbar und nachvollziehbar. Wie sich Governance auf Unity Catalog aufbaut, klären wir im Überblick zu Unity Catalog.
Bronze, Silver, Gold: wie funktioniert die Medaillon-Architektur im Lakehouse?
Auf dem Lakehouse hat sich ein Layer-Muster etabliert, das aus dem klassischen Data-Warehousing kommt: Roh-, Konform- und Konsum-Schicht. Databricks nennt es Medaillon-Architektur, in der offiziellen Dokumentation als "Bronze, Silver, Gold" formalisiert. Bronze hält Rohdaten möglichst unverändert und meist nur-anfügend (append-only), Silver enthält bereinigte und konforme Tabellen, Gold liefert die aggregierten Datenprodukte für Reporting, ML-Features und Downstream-Konsum.
Bronze → Silver → Gold: Datenqualität in drei Stufen.
Drei Schichten mit steigender Qualität und Aggregation. Bronze hält Rohdaten append-only; Silver validiert und standardisiert; Gold liefert business-ready Aggregate mit SLAs.
Das Muster ist heute eine gängige Konvention für Lakehouse-Umsetzungen. Auch Microsoft Fabric dokumentiert die drei Layer mit derselben Logik, und die Community rund um Iceberg und Hudi arbeitet nach demselben Schema.
Der entscheidende Punkt: Die Layer sind eine Modellierungs-Konvention. Alle drei liegen auf demselben Storage im selben Tabellenformat und werden von denselben Engines gelesen. Was sich zwischen den Layern ändert, sind Aktualisierungs-Frequenz, Modellierungs-Tiefe und Zugriff. Konsumierende Anwendungen greifen meist auf Gold zu, Data Science darf auch auf Silver, Data Engineering pflegt Bronze und Silver.
Wie sich Bronze, Silver und Gold sauber modellieren lassen, führen wir im Überblick zu Medaillon-Architektur aus.
Was bedeutet Open Lakehouse wirklich?
Open Lakehouse wird oft unscharf verwendet. Nicht jede Plattform ist wirklich offen, nur weil sie auf offenen Dateien oder einem bekannten Tabellenformat basiert. Entscheidend ist, wie frei Format, Katalog und Berechtigungen tatsächlich genutzt werden können.
Drei Fragen helfen bei der Einordnung:
- Können mehrere Engines das Tabellenformat lesen und schreiben?
- Lässt sich der Katalog über einen offenen Standard anbinden oder austauschen?
- Bleibt das Berechtigungsmodell nutzbar, wenn eine andere Engine dazukommt?
Wenn alle drei Punkte erfüllt sind, bleibt die Architektur wirklich offen. Wenn Format, Katalog oder Berechtigungen nur innerhalb eines Anbieter-Ökosystems funktionieren, ist die Offenheit begrenzt.
Ein Open Lakehouse ist deshalb auf allen Ebenen offen: Storage, Tabellenformat, Katalog und Governance. Was Open Lakehouse konkret bedeutet, ordnen wir im Überblick zu Open Lakehouse ein.
Databricks, Snowflake, Fabric oder SAP BDC: welche Plattform setzt Lakehouse wie um?
Vier Plattformen prägen die Lakehouse-Diskussion. Sie setzen die Architektur unterschiedlich um:
Databricks hat die Kategorie stark geprägt und arbeitet nativ mit Delta Lake, ergänzt um Iceberg-Kompatibilität über UniForm. Unity Catalog bildet die Governance-Schicht, Photon die performante SQL-Engine. Die Plattform ist stark auf Data Engineering, Analytics, BI und ML in einem gemeinsamen Lakehouse-Modell ausgerichtet.
Snowflake kommt historisch aus dem Data-Warehouse-Modell und öffnet sich zunehmend in Richtung Lakehouse, vor allem über Iceberg Tables und Apache Polaris als offenen Katalog. Das zeigt, wie stark Warehouse- und Lakehouse-Architekturen inzwischen zusammenwachsen.
Microsoft Fabric setzt auf OneLake als zentrale Storage-Schicht und Delta Lake als Tabellenformat. Governance und Integration liegen stark im Fabric-Ökosystem. Das macht den Einstieg für Microsoft-nahe Organisationen attraktiv, begrenzt aber den Wechselspielraum auf der Katalog- und Plattformebene.
SAP Business Data Cloud baut auf Databricks als Rechenkern und setzt auf Delta plus Iceberg. Für SAP-lastige Landschaften kann das ein pragmatischer Zugang zur Lakehouse-Kategorie sein, weil bestehende SAP-Datenwelten enger mit Analytics- und AI-Workloads verbunden werden.
Die detaillierten Trade-offs zwischen den vier Plattformen, etwa Kosten, Governance, AI/ML-Reifegrad und Multi-Cloud-Support, klären wir im Datenplattform-Vergleich.
Wann lohnt sich ein Data Lakehouse?
Ein Data Lakehouse lohnt sich besonders, wenn BI, ML, Streaming und Data Sharing auf dieselben Daten zugreifen sollen und die Kopie zwischen Systemen weh tut. Vier Muster wiederholen sich in den Umbauten, die wir sehen.
Analytics plus ML auf einer Kopie. Ein typisches Muster: Reporting läuft auf dem konformen Silver-Layer, ML-Feature-Pipelines gehen ebenfalls auf Silver und Gold, ohne eine zweite Datenkopie nur für ML zu erzeugen. Die BI-Zahl im Board und das ML-Feature stammen aus derselben Tabelle. Die klassische Warehouse-Lake-Trennung, in der Data Science eine zwei Tage alte Kopie hatte, entfällt.
Streaming-Ingestion in dieselbe Tabelle wie Batch. CDC-Streams aus operativen Systemen (Postgres, Kafka) landen als Append im Bronze-Layer und werden inkrementell in Silver bereinigt. Reporting liest denselben Silver-Layer wie das ML-Training. Das ist der operative Fall, in dem die Zwei-System-Strecke zwischen Warehouse und Lake historisch das teuerste Wartungs-Objekt war.
IoT- und Sensor-Landschaften mit gemischter Modellierung. In Fertigung, Energie und Logistik liegen strukturierte ERP-Daten neben unstrukturierten Sensor-, Telemetrie- und Bild-Daten. Predictive-Maintenance-Modelle brauchen beides gemeinsam. Das Lakehouse hält sie im selben Katalog und derselben Storage-Ebene, damit die Modell-Trainings auf die konforme Sensor-Historie zugreifen können, während das ERP-Reporting parallel läuft.
Regulatorisches Reporting mit heterogenen Quellen. ESG-, DSGVO- und EU-AI-Act-Berichte ziehen aus Finanz-, Lieferanten-, HR- und IoT-Systemen zusammen. Die Datenherkunft muss auditierbar sein, die Berichts-Aggregate müssen reproduzierbar bleiben. Katalog und Time Travel liefern beides. Ohne die Katalog-Schicht bleibt jede Wirtschaftsprüfer-Frage nach dem "Stand vom 31.12." schwer beantwortbar.
Der gemeinsame Nenner dieser Fälle ist die Trennung von Storage, Format, Katalog und Engine. Genau die Trennung, die in kleinen und homogenen Landschaften Überengineering bleibt und in großen, gemischten Landschaften die Zwei-System-Rechnung ablöst.
Grenzen: Wann ist ein Data Lakehouse nicht sinnvoll?
Das Lakehouse ist nicht für jeden Workload die richtige Architektur. Es trägt breit für Analytics, ML und Streaming, hat aber echte Grenzen.
Kein OLTP
Das Lakehouse ist nicht die richtige Ebene für transaktionale Workloads mit hoher Update-Frequenz und Punktzugriffen. Für OLTP-Systeme wie ERP, Order-Management oder Customer-Portale bleiben Postgres, SQL Server oder eine spezialisierte OLTP-Datenbank die richtige Wahl.
Keine Sub-Millisekunden-Latenz
Photon und Databricks SQL sind sehr schnell, aber für Fraud-Scoring in Millisekunden oder Real-Time-Personalisierung im Web-Frontend sind spezialisierte Engines wie Druid, Pinot oder ClickHouse näher am Ziel.
Kleine, extrem hochfrequente Punkt-Lookups
Wenn eine Anwendung tausende Punkt-Lookups pro Sekunde auf spezifische Schlüssel macht, ist das kein Lakehouse-Workload. Key-Value-Store oder relationale Datenbank bleiben schneller und günstiger.
Kleinteilige Landschaften ohne Volumen
In sehr kleinen Landschaften mit wenigen Datenquellen, wenig Volumen und einer einzigen BI-Anwendung kann ein Lakehouse überdimensioniert sein. Die Kategorie lohnt sich ab dem Punkt, an dem die Zwei-System-Frage überhaupt entsteht.
Governance-Reife als harte Voraussetzung
Ohne funktionierenden Katalog, klare Ownership und Data Contracts wird das Lakehouse zum modernen Data Lake mit denselben Wunden. Der Umbau lohnt sich erst, wenn die Governance mitläuft.
Fehlende Data Strategy
Ohne eine klare Data Strategy ist ein Lakehouse-Aufbau verfrüht. Zielbild, Use-Case-Priorisierung, Ownership und Governance-Grundsätze müssen stehen, bevor die Plattform-Diskussion Sinn ergibt.
Wie das Lakehouse operative Real-Time-Analytik ergänzt oder abgibt, klären wir im Überblick zu Lakehouse-RT auf Databricks. Wie Lakebase den OLTP-Anschluss löst, klären wir im Überblick zu Lakebase auf Databricks.
Fazit
Das Data Lakehouse löst die Zwei-System-Architektur aus Data Warehouse und Data Lake ab, sobald Analytics, ML und Streaming eine gemeinsame Datenbasis brauchen.
Das Data Lakehouse ist die Antwort auf die Zwei-System-Architektur aus Data Warehouse und Data Lake, in der BI und ML auf getrennten Plattformen mit CDC-Strecke dazwischen liefen. Aus vier Bausteinen (Objektspeicher, offenes Tabellenformat, gemeinsamer Katalog, entkoppelte Engines) entsteht eine Plattform, auf der Analytics, ML und Streaming eine gemeinsame Datenkopie lesen und der Wechselspielraum bei Engine und Anbieter erhalten bleibt.
Die Kategorie hat sich etabliert: Databricks als Prägungs-Erfinder, Snowflake als Kategorien-Konvergenz über Iceberg, Microsoft Fabric und SAP Business Data Cloud als weitere Umsetzungen. Der eigentliche Wettbewerb liegt heute in Katalog, Engine, Governance und Kostenmodell. Die Kategorie selbst ist Konsens. Die bessere Frage lautet heute, welche Lakehouse-Architektur zu den eigenen Workloads passt.
Vier Faktoren entscheiden über den erfolgreichen Einsatz: eine tragende Data Strategy (Zielbild, Use-Case-Priorisierung, Ownership), die Offenheit der vier Bausteine (Format offen, Katalog offen, Berechtigungen portabel), die Reife der Governance (Katalog, Data Contracts, Lineage stehen, bevor die erste produktive Analyse läuft) und ein klarer Blick auf die Grenzen (OLTP, Sub-Millisekunden-Latenz und kleine Landschaften bleiben Nachbararchitekturen).
Mein Vorschlag: Für Landschaften, die aus einem klassischen DWH herauswachsen oder aus einem Data Lake mit BI-Anschluss die Kategorie sortieren wollen, ist das Lakehouse heute die tragende Architektur. Beginnt mit der Data Strategy, klärt dann, welcher der vier Bausteine bei welchem Anbieter wie offen bleibt, und wählt danach die Plattform. Wer zuerst den Anbieter wählt und erst danach die Architektur klärt, verschiebt die Lock-in-Frage nur auf die nächste Plattform.
Beginnt mit der Data Strategy, klärt dann, welcher der vier Bausteine bei welchem Anbieter wie offen bleibt, und wählt danach die Plattform.
Löst ein Lakehouse eure DWH- oder Data-Lake-Architektur wirklich ab?
Ob ein Lakehouse eure bestehende Architektur wirklich vereinfacht oder nur eine zusätzliche Plattformschicht erzeugt, lässt sich in einem ersten Architecture Review klären.
- welche Workloads echte Kandidaten für eine Lakehouse-Architektur sind
- welche Governance-, Kosten- und Betriebsrisiken vor dem nächsten Umbau geprüft werden sollten
- welcher Vorgehensweg zur Ablösung oder Ergänzung eurer bestehenden DWH- oder Lake-Architektur passt
FAQ
Ein Data Lakehouse verbindet die Analysefähigkeiten eines Data Warehouse mit der flexiblen und günstigen Speicherung eines Data Lake. Sie besteht aus vier Bausteinen: Objektspeicher, offenes Tabellenformat mit ACID (Delta, Iceberg, Hudi), gemeinsamer Katalog für Governance und entkoppelte Engines für Analytics, ML und Streaming. Das Data Lakehouse beschreibt eine offene Architektur, die mehrere Anbieter umsetzen.
