Ratgeber & Vergleiche · Stand: 18. Oktober 2026

Data Lake vs. Data Warehouse: Unterschiede und Lakehouse

Ein Data Lake bewahrt Daten aus unterschiedlichen Quellen flexibel als Dateien oder Objekte auf. Ein Data Warehouse stellt zusammengeführte, fachlich modellierte Daten für definierte Analysen und Berichte bereit. Ein Lakehouse verbindet lakebasierte Speicherung mit Tabellenverwaltung und Analysefunktionen. Die passende Architektur ergibt sich aus Ihren Fragen, Daten und Betriebsfähigkeiten; Lake und Warehouse können auch gemeinsam sinnvoll sein.

Für die Auswahl reicht die Frage nach dem Speicherort nicht. Sie müssen wissen, wer welche Daten in welcher Qualität, mit welchen Rechten und wie aktuell benötigt. Der folgende Vergleich führt deshalb von den Begriffen zu konkreten Anforderungen und einem eigenen Modellfall.

Was Lake und Warehouse jeweils leisten

Data Lake: Daten für unterschiedliche Fragen erhalten

Ein Data Lake kann Tabellenexporte, verschachtelte Ereignisdaten, Texte und Bilder aufnehmen. Die ursprünglichen Daten bleiben für spätere Fragen verfügbar, die beim ersten Laden noch nicht feststanden. Dabei können neben Rohdaten auch bereinigte und aufbereitete Bestände im Lake liegen. Microsoft beschreibt diese Vielfalt in seiner Einführung zum Data Lake.

Die Ablage ist nur ein Bestandteil der Lösung. Speicher hält Dateien; ein Katalog beschreibt auffindbare Datensätze und ihre Bedeutung; eine Verarbeitungsengine liest und verändert Daten; Abfragewerkzeuge und Anwendungen stellen den Nutzungszugriff bereit. Orchestrierung, Rechte und Überwachung verbinden diese Teile. Eine Sammlung von Dateien ist deshalb noch kein verlässlicher Analysedienst.

Der Nutzen liegt in der Wiederverwendbarkeit: Ein Team kann zunächst Rohereignisse untersuchen und später daraus ein neues Merkmal ableiten. Es muss dafür trotzdem den Inhalt verstehen, zulässigen Zugriff erhalten und die verwendeten Daten prüfen.

Data Warehouse: gemeinsame Modelle für wiederkehrende Analysen

Ein Data Warehouse führt Daten aus mehreren Quellen für fachliche Auswertungen zusammen. Es legt beispielsweise fest, wie Bestellungen, Kunden und Zeiträume zusammenhängen und welche Definition für einen ausgewiesenen Umsatz gilt. Historische Stände ermöglichen Zeitvergleiche. SQL-Abfragen und angeschlossene BI-Werkzeuge nutzen diese Modelle für Berichte und Analysen.

Fakten- und Dimensionstabellen sind eine mögliche Modellierung; andere Modelle können ebenfalls passen. Weder eine bestimmte Normalform noch ein ausschließlich lesender Gesamtbetrieb definiert das Warehouse. Ein Analyst darf nur lesen ist eine Berechtigungsentscheidung; die Aufbereitung kann den Bestand weiterhin ergänzen oder korrigieren.

Warehousing gibt es lokal, als Cloud-Dienst und in hybriden Umgebungen. Moderne Systeme überschreiten zudem den alten Gegensatz zwischen relationalen Tabellen und anderen Formaten. Die IBM-Einordnung der drei Architekturkonzepte beschreibt diese Entwicklung und die mögliche Kombination. Ihre Aufgabe bleibt, ein tatsächlich verständliches und geprüftes Fachmodell bereitzustellen.

Datenstruktur, Schema und Qualität auseinanderhalten

Die folgenden kleinen Datenbeispiele gehören zu einem fiktiven Bestellportal. Sie sind keine Kundendaten:

Ein unveränderter Tabellenexport ist roh und zugleich strukturiert. Ein bereinigtes JSON-Dokument kann weiterhin verschachtelt sein. Bearbeitungszustand, Struktur und fachliche Qualität beantworten verschiedene Fragen.

