Was ist ein Data Lakehouse?

Ein Data Lakehouse ist eine Datenarchitektur, die den günstigen, beliebig skalierbaren Speicher eines Data Lake mit der strukturierten Datenverwaltung, der Abfrageleistung und der Governance verbindet, die man sonst vom Data Warehouse kennt. Bekannt gemacht hat den Begriff Databricks mit einem Papier von 2021; seither ist er zum Rahmen für große Plattformen geworden, von Databricks selbst über Installationen auf Apache Iceberg bis zu Delta Lake.

Das Lakehouse ist als Antwort auf ein strukturelles Problem entstanden: Organisationen brauchten beides, die Größe und Beweglichkeit eines Data Lake für Rohdaten, unstrukturierte Daten und Machine Learning, und zugleich die Verlässlichkeit und Geschwindigkeit eines Data Warehouse für Analyse, Business Intelligence (BI) und geschäftskritische Berichte. Beides parallel zu betreiben und synchron zu halten kostete Geld, Aufwand und Konsistenz. Das Lakehouse führt beides in einer Architektur zusammen.

Das Problem aus Lake und Warehouse

Um das Lakehouse zu verstehen, hilft ein Blick darauf, was es ersetzt hat, genauer: was es zusammengeführt hat.

Data Warehouse: schnell und geregelt, aber eingeschränkt beweglich

Klassische Data Warehouses (Teradata, IBM Netezza, später ihre Cloud-Entsprechungen) boten hohe Abfrageleistung, ACID-Transaktionen, durchgesetzte Schemata und gut verstandene Governance-Modelle. Sie waren jedoch teuer im großen Maßstab, verlangten strukturierte Daten, kamen mit unstrukturierten und halbstrukturierten Daten schlecht zurecht und unterstützten Machine Learning kaum. Jedes gespeicherte Byte kostete Geld, also musste sorgfältig kuratiert werden, bevor Daten überhaupt im Warehouse landeten.

Data Lake: groß und beweglich, aber schwer zu regeln

Data Lakes (zunächst Hadoop HDFS, dann Cloud-Objektspeicher wie S3, GCS, ADLS) boten billigen, skalierbaren Speicher für jedes Format. Rohdaten, Logs, Bilder, JSON, Parquet, alles konnte im Lake landen. Nur hatten Data Lakes ein Governance-Problem: ohne durchgesetztes Schema, ohne Transaktionen und ohne Zugriffskontrolle auf einzelne Dateien wurden sie zu „Datensümpfen“, groß, billig und für verlässliche Analyse kaum zu gebrauchen. Die Abfragen waren langsam, die Datenqualität unberechenbar, die Lineage undurchsichtig.

Das Zwei-Ebenen-Problem

Viele Organisationen betrieben beides: einen Data Lake für Rohdaten, ML-Daten und unstrukturierte Inhalte und ein Data Warehouse für Analyse und BI. Daraus entstand das Zwei-Ebenen-Problem: ETL-Pipelines schoben Daten vom Lake ins Warehouse und erzeugten dabei Verzögerungen, Abweichungen und laufenden Betriebsaufwand. Dieselben Daten lagen an zwei Orten, womöglich unterschiedlich aktuell, gepflegt von verschiedenen Teams mit verschiedenen Governance-Praktiken.

Die Architektur des Lakehouse

Das Lakehouse löst das Zwei-Ebenen-Problem mit drei Bausteinen, die zusammenwirken:

1. Offene Dateiformate auf Cloud-Objektspeicher: Die Daten liegen als Parquet- oder ORC-Dateien auf S3, GCS oder ADLS. Das ist günstig, skalierbar und für jede Compute-Engine lesbar, ob SQL-Engine, Spark, Python oder R.
2. Metadatenschicht als offenes Tabellenformat: Delta Lake, Apache Iceberg oder Apache Hudi legen ein Transaktionsprotokoll über die Dateischicht. Es ermöglicht ACID-Transaktionen (gleichzeitiges Lesen und Schreiben ohne beschädigte Daten), Time Travel (die Tabelle so abfragen, wie sie vor 30 Tagen aussah), Schema-Evolution (Spalten sicher ergänzen oder ändern) und effizientes Pruning über Metadaten.
3. Schnelle Abfrage-Engines: SQL-Engines (Trino, Spark SQL, DuckDB, Snowflake auf Iceberg) lesen die Metadatenschicht und führen Abfragen aus, ohne alle Dateien zu durchsuchen. Caching und Data Skipping bringen die Geschwindigkeit eines Warehouse auf die Dateischicht.

Was ein Lakehouse können muss

ACID-Transaktionen

Die Metadatenschicht verfolgt jede Änderung atomar. Ein Schreibvorgang gelingt vollständig oder wird zurückgerollt, es gibt keine halben Schreibvorgänge, die Tabellen in einem widersprüchlichen Zustand hinterlassen. Das ist die Grundlage dafür, dass Analyse und Data Engineering gleichzeitig auf demselben Speicher arbeiten können.

Time Travel: Abfragen in die Vergangenheit

