Data Warehouse vs. Data Lake vs. Lakehouse: Welche Architektur trägt eure Workloads?

Im Quartalsreview werden zwei aufeinanderfolgende Präsentationen gezeigt. Das BI-Team zeigt den Umsatz je Kunde aus dem Data Warehouse. Zwanzig Minuten später präsentiert das Data-Science-Team sein Abwanderungsmodell, gerechnet auf dem Data Lake, mit einem anderen Umsatz je Kunde. Beide Ergebnisse sind auf Grundlage des jeweiligen Datenstands nachvollziehbar. Das Warehouse wurde in der Nacht geladen, die Kopie im Lake am Wochenende. Anschließend muss geklärt werden, welcher Datenstand als verbindlich angesehen wird.

Diese Situation ist in historisch gewachsenen Datenlandschaften weit verbreitet: ein Warehouse für das Reporting, ein Lake für Data Science. Zwischen beiden Systemen übertragen Pipelines regelmäßig Datenkopien. Bei jeder neuen Anforderung muss erneut entschieden werden, in welchem System sie umgesetzt wird.

Brauchen wir das Warehouse noch, wenn der Lake längst alle Daten hält? Kann der Data Lake auch verlässliches Reporting unterstützen? Bietet das Lakehouse einen eigenständigen Architekturansatz oder lediglich eine neue Bezeichnung für bestehende Konzepte? Welche Architektur unterstützt BI, Data Science und Streaming auf einer gemeinsamen Datenbasis?

Die Entscheidung sollte sich an den benötigten Workloads und nicht an grundsätzlichen Präferenzen für eine bestimmte Technologie orientieren. Sobald die Workload-Frage beantwortet ist, lässt sich in einem gemeinsamen Workshop eine fundierte Vorauswahl der Architektur treffen.

Data Warehouse und Data Lake wurden für unterschiedliche Anwendungsfälle entwickelt. Die klassische Data-Warehouse-Architektur entstand in den 1990er-Jahren für eine Aufgabe: verbindliche Kennzahlen aus vielen Quellsystemen, konsistent modelliert, performant abfragbar, häufig ergänzt um Data Marts als fachbereichsbezogene Ausschnitte. Der Data Lake entstand rund 15 Jahre später für eine andere Aufgabe: wachsende Datenmengen jeder Form so günstig speichern, dass Datenteams damit experimentieren können, auch wenn die späteren Analyseanforderungen noch nicht vollständig bekannt sind.

Auch die Verarbeitungslogik unterscheidet sich, im Betriebsalltag meist als ETL vs. ELT diskutiert. Im klassischen Warehouse-Umfeld wird häufig ETL eingesetzt: Daten werden transformiert, bevor sie geladen werden, damit sie bereits beim Laden dem festgelegten Datenmodell entsprechen. Im Data-Lake-Umfeld wird häufig ein ELT-Ansatz verwendet: Daten landen roh im Speicher und werden erst danach in Schichten aufbereitet. Beides sind Werkzeuge der Datenaufbereitung. Die Abgrenzung ist heute weniger eindeutig, da moderne Plattformen beide Verfahren unterstützen.

Ein dritter Unterschied liegt im Verhältnis von Speicher und Rechenleistung. Im klassischen Warehouse sind beide gekoppelt: Wachsende Datenmengen können zusätzliche Infrastruktur erforderlich machen, auch wenn die Abfragelast gleich bleibt. Lake und Lakehouse trennen die beiden Größen. Der Speicher wächst günstig im Objektspeicher, Rechenleistung wird je Workload zugeschaltet und wieder abgebaut. Die getrennte Skalierung von Speicher und Rechenleistung beeinflusst das Kostenmodell wesentlich.

Ein direkter Vergleich greift deshalb zu kurz, wenn die unterschiedlichen Zielsetzungen nicht berücksichtigt werden. Das Warehouse ist die stärkere Option bei Verlässlichkeit und Reporting-Performance. Der Lake liegt vorn bei Datenvielfalt, Kosten pro Terabyte und Freiheit für Datenteams. In der Praxis betreiben viele Unternehmen deshalb beide Systeme parallel.