Auch ein Warehouse ist technisch nicht auf starre relationale Spalten beschränkt. Snowflake kann beispielsweise JSON und weitere dokumentierte Formate laden und unter anderem in VARIANT, ARRAY oder OBJECT speichern. Das belegt die Referenz zu semistrukturierten Daten. Die Unterstützung eines Formats ersetzt wiederum keine verständliche Kennzahlendefinition.

Wann wird das Schema verbindlich?

Bei Schema-on-Read wird die benötigte Interpretation beim Lesen angewendet. Ein Ladeprozess kann das ursprüngliche Ereignis erhalten, während eine spätere Auswertung entscheidet, welche Felder sie wie verwendet. Diese Leselogik braucht trotzdem ein Schema: Ist ein Betrag Text oder Zahl? Welche Zeitzone verwendet der Zeitstempel? Fehlt ein Pflichtmerkmal, muss jemand über Fehlerbehandlung und Freigabe entscheiden.

Ein früher verbindlicher Schema- und Modellvertrag prüft solche Bedingungen bereits bei der Aufnahme in die betreffende Tabelle oder bei deren Aufbereitung. Fehler werden früher sichtbar; dafür muss eine Änderung des Vertrags mit den betroffenen Nutzern abgestimmt werden. Bei späterer Interpretation verschiebt sich ein Teil dieser Arbeit zu den lesenden Anwendungen und ihren Verantwortlichen.

Die Grenze verläuft nicht sauber zwischen zwei Produktklassen. Warehouses können flexible Aufnahmebereiche besitzen. Ein Lakehouse kann Schemaregeln an Tabellen durchsetzen. Entscheiden Sie deshalb für jeden bereitgestellten Datensatz, wann Struktur und Bedeutung verbindlich werden und wer einen abweichenden Datensatz zurückhält oder neu verarbeitet.

Korrektur und Historie sind unterschiedliche Anforderungen

Im Modellportal könnte ein Versanddatum falsch übertragen worden sein. Eine Korrektur soll dann die Auswertung berichtigen. Ein Kunde kann aber auch tatsächlich die Region wechseln; für frühere Auswertungen kann seine damalige Region weiterhin relevant sein. Überschreiben und historisches Fortschreiben erfüllen hier unterschiedliche Zwecke.

Legen Sie fest, ob Sie nur anhängen, Datensätze aktualisieren oder löschen und frühere fachliche Stände erhalten müssen. Welche Operationen sicher möglich sind, hängt von Engine, Tabellenformat und Datenvertrag ab. Die Dateien eines Lake sind nicht automatisch beliebig nebenläufig änderbar; ein Warehouse ist ebenso wenig grundsätzlich unveränderlich. Auch ein technischer Tabellensnapshot ersetzt keine bewusst definierte fachliche Historie.

Die Unterschiede an Ihren Anforderungen prüfen

Die Berufsbezeichnung allein legt die Architektur nicht fest. Ein Reportingteam benötigt meist wiederkehrende, vergleichbare Kennzahlen. Data Science kann detaillierte Rohereignisse für eine neue Frage benötigen. Data Engineering muss Aufnahme, Verarbeitung und Bereitstellung betreiben. Gemischte Teams brauchen abgestimmte Übergaben zwischen diesen Aufgaben. Self-Service setzt in jedem Fall verständliche Datensätze, einen nutzbaren Katalog und passende Rechte voraus.

Nutzen Sie für den Vergleich diese Prüffragen. Sie sind eine Entscheidungshilfe, keine gemessene Rangfolge:

ETL oder ELT bezeichnet, ob die Transformation vor oder nach dem Laden in das betrachtete Ziel stattfindet. Batch oder Streaming betrifft die Verarbeitung im Zeitverlauf. Diese Entscheidungen sind vom Namen der Datenhaltung zu trennen. Ein Lake kann verspätet befüllt werden; auch ein Warehouse kann häufig aktualisiert werden. Den sichtbaren Datenstand müssen Sie über die gesamte Verarbeitung bis zum Bericht prüfen.