Weil das Transaktionsprotokoll jede Änderung festhält, lässt sich jede Tabelle in dem Zustand abfragen, den sie zu einem beliebigen Zeitpunkt innerhalb der Aufbewahrungsfrist hatte. „Zeig mir diesen Datensatz vom vergangenen Dienstag“ ist eine SQL-Abfrage und keine Wiederherstellung. Für Prüfungen, Fehlersuche und regulatorische Anforderungen ist das entscheidend.

Schema-Durchsetzung und Schema-Evolution

Das Tabellenformat setzt das Schema durch: Schreibvorgänge, die nicht dazu passen, werden abgewiesen. Schemaänderungen wie neue Spalten oder geänderte Nullbarkeit werden versioniert und im Protokoll festgehalten, sodass sich das Modell weiterentwickeln lässt, ohne Pipelines zu zerbrechen.

Plattformen für das Lakehouse

Die Lakehouse-Architektur wird inzwischen von mehreren Plattformen getragen:

• Databricks: der Urheber des Begriffs. Nutzt Delta Lake als eigenes Tabellenformat und Unity Catalog für Governance, stark bei ML und KI.
• Apache Iceberg: das offene Tabellenformat mit der breitesten Unterstützung im Ökosystem, getragen von Snowflake (als Snowflake Open Catalog), AWS (Glue, Athena, EMR), Azure und vielen anderen.
• Snowflake: klassisches Cloud Data Warehouse, das inzwischen Iceberg-Tabellen und gemischte Lakehouse-Architekturen unterstützt und bei SQL und BI weiterhin stark ist.
• Apache Hudi: spezialisiert auf Streaming-Ingestion und inkrementelle Verarbeitung, häufig dort, wo viel CDC anfällt.

Governance im Lakehouse

Gerade die Beweglichkeit des Lakehouse, also beliebige Daten, beliebige Formate, beliebige Compute-Engines, macht Governance zugleich wichtiger und schwieriger als im klassischen Data Warehouse. Dort setzte das strukturierte Schema Governance implizit durch; im Lakehouse muss sie ausdrücklich gebaut werden.

Die entscheidenden Governance-Anforderungen:

• Katalogisierung: Jede Tabelle, jede Partition und jede Datei, die Fachbereiche oder KI-Systeme finden sollen, braucht einen Katalogeintrag mit Schema, Verantwortlichkeit, Qualität und Nutzungsinformationen.
• Feingranulare Zugriffskontrolle: Sicherheit auf Spalten- und Zeilenebene muss über die Abfrage-Engine durchgesetzt werden, nicht erst auf der Speicherschicht. Unity Catalog, Ranger und vergleichbare Werkzeuge leisten das.
• Datenklassifizierung: erkennen, welche Daten personenbezogene Daten, schützenswerte Geschäftsinformationen oder regulierte Inhalte enthalten, und die passenden Zugriffs- und Umgangsregeln anwenden.
• Lineage: nachzuvollziehen, wie Daten von der Rohzone über Transformationen in kuratierte Zonen und weiter in Berichte fließen, ist im Lakehouse aufwendiger als im Warehouse und zugleich wichtiger, weil die Wege vielfältiger sind und die Gefahr größer ist, versehentlich Rohdaten statt kuratierter Daten zu verwenden.

Wann sich ein Lakehouse lohnt

Das Lakehouse ist die richtige Wahl, wenn:

• SQL-Analyse und ML- oder KI-Arbeitslasten auf denselben Daten laufen sollen
• neben strukturierten Daten größere Mengen halbstrukturierter oder unstrukturierter Daten anfallen
• Rohdaten aus regulatorischen, prüferischen oder Wiederaufbereitungsgründen aufbewahrt werden müssen
• ohnehin auf Cloud-Objektspeicher gebaut wird und die Kosten und der Aufwand einer eigenen Data-Warehouse-Ebene entfallen sollen
• das Team mit dbt und Spark vertraut ist und offene Formate und austauschbare Werkzeuge bevorzugt

Ein klassisches Cloud Data Warehouse kann weiterhin die bessere Wahl sein, wenn die Arbeitslasten rein SQL-basiert sind, alle Daten strukturiert vorliegen und das Team auf BI und Berichtswesen ausgerichtet ist statt auf Data Engineering.

Fazit

Das Data Lakehouse ist 2026 zur beherrschenden Architektur für Datenplattformen im Unternehmen geworden, weil es die Kostenrechnung des Objektspeichers mit der Governance und der Geschwindigkeit verbindet, die verlässliche Analyse und KI brauchen. Der entscheidende Punkt: Es verschiebt die Governance-Aufgabe. Statt das Schema beim Laden zu erzwingen, wie es das Warehouse tut, muss Governance ausdrücklich über Katalogisierung, Zugriffskontrolle, Qualitätsüberwachung und Lineage hergestellt werden. Wer in diese Schicht investiert, macht aus dem Lakehouse einen belastbaren Unternehmenswert. Wer es lässt, bekommt einen teuren, undurchsichtigen Datensumpf.