Ein Data Lakehouse verfolgt das Ziel, Warehouse- und Lake-Workloads auf einer gemeinsamen Datenbasis zusammenzuführen. Offener Objektspeicher wird dabei um Funktionen ergänzt, die verlässliches Reporting ermöglichen. Möglich machen das offene Tabellenformate, die zwischen Dateien und Abfrage-Engine eine zusätzliche Verwaltungs- und Transaktionsschicht bereitstellen.

Der Begriff wurde insbesondere durch Databricks geprägt und verbreitet. Die zugrunde liegenden Architekturprinzipien sind dokumentiert und technisch nachvollziehbar. Forscher um Michael Armbrust beschreiben das Konzept im Lakehouse-Paper der CIDR-Konferenz 2021 als offene Plattform, die Datenmanagement-Funktionen eines Warehouse direkt auf günstigem Cloud-Speicher umsetzt. Die tragenden Formate sind als Open Source verfügbar und werden von mehreren Anbietern unterstützt.

Offene Tabellenformate ergänzen einen klassischen Data Lake um drei zentrale Funktionen. Erstens ACID-Transaktionen: Schreibvorgänge werden vollständig oder gar nicht wirksam, parallele Schreib- und Lesevorgänge können konsistent verarbeitet werden. Zweitens Schema-Regeln: Nicht schema-konforme Daten können beim Schreiben abgelehnt werden. Drittens nachvollziehbare Datenstände, oft Time Travel genannt (Zugriff auf frühere Versionen einer Tabelle), was Korrekturen und Audits erleichtert. Das Delta-Lake-Projekt dokumentiert diese Eigenschaften als Transaktionsschicht über Parquet-Dateien.

Mit Apache Iceberg existiert ein zweites offenes Tabellenformat mit vergleichbarem Ziel. Welche Stärken die beiden Formate unterscheiden, vergleichen wir in den Überblicken zu Delta Lake und Iceberg.

Die Modellierungsprinzipien des Data Warehouse bleiben erhalten und werden als strukturierte Serving-Schicht umgesetzt. In einer Medallion-Architektur werden Daten schrittweise aufbereitet und strukturiert: Sie kommen roh an, werden bereinigt und integriert und stehen schließlich als geschäftsfertige Tabellen für Reporting und Self-Service bereit. Databricks beschreibt dieses Schichtenmodell mit Bronze-, Silver- und Gold-Ebene. Die Gold-Ebene übernimmt die Rolle, die bisher das Warehouse gespielt hat: modellierte, verbindliche Daten. Wie dieses Schichtenmodell entworfen wird, zeigen wir im Überblick zur Medallion-Architektur.

Technische Tabellenformate lösen jedoch weder fachliche Modellierung noch organisatorische Verantwortlichkeiten. Ein bestehender Data Lake wird nicht allein durch ein Tabellenformat zu einer verlässlichen Datenplattform.

Gleichzeitig erweitern auch Cloud Data Warehouses, im Markt auch als Modern Data Warehouse positioniert, ihre Unterstützung für offene Tabellenformate und weitere Workloads. Die funktionalen Unterschiede zwischen den Plattformansätzen werden zunehmend geringer. Entscheidend bleibt, ob offene Datenformate das zentrale Fundament der Architektur bilden oder lediglich ergänzend unterstützt werden.

Aus diesen Kriterien lässt sich ein Entscheidungsraster ableiten. Dabei sollten zunächst die Fälle betrachtet werden, in denen bestehende Architekturen weiterhin ausreichend sind, denn eine Konsolidierung ist nicht in jeder Datenlandschaft notwendig.

• Eure Analytik besteht aus strukturiertem Reporting und SQL-Auswertungen, und daran wird sich auf absehbare Zeit wenig ändern.
• Die Quellsysteme sind stabil und überschaubar, neue Datenformen wie Sensorik, Logs oder Texte sind nicht absehbar.
• Das bestehende Warehouse läuft verlässlich, das Modell ist gepflegt, und es bestehen keine konkret geplanten und finanzierten ML- oder Streaming-Anwendungsfälle.

