Lakehouse-Architektur: Data Lake und Warehouse in einem System

Viele Unternehmen betreiben beides nebeneinander: einen Data Lake für Rohdaten und Machine Learning, ein Data Warehouse für Reporting. Zwischen beiden läuft eine ständige Kopiererei, die teuer, langsam und fehleranfällig ist. Das Lakehouse verspricht, beides in einem System zu vereinen. Dieser Artikel erklärt, wie das technisch funktioniert, worin der eigentliche Gewinn liegt und wann sich der Umstieg lohnt.

Das Problem: zwei Systeme, eine ständige Kopiererei

Die klassische Architektur trennt zwei Welten. Der Data Lake speichert Rohdaten günstig auf Object Storage und dient Exploration und ML. Das Data Warehouse hält strukturierte, modellierte Daten für schnelles SQL-Reporting. Beide haben ihre Berechtigung, aber sie leben nebeneinander.

Der Preis dieser Trennung ist Bewegung. Daten werden aus dem Lake ins Warehouse kopiert, transformiert, synchronisiert. Jede Kopie kostet Rechenzeit, jede Synchronisation ist eine potenzielle Fehlerquelle, und Reporting und ML arbeiten auf unterschiedlichen Ständen derselben Daten. Ein großer Teil der Data-Engineering-Arbeit fließt in das bloße Verschieben von Daten zwischen zwei Systemen, die dasselbe Unternehmen abbilden.

Was ein Lakehouse ist

Ein Lakehouse bringt die Verlässlichkeit eines Warehouse direkt auf den Object Storage eines Data Lake. Es fügt der günstigen, flexiblen Speicherung genau die Eigenschaften hinzu, die dem Lake fehlten: ACID-Transaktionen, erzwungene Schemata, SQL-Performance und Versionierung. Das Ziel ist, beide Anwendungsfälle, Reporting und Rohdatenverarbeitung, auf einer einzigen Datenkopie zu bedienen.

Damit verschwindet die Trennung zwischen Lake und Warehouse als getrennte Systeme. Es gibt eine Speicherschicht, auf der sowohl ein SQL-Dashboard als auch eine ML-Pipeline arbeiten, ohne dass Daten zwischen zwei Häusern hin- und herwandern.

Wie es funktioniert: offene Tabellenformate

Möglich machen das Lakehouse offene Tabellenformate. Sie sind die entscheidende Erfindung, und drei dominieren: Apache Iceberg, Delta Lake und Apache Hudi.

Technisch liegen die Daten weiterhin als Parquet-Dateien auf dem Object Storage (S3, Azure Data Lake Storage, GCS). Das Tabellenformat legt eine Metadatenschicht darüber, die eine Sammlung von Dateien in eine echte Tabelle verwandelt. Diese Schicht leistet:

• ACID-Transaktionen: Gleichzeitige Schreibvorgänge kollidieren nicht, eine fehlgeschlagene Operation hinterlässt keine halben Daten.
• Schema Evolution: Spalten hinzufügen oder Typen ändern, ohne die Tabelle neu zu schreiben und ohne Konsumenten zu brechen.
• Time Travel: auf einen früheren Stand der Tabelle zugreifen, was Audits, Reproduzierbarkeit und das Zurückrollen fehlerhafter Ladevorgänge ermöglicht.
• Performance: Metadaten und Statistiken, mit denen Query-Engines nur die relevanten Dateien lesen statt der ganzen Tabelle.

Abgefragt wird das Ganze über Engines wie Apache Spark, Trino oder die nativen Dienste der Plattformen (etwa Databricks). Speicher und Rechenleistung bleiben entkoppelt: Der Storage ist offen, die Engine austauschbar.

Der eigentliche Gewinn

Der offensichtliche Vorteil sind Kosten, ein Object Store ist günstiger als ein Warehouse. Der eigentliche Gewinn liegt woanders: im Wegfall einer ganzen Klasse von Problemen.

Wenn Reporting und ML auf derselben Datenkopie arbeiten, entfällt die Synchronisation zwischen Lake und Warehouse. Es gibt keine zwei Wahrheiten mehr, die auseinanderdriften, keine nächtlichen Kopierjobs, die brechen können, keine Diskussion, welcher Stand der richtige ist. Data-Engineering-Kapazität, die vorher in das Verschieben von Daten floss, wird frei. Das ist der Grund, warum das Lakehouse in vielen Projekten zum vernünftigen Standard geworden ist: Es entfernt Arbeit, statt nur Speicher zu verbilligen.

Wann sich ein Lakehouse lohnt, und wann nicht

Ein Lakehouse ist kein Selbstzweck. Die Entscheidung folgt den Anforderungen.

Es lohnt sich, wenn ein Unternehmen beides ernsthaft braucht, strukturiertes Reporting und Rohdatenverarbeitung oder ML, und die Infrastruktur konsolidieren will, statt Lake und Warehouse parallel zu betreiben. Der Tradeoff ist real: mehr Komplexität in der Verwaltung der Tabellenformate und höhere Anforderungen an das Plattformteam.

Es lohnt sich nicht, wenn die Anforderung rein strukturiertes SQL-Reporting ist. Dann ist ein klassisches Data Warehouse einfacher und schneller am Ziel. Und es lohnt sich nicht als Prestigeprojekt: Ein Lakehouse einzuführen, weil der Begriff modern klingt, fügt Komplexität ohne Gegenwert hinzu.

Typische Fehler

Aus der Praxis: die Muster, die Lakehouse-Projekte schwächen.

1. Lakehouse ohne Governance. Dieselbe Zonierung, Katalogisierung und Ownership, die ein Data Lake braucht, gilt weiter. Das Tabellenformat allein verhindert keinen Data Swamp.

2. Format als reine Technikentscheidung. Iceberg, Delta oder Hudi wählen, ohne die Engine-Unterstützung und das bestehende Ökosystem zu prüfen.

3. Konsolidierung erzwingen. Ein funktionierendes Warehouse ablösen, obwohl reines Reporting damit einfacher bedient wäre.

4. Time Travel als Backup missverstehen. Versionierung ersetzt keine Aufbewahrungs- und Sicherungsstrategie.

5. Alles auf einmal migrieren. Statt einen Anwendungsfall zu beweisen, die gesamte Landschaft in einem Zug umstellen.

Lakehouse-Architektur besprechen

DNA Solutions berät Unternehmen im DACH-Raum bei der Entscheidung für und dem Aufbau von Lakehouse-Architekturen: von der Wahl des Tabellenformats über Governance und Query-Engine bis zur schrittweisen Ablösung paralleler Lake- und Warehouse-Systeme. Wenn Sie zwei Systeme synchronisieren, wo eines genügen würde, sequenzieren wir die Konsolidierung entlang eines konkreten Anwendungsfalls. Sprechen Sie uns an.