Data Lakehouse: Definition, Architektur, Abgrenzung

Ein Data Lakehouse ist ein Bauplan für Datenplattformen, der zwei bisher getrennte Welten in einem Speicher zusammenführt: den günstigen, offenen Datei-Speicher eines Data Lake (Ablage großer Rohdaten-Mengen) und die verlässlichen Tabellen-Eigenschaften eines Data Warehouse (Analyse-Datenbank mit festem Schema und geordneten Schreib-Vorgängen). Technische Grundlage sind offene Tabellenformate wie Delta Lake, Apache Iceberg oder Apache Hudi. Sie legen sich als Schicht über die Dateien und liefern die Kern-Eigenschaften eines Warehouse für Analyse, Business Intelligence (BI) und Machine Learning (ML) auf einer gemeinsamen Datenbasis: geordnete Schreib-Vorgänge (ACID, also Atomicity, Consistency, Isolation, Durability), Versionierung, Schema-Kontrolle und Metadaten.

Was ist ein Data Lakehouse?

Ein Data Lakehouse ist eine Datenplattform-Architektur, in der Daten als offene Dateien in einem Objekt-Speicher (dem günstigen Cloud-Datei-Speicher wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage) liegen und über eine zusätzliche Tabellen-Schicht verlässlich zugreifbar werden. Die günstige Speicherung und die Format-Offenheit des Data Lake bleiben erhalten; darüber legt sich ein Tabellenformat, das mehrere Warehouse-Eigenschaften ergänzt: geordnete Schreib-Vorgänge (ACID-Transaktionen, sodass keine halben Änderungen sichtbar werden), Schema-Kontrolle (verhindert, dass Spalten stillschweigend zerbrechen), Zeitreisen (frühere Stände der Tabelle bleiben abfragbar) sowie Aktualisierungen und Löschungen einzelner Zeilen. Ein Katalog wie Unity Catalog, AWS Glue, Apache Polaris oder Nessie (also ein zentrales Verzeichnis über alle Tabellen) verwaltet Berechtigungen und den Herkunfts-Nachweis der Daten plattform-übergreifend.

Der Begriff wurde 2020 durch Michael Armbrust, Ali Ghodsi, Reynold Xin und Matei Zaharia (Databricks/UC Berkeley) in dem Paper „Lakehouse: A New Generation of Open Platforms That Unify Data Warehousing and Advanced Analytics" (CIDR 2021) geprägt. Ausgangspunkt war die Beobachtung, dass viele Organisationen Data Lake und Data Warehouse parallel betreiben, Daten zwischen beiden Systemen kopieren und dabei Konsistenz-, Kosten- und Governance-Probleme in Kauf nehmen. Das Lakehouse-Muster löst die Zwei-System-Architektur auf, indem es die Warehouse-Eigenschaften direkt auf die Lake-Speicherung setzt.

Compute und Speicher sind im Lakehouse entkoppelt. Verschiedene Engines wie Apache Spark, Trino, Presto, DuckDB, Photon oder auch Snowflake über External Tables greifen auf dieselben Dateien zu. Diese Engine-Vielfalt und die Verwendung offener Dateiformate (Parquet, ORC) und offener Tabellen-Spezifikationen unterscheiden das Muster von proprietären Cloud-Warehouses, in denen Daten in einem geschlossenen internen Speicherformat liegen. Für BI- und ML-Workloads ergibt sich damit eine einzige Datenbasis, während die Wahl der Query-Engine offen bleibt.

Abgrenzung zu Data Warehouse, Data Lake und Data Intelligence Platform

Der Begriff Data Lakehouse wird in Praxis-Diskussionen häufig mit verwandten Konzepten vermischt, die entweder eine andere Speicher-Philosophie beschreiben oder eine konkrete Produkt-Ausprägung meinen.