In dieser Situation kann ein Plattformwechsel mehr Aufwand verursachen, als er Nutzen schafft. Sinnvoller ist es dann häufig, das bestehende Datenmodell und die Reporting-Prozesse weiterzuentwickeln.

• Ihr sammelt große Rohdatenmengen als Archiv oder für Exploration, und der Zugriff erfolgt überwiegend durch technisch erfahrene Daten- und Engineering-Teams.
• Reporting läuft woanders und soll dort bleiben, der Data Lake dient nicht als verbindliche Grundlage für Management-Reporting.
• Kosten pro Terabyte sind das dominierende Kriterium, etwa bei Sensordaten oder langlebigen Rohdaten-Archiven.

Der Lake bleibt dann eine Speicher- und Explorationsschicht mit begrenztem Auftrag. Der vorgesehene Einsatzbereich sollte organisatorisch klar festgelegt und eingehalten werden. Andernfalls entstehen mit der Zeit zusätzliche Reporting-Anforderungen auf einer dafür nicht ausgelegten Datenbasis.

• BI, Data Science und Streaming sollen auf dieselben Daten zugreifen, und heute werden dafür Daten regelmäßig zwischen mehreren Systemen übertragen.
• Reporting und Machine-Learning-Modelle verwenden unterschiedliche Datenstände oder Definitionen.
• Governance-Regeln sollen zentral definiert und für unterschiedliche Workloads einheitlich angewendet werden, vom Dashboard bis zum ML-Modell.
• Offene Daten- und Tabellenformate sind eine langfristige Architekturvorgabe, etwa um Abfrage-Engines wechseln zu können, ohne Daten zu migrieren.

Zusätzliche Anforderungen entstehen aktuell insbesondere durch KI-Anwendungsfälle: Sprachmodelle und RAG-Anwendungen arbeiten auf Texten, Dokumenten und Logs, also auf Datenformen, die ein klassisches Warehouse kaum sinnvoll aufnimmt. Sobald solche Use Cases mit Budget auf der Roadmap stehen, gehen die Anforderungen automatisch über klassisches SQL-Reporting hinaus.

Für eine erste Einordnung im Steering Committee gilt: Wenn eure Analytik bei strukturiertem SQL-Reporting endet, trägt ein Warehouse. Wenn nur Datenteams auf Rohdaten arbeiten, genügt ein Lake mit klarem Auftrag. Wenn mehrere Workload-Typen dieselben Daten brauchen, prüft das Lakehouse. Und wenn bestehende Datenkopien bereits zu widersprüchlichen Kennzahlen führen, sollte eine Konsolidierung ernsthaft geprüft werden.

Der Vergleich bietet eine erste Orientierung für die Wahl der Plattformarchitektur. Einige Fragen beantwortet er grundsätzlich nicht. Diese zusätzlichen Fragen sind jedoch wesentlich für die erfolgreiche Umsetzung.

Trotz dieser Einschränkungen unterstützt der Vergleich eine fundierte grundsätzliche Architekturentscheidung: Er hilft dabei, Workloads, Datenkopien und Governance-Anforderungen vor der Auswahl eines Produkts zu bewerten. Die Wahl der konkreten Plattform, ob die offene Datenbasis bei Databricks, einem Cloud-Warehouse mit offenen Formaten oder einem Eigenbau liegt, sollte erst im nächsten Schritt erfolgen und fällt leichter, wenn das Muster feststeht. Offen bleibt auch die Organisationsfrage: Data Mesh ist ein Verantwortungs- und Verteilungsmuster für Datenprodukte und lässt sich mit jedem der drei Speicher-Muster kombinieren.

Sobald operative Berichte, Modelle und Compliance-Pflichten an der Plattform hängen, gehört die Entscheidung dokumentiert. Für die gewählte Architektur sollten klare Exit-Kriterien und realistische Rückbau- oder Migrationsmöglichkeiten vorgesehen werden.