Für die Antwortzeit sind unter anderem Dateiformat, Partitionierung beziehungsweise Pruning, Engine, Datenmodell, Aggregationen und Parallelität relevant. Pruning bedeutet, nicht benötigte Datenbereiche beim Lesen auszulassen. Ein sinnvoller Test vergleicht eine feste BI-Abfrage und eine breitere Explorationsfrage unter dokumentierter Last. Halten Sie fest, ob Caches bereits gefüllt waren und ob dieselbe fachliche Ergebnismenge herauskam. Das Etikett Lake oder Warehouse liefert noch keinen belastbaren Geschwindigkeitsvergleich.

Beim Wachstum gilt ebenfalls keine allgemeine Regel „Lake horizontal, Warehouse vertikal“. Moderne Dienste können Speicher und Compute trennen. Bei Snowflake sind beispielsweise gespeicherte Daten und unabhängige Compute-Warehouses getrennte Architekturteile; die Architekturreferenz beschreibt sie ausdrücklich. Wachsende Datenhaltung und zusätzliche Abfragekapazität sind somit unterschiedliche Entscheidungen. Viele kleine Dateien oder ein überlastetes Betriebsteam bleiben eigene Grenzen.

Ein niedriger Preis für Objektspeicher beantwortet die Gesamtkostenfrage nicht. Vergleichen Sie denselben Datenumfang, Nutzungsrhythmus, Frischebedarf und Betriebsumfang. Häufige Vollscans, zusätzliche Kopien oder schlecht zugeordnete Transformationsjobs können die Rechnung prägen. Auch kleine Datenbestände können ein verbindliches Warehousemodell brauchen; ein Lake erfordert keine vorher erreichte Petabytegrenze.

Governance für jede Variante gestalten

Benennen Sie für jeden freigegebenen Bestand einen fachlichen Owner und einen technischen Betriebsverantwortlichen. Dokumentieren Sie Herkunft, Bedeutung, Qualitätsregeln und die erlaubte Nutzung. Eine Rohdatenzone braucht eingeschränkte Rechte, gerade wenn sie mehr Felder als der spätere Bericht enthält. Katalogeintrag und Tag erleichtern die Einordnung; der erlaubte Zugriff muss zusätzlich durchgesetzt werden.

Unterscheiden Sie technische Validierung von fachlicher Freigabe: Ein Datum kann syntaktisch korrekt und trotzdem der falsche Geschäftstag sein. Legen Sie auch Aufbewahrung, Korrektur und Löschung passend zum konkreten Datenbestand fest. Keine der drei Architekturbezeichnungen beweist Datenqualität oder rechtliche Konformität.

Kombination und Lakehouse: Welche Arbeit kommt hinzu?

Lake und Warehouse können verschiedene Aufgaben derselben Lösung übernehmen. Ursprüngliche Ereignisse bleiben für neue Analysen erhalten, während ausgewählte Daten in ein gemeinsames Berichtsmodell einfließen. Der Übergang kann eine physische Kopie, eine unterstützte externe Abfrage oder die Nutzung gemeinsam verwalteter Tabellen enthalten.

Diese Wege unterscheiden sich bei unterstützten Operationen, Datenstand und Verantwortlichkeit. Bei Kopien brauchen Sie Abgleich und Wiederanlauf. Bei externem Zugriff müssen Quelle, Katalog, Engine und Rechte zusammenpassen. „Gemeinsam genutzt“ bedeutet deshalb nicht automatisch „ohne Kopien“ oder „überall derselbe Stand“.

Ein Lakehouse ergänzt lakebasierte Datenhaltung um eine Tabellen- und Metadatenebene sowie geeignete Analyseengines. Damit können BI und ML denselben verwalteten Bestand verwenden. Prüfen Sie, welche Engine welche Formate lesen und schreiben kann und wie die Tabelle gepflegt wird. Lakehouse ist ein Architekturkonzept, kein einzelnes Produkt und kein automatischer Ersatz eines funktionierenden Warehouse.

Die Grafik ordnet die Aufgaben nebeneinander ein. Sie beschreibt keine vorgeschriebene Migrationsfolge:

Eine Parquet-Datei ist noch keine verwaltete Tabelle

Ein Dateiformat wie Parquet beschreibt die Speicherung von Daten innerhalb einer Datei. Eine Tabellenebene muss zusätzlich festlegen, welche Dateien zu welchem Tabellenstand gehören und wie Änderungen veröffentlicht werden. Die dafür verwendeten Verfahren unterscheiden sich:

