Data Lakehouse

Strukturierte Daten liegen im Warehouse, Logdaten, Dokumente, Sensordaten und Datensätze für KI in anderen Systemen. Reporting und KI arbeiten dadurch auf getrennten Beständen, die erst aufwendig abgeglichen werden müssen.

Ein Data Lakehouse legt alles in offenen Formaten im Cloud-Speicher ab und stellt darauf Tabellen mit den Eigenschaften eines Data Warehouse bereit. Ob das zu den Daten und Zielen passt, prüfen wir zuerst. Was in beiden Welten gleich ist, etwa Schichten und Historisierung, beschreiben wir auf der Seite zum Data Warehouse und wiederholen es hier nicht.

Dateien, Tabellenschicht, Katalog

Ein Lakehouse besteht aus drei Teilen. Unten liegen Dateien im Cloud-Speicher, meist im Format Parquet. Darüber sitzt eine Tabellenschicht, die liefert, was reine Dateien nicht können: ACID-Transaktionen, Schema-Verwaltung, Änderungen einzelner Zeilen und den Zugriff auf frühere Tabellenstände (Time Travel). Der Katalog verzeichnet, welche Tabellen es gibt und wer darauf zugreifen darf.

Auf diese Tabellen greifen verschiedene Engines zu: SQL-Abfragen für Berichte, Spark für Datenaufbereitung und Machine Learning, Streaming-Jobs für laufend eintreffende Daten. Das ist der eigentliche Unterschied zum klassischen Warehouse, bei dem Speicher und Abfrage-Engine eng gekoppelt sind.

Wann das Lakehouse mehr kann als ein Warehouse

Für überwiegend strukturierte Daten und klassisches Reporting raten wir zum Warehouse. Ein Lakehouse nur wegen des Namens zu bauen, macht die Sache komplizierter und nicht besser.

Es lohnt sich, wenn die Daten anders aussehen oder anders genutzt werden. Zum Beispiel, wenn sehr große Mengen anfallen, die im Objektspeicher günstig liegen und unabhängig von der Rechenleistung wachsen. Oder wenn Dokumente, Bilder, Logs, JSON und Sensordaten neben den Tabellen verfügbar sein sollen. Oder wenn Modelle auf denselben Daten trainiert werden, auf denen das Reporting läuft, ohne dass Kopien entstehen, und KI-Anwendungen Dokumente und Tabellen als Wissensbasis nutzen. Auch Daten, die laufend eintreffen und ohne Umweg abfragbar sein sollen, sprechen dafür.

Beides schließt sich nicht aus. Häufig steht ein Lakehouse für Rohdaten und KI neben einem Warehouse für das geprüfte Reporting, oder das Warehouse läuft selbst auf offenen Formaten.

Delta, Iceberg oder Hudi

Delta Lake entstand im Umfeld von Databricks und ist die Grundlage von Microsoft Fabric: Alle Tabellen in OneLake liegen als Delta-Tabellen vor. Apache Iceberg wird von den meisten großen Plattformen gelesen, wenn auch in unterschiedlichem Umfang. Apache Hudi ist vor allem bei häufigen Aktualisierungen einzelner Datensätze und beim Streaming üblich.

Die Formate nähern sich an. Microsoft bietet in OneLake eine Umsetzung, bei der dieselbe Tabelle als Delta Lake und als Iceberg gelesen werden kann, ohne die Daten zu kopieren, und auch andere Anbieter machen Delta-Tabellen für Iceberg-Leser sichtbar. Die Entscheidung hängt deshalb weniger am Format selbst als daran, welche Werkzeuge es lesen und schreiben sollen. Funktionen und Versionsstände unterscheiden sich je Plattform, das prüfen wir vor jeder Festlegung.

Der Katalog bestimmt, wie offen es wirklich ist

Entscheidend ist, ob mehrere Engines denselben Katalog nutzen können. Als gemeinsame Schnittstelle hat sich der Iceberg REST Catalog etabliert. Umgesetzt wird er unter anderem von Apache Polaris, das im Februar 2026 zum Top-Level-Projekt der Apache Software Foundation wurde und von Anbietern wie Snowflake mitgetragen wird. Databricks bringt den Unity Catalog mit, und auch Google und AWS haben eigene Kataloge.

Offene Formate im eigenen Speicher verringern die Abhängigkeit von einem Anbieter. Wer wechselt, muss nicht alle Daten neu laden. Ein vollständiger Schutz ist das nicht. Zugriffsregeln, Klassifizierungen und Lineage hängen oft am Katalog des jeweiligen Anbieters, manche Plattformen lesen Tabellen anderer Engines, schreiben aber nur in eigene, und neuere Formatfunktionen kommen nicht überall gleich schnell an. Wir entscheiden deshalb bewusst, wo Offenheit wichtig ist und wo die Funktionen eines Anbieters Vorrang haben.

Weil Tabellen, Dateien und Modelle auf einer Plattform liegen, müssen auch die Regeln zentral gelten: Zugriffsrechte bis auf Zeilen- und Spaltenebene, Klassifizierung sensibler Daten, Nachvollziehbarkeit der Herkunft, Protokollierung. Am besten werden sie im Katalog gepflegt, damit Berichte, Notebooks und KI-Anwendungen dieselben Regeln sehen. Welche Regeln gelten und wer dafür verantwortlich ist, legt die Data Governance fest. Beim Lakehouse setzen wir sie technisch um.

Wie ein Lakehouse schiefgeht

Meist liegt es am fehlenden Zweck. Wer nur strukturierte Daten für Berichte hat, kommt mit einem Warehouse schneller ans Ziel. Der zweite Klassiker ist der Data Lake, der unübersichtlich wird: Ohne Struktur, Zuständigkeiten und Katalog findet niemand, was vorhanden ist, und niemand vertraut den Daten.

Dazu kommen Kosten und Rechte. Offene Abfragen auf großen Datenmengen verbrauchen schnell viel Rechenleistung, und Zugriffsregeln lassen sich nachträglich schwer durchsetzen. Jede zusätzliche Kombination aus Format und Engine erhöht außerdem den Pflegeaufwand. Und wenn Reporting und KI dieselben Daten nutzen, müssen Kennzahlen einmal definiert und die Datenqualität geprüft sein, sonst entstehen nur schneller mehr Varianten derselben Zahl.