Begriff	Achse	Kernunterschied
Data Warehouse	Speicher-Philosophie	Relationale Analyse-Datenbank mit festem Schema (Schema-on-Write) auf meist proprietärem Speicherformat. Das Lakehouse öffnet den Speicher (Objektspeicher + offene Dateiformate) und ergänzt ihn um Warehouse-Eigenschaften.
Data Lake	Betriebsreife	Roher Datenspeicher ohne Transaktionen und ohne Schema-Garantien. Das Lakehouse ergänzt den Lake um eine transaktionale Tabellen-Schicht und einen Katalog, ohne den Speicher zu ersetzen.
Databricks Data Intelligence Platform	Produkt vs. Muster	Kommerzielle Umsetzung eines Lakehouse-Musters mit Delta Lake, Unity Catalog, Photon und AI-/BI-Layer. Das Lakehouse-Muster ist herstellerneutral, die Data Intelligence Platform eine konkrete Implementierung.
Open Lakehouse	Governance-Aussage	Betonungs-Variante mit expliziter Wahl offener Tabellenformate (Apache Iceberg, Delta OSS, Apache Hudi) und offener Kataloge (Polaris, Nessie, Unity Catalog OSS) zur Vermeidung von Vendor-Lock-In. Kein zweites Architekturmuster.
Modern Data Warehouse	Terminologie-Nachbar	Aufgewertetes Cloud-Warehouse mit ELT-Pipelines und semantischer Schicht bei weiterhin geschlossenem Speicherformat. Der Speicher bleibt in der proprietären Warehouse-Engine gebunden, während das Lakehouse auf offenen Objekt-Speicher setzt.

Die zentrale Abgrenzung verläuft zwischen Data Lake und Data Lakehouse. Der Data Lake ist die Storage-Basis: Objekt-Speicher plus offene Dateiformate. Das Lakehouse ist die logische Schicht darüber: dieselben Parquet-Dateien, ergänzt um Delta-, Iceberg- oder Hudi-Metadaten und einen Katalog. Beide Muster können auf demselben S3-Bucket koexistieren; der Übergang vom Lake zum Lakehouse ist damit eine Format-Migration, keine Speicher-Migration.

Die zweite häufige Verwechslung betrifft das Muster gegenüber einer konkreten Plattform. Databricks, Microsoft Fabric mit OneLake, Snowflake mit Iceberg Tables, AWS mit S3 Tables und Google mit BigLake bauen alle Lakehouse-Architekturen mit unterschiedlichen Standard-Tabellenformaten, Katalogen und Engine-Präferenzen. Der Begriff Lakehouse beschreibt damit eine Architekturklasse, unter der sich mehrere Produkt-Ausprägungen einordnen lassen.

Beispiel: Lakehouse in einer produzierenden Umgebung

Ein produzierendes Unternehmen speichert Sensor-Daten aus MES und SCADA sowie Auftragsdaten aus dem ERP als Parquet-Dateien im Objekt-Speicher. Über Delta Lake als Tabellenformat entstehen darüber transaktionale Tabellen mit ACID-Garantien; Unity Catalog verwaltet Berechtigungen, Lineage und Datenqualitäts-Signale plattform-übergreifend. Spark-Jobs verarbeiten eine Bronze-Zone mit Rohdaten in bereinigte Silver- und aggregierte Gold-Tabellen. BI-Werkzeuge greifen über einen SQL-Warehouse auf die Gold-Ebene zu; ein ML-Team liest für Anomalie-Erkennung direkt aus Silver.

Dieselben Delta-Tabellen sind über UniForm zusätzlich als Iceberg-Tabellen lesbar, ohne die Daten zu kopieren. Externe Engines wie Trino oder Snowflake können damit denselben Datenbestand über die Iceberg-Spezifikation abfragen. Ohne die Lakehouse-Schicht würde die Umgebung entweder mit einem separaten Data-Warehouse-Speicher betrieben (mit einer ETL-Pipeline zwischen Lake und Warehouse) oder als reiner Data Lake ohne Transaktionalität und ohne verlässliches Schema-Management.

Diese Architektur ist die typische heutige Lakehouse-Umsetzung. Sie kombiniert Objekt-Speicher als Fundament, offene Dateiformate für die Persistenz, ein offenes Tabellenformat für Transaktionen und Metadaten, verteilte Engines für Verarbeitung und einen Katalog für Governance. Wird der Katalog auf einen offenen Katalog wie Apache Polaris umgestellt und werden die Tabellen direkt in Iceberg statt Delta Lake gepflegt, spricht man von einer Open-Lakehouse-Umsetzung; die grundlegende Architektur bleibt dieselbe.