ACID steht für Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Die Zusage bezieht sich auf den jeweils unterstützten Transaktionsumfang. Daraus folgt keine atomare Geschäftsabwicklung über eine API, mehrere Tabellen und einen fremden Berichtsdienst hinweg. Prüfen Sie die konkrete Kombination aus Format, Engine, Katalog und gleichzeitig schreibenden Prozessen.

Ein offenes Format allein macht außerdem weder SQL-Abfragen noch Zugriffsregeln und Betriebsabläufe unverändert portabel. Fragen Sie getrennt: Können wir die Dateien lesen? Können wir die Tabelle korrekt weiterschreiben? Lassen sich Katalog, Rechte und laufende Jobs auf dem vorgesehenen Ziel nachbilden?

Medallion beschreibt eine andere Achse

Bronze, Silver und Gold beschreiben logische Aufbereitungs- und Qualitätszustände. Sie können innerhalb einer Lakehouseplattform umgesetzt werden; Bronze und Silver müssen nicht physisch einem Lake und Gold einem getrennten Warehouse entsprechen. Diese Einordnung folgt dem offiziellen Medallion-Designmuster.

Wenn Ihre offene Frage vor allem die Qualitätsübergaben zwischen diesen Zuständen betrifft, führt der eBiz-Leitfaden zur Medallion-Architektur weiter. Die Speicher- und Analyseentscheidung bleibt davon getrennt.

Ein Modellfall mit Reporting und Exploration

Für das fiktive Bestellportal liegen Bestellpositionen, Kundenzuordnungen und Klickereignisse vor. Das Reportingteam vereinbart für den Vergleich einen Tagesumsatz: den Nettobetrag versandter Positionen am Versandtag; zugeordnete Stornos korrigieren diesen ursprünglichen Tag. Die Regel ist eine eigene illustrative Kennzahlendefinition, keine allgemeingültige Umsatzvorschrift.

Data Science möchte dagegen untersuchen, welche Klickfolgen einem Kauf vorausgehen. Eine Tagessumme würde diese Reihenfolge verlieren. Engineering muss beide Nutzungen aus denselben nachvollziehbaren Quellen versorgen.

Eine begründete erste Lösung wäre, Rohereignisse mit eingeschränktem Zugriff zu erhalten und für das Reporting ein kuratiertes Positions-/Tagesmodell bereitzustellen. Existiert bereits ein geeignetes Warehouse, kann es zunächst das Berichtsmodell tragen. Eine zusätzliche Lakehouseplattform wäre erst dann zu begründen, wenn gemeinsame Tabellen, weitere Analysewege oder konkrete Grenzen der vorhandenen Umgebung sie erforderlich machen.

Ein kleines Team mit klaren Kennzahlen braucht nicht automatisch mehrere Plattformen. Umgekehrt beantwortet die reine Dateiablage weder die Stornoregel noch die Zuordnung wechselnder Kundeneigenschaften. Fehlt der Kennzahlenowner, löst ein neuer Speicher den Konflikt nicht.

Vor einer Erweiterung prüfen die Verantwortlichen deshalb auch Katalogpflege, Rechteänderungen, Tabellenwartung, Monitoring und Recovery. Wer bemerkt einen ausgefallenen Import? Wer entscheidet über die Wiederverarbeitung? Welcher bestätigte Stand steht Berichten zur Verfügung, während ein Fehler behoben wird? Ohne diese Antworten fehlt dem Zielbild ein tragfähiger Betrieb.

Eine Datenquelle bis zum nutzbaren Ziel verfolgen

Zur Architektur gehört im Modell auch ein externer Transaktionsdatenstrom. Dessen Aufnahme ist nicht dadurch erledigt, dass ein Lake oder Warehouse bereitsteht. Ein nachvollziehbarer, hier nicht ausgeführter Modellablauf umfasst:

1. Historischen Umfang bestimmen. Welche Objekte und Zeiträume müssen zunächst nachgeladen werden? Dieser Backfill ist vom späteren laufenden Nachladen zu unterscheiden.
2. Alle Seiten lesen. Der Abruf arbeitet mit stabilen Objekt-IDs und dem vorgesehenen Cursor. Eine erfolgreiche erste Antwort belegt noch keinen vollständigen Bestand. Endekriterium, übernommene IDs und vereinbarte Vollständigkeitskontrollen werden protokolliert.
3. Unterbrechungen beherrschen. Ein bestätigter Fortschrittspunkt erlaubt die Wiederaufnahme. Wiederholungen dürfen einen bereits übernommenen Geschäftsvorgang nicht unbemerkt verdoppeln; Fehler und Ratenbegrenzungen brauchen eine festgelegte Behandlung.
4. Änderungen abnehmen. Neue oder anders typisierte Felder werden gegen den Datenvertrag geprüft. Sensible Kunden- und Transaktionsfelder gelangen nur in den vereinbarten Zugriffskreis.
5. Bis zur Kennzahl abstimmen. Nach erfolgreicher Aufnahme werden Datensätze, Zeiträume und fachliche Summen mit dem bestätigten Quellumfang verglichen. Ein fehlender Storno darf nicht erst am fertigen Dashboard auffallen.

Ein konkretes Beispiel für Cursorpaginierung sind die Stripe-v1-Listen mit starting_after beziehungsweise ending_before und dem Antwortfeld has_more. Die Originalreferenz zur Paginierung weist ausdrücklich auf eine andere Schnittstelle im v2-Namensraum hin. Übertragen Sie diese Parameter daher nicht ungeprüft auf eine andere API. Der Modellablauf erfordert hier weder eine reale Zahlungsaktion noch einen API-Aufruf.

Vorgefertigter Anschluss oder eigene Pipeline?

Ein vorgefertigter Export oder Connector kann einen Teil dieser Arbeit übernehmen. Prüfen Sie am konkreten Angebot: Welche Objekte und historische Zeiträume werden tatsächlich unterstützt? Wie werden Aktualisierungen und Löschungen behandelt? Welche Zielregion, welches Frischeziel und welcher Vertrag gelten? Wer erkennt und behebt eine unvollständige Übernahme?

Eine eigene Pipeline kann andere Anpassungen ermöglichen, überträgt aber API-Änderungen, Wiederholungslogik und Betrieb an Ihr Team. Stellen Sie beide Varianten anhand desselben benötigten Bestands und derselben Abnahmekriterien gegenüber. Herstellernähe allein beweist weder höhere Sicherheit noch geringere Gesamtkosten. Das sind Prüfaufträge für den tatsächlichen Datenweg, keine Eigenschaften eines erfundenen eBiz-Connectors.

Anforderungen und ersten Test festhalten

Halten Sie vor der Technologiewahl das vorhandene System und den gewünschten Nutzungsweg auf einer Seite fest:

• Datenarten, Quellen, aktueller Umfang und erwartete Änderungen.
• Fachliche Fragen, Nutzergruppen und verbindliche Kennzahlen.
• Benötigtes Datenalter, Antwortzeit und repräsentative Parallelität.
• Rechte, sensible Felder, Korrekturen, Historie und Aufbewahrung.
• Vorhandene Komponenten, Teamfähigkeiten, Betriebszuständigkeit und Budget.
• Erwartete Ergebnisse und Bedingungen, unter denen die gewählte Variante verworfen wird.

Für den Modellfall wäre ein erster Test die Tagesauswertung mit einer verspäteten Lieferung, einem Storno und einem wiederholten Quellabruf. Prüfen Sie die vereinbarte Kennzahl, die Vollständigkeit und die Rechte anschließend sowohl im Detail als auch im Bericht. Ergänzen Sie die benötigte Last und einen unterbrochenen Ladevorgang. Dokumentieren Sie erwartete und tatsächliche Ergebnisse; hier werden keine Testerfolge behauptet.

So wird aus dem Begriffvergleich eine konkrete Architekturfrage: Welche vorhandene Komponente erfüllt diese Aufgaben, und welche zusätzliche Fähigkeit fehlt nachweisbar? Für die Prüfung von Datenarchitektur und Integration bietet eBiz den bestehenden Bereich Cloud Data & AI als nächsten fachlichen Anschluss.