Zwei Speicherphilosophien
Beide speichern große Datenmengen für Analysen – aber mit gegensätzlicher Grundhaltung. Das Data Warehouse fragt: Welche Fragen wollen wir beantworten? und strukturiert die Daten vorab entsprechend. Der Data Lake fragt: Welche Daten haben wir? und speichert erst einmal alles im Rohformat – die Fragen kommen später. Diese Differenz zieht sich durch alles: Kosten, Nutzer, Werkzeuge und Datenqualität.
Data Warehouse: Die kuratierte Wahrheit
Ein Data Warehouse ist die zentrale, aufbereitete Datenbasis fürs Unternehmen. Daten aus operativen Systemen (ERP, CRM, Shop) werden per ETL/ELT-Prozess bereinigt, vereinheitlicht und in ein festes Schema geladen – Schema-on-Write: Die Struktur steht fest, bevor die Daten hineinkommen.
Die Stärken:
- Verlässliche Kennzahlen: Eine Zahl, eine Wahrheit – Umsatz bedeutet überall dasselbe
- SQL-Performance: Spaltenorientierte Speicherung und Optimierung für analytische Abfragen
- BI-Integration: Reporting-Tools docken direkt an
- Governance: Zugriffsrechte, Historisierung und Nachvollziehbarkeit sind eingebaut oder etabliert
Die Schwächen: Das feste Schema macht träge – neue Datenquellen erfordern Modellierungsarbeit, bevor sie nutzbar sind. Unstrukturierte Daten (Texte, Bilder, Logs) passen konzeptionell nicht hinein. Und pro Terabyte ist ein Warehouse deutlich teurer als einfacher Objektspeicher, weil Speicher und Rechenleistung auf schnelle Abfragen optimiert sind.
Data Lake: Das Rohdaten-Reservoir
Ein Data Lake ist im Kern günstiger Objektspeicher (etwa S3-kompatible Systeme), in den Daten im Originalformat fließen: CSV-Exporte, JSON-Events, Parquet-Dateien, Bilder, Audiodateien, Server-Logs. Die Interpretation passiert erst bei der Nutzung – Schema-on-Read: Wer die Daten liest, legt fest, wie sie strukturiert werden.
Die Stärken:
- Alle Formate: Strukturiert, semi-strukturiert, unstrukturiert – alles hat Platz
- Günstig: Objektspeicher kostet einen Bruchteil von Warehouse-Speicher
- Zukunftsoffen: Daten werden gesammelt, bevor klar ist, wofür sie gebraucht werden
- ML-tauglich: Data Scientists greifen direkt auf Rohdaten zu – ideal für Feature Engineering und Modelltraining
Die Schwächen: Freiheit ohne Disziplin endet im Data Swamp – einem Sumpf aus undokumentierten, veralteten, unauffindbaren Dateien. Ohne Datenkatalog, Qualitätsregeln und klare Zuständigkeiten verliert der Lake schnell seinen Wert. Auch Abfrage-Performance und Zugriffskontrolle sind nicht automatisch da, sondern müssen über zusätzliche Engines und Governance-Schichten nachgerüstet werden.
In der Praxis strukturieren Teams ihren Lake deshalb in Zonen: eine Raw-Zone für unveränderte Originaldaten, eine bereinigte Zone für validierte und vereinheitlichte Daten und eine kuratierte Zone für konsumfertige Datensätze. Dieses Schichtenmodell – oft Medallion-Architektur genannt – bringt Ordnung, ohne die Flexibilität des Lakes aufzugeben.
Die KI-Perspektive
Für Machine Learning ist der Data Lake die natürliche Heimat. Trainingsdaten sind fast immer Rohdaten: Texte für Sprachmodelle, Bilder für Computer Vision, Clickstreams für Empfehlungssysteme. Ein Warehouse kennt solche Daten nicht – es speichert aggregierte, tabellarische Sichten. Auch moderne KI-Anwendungsmuster wie RAG (Retrieval-Augmented Generation) schöpfen aus Dokumentenbeständen, die typischerweise im Lake liegen, bevor sie in Vektordatenbanken indexiert werden.
Das Warehouse spielt im KI-Kontext eine andere Rolle: Es liefert die kuratierten, verlässlichen Features – Kundenumsätze, Bestellhistorien, Stammdaten – und ist der Ort, an dem Modell-Ergebnisse (Scores, Prognosen) fürs Business-Reporting landen. Ein typischer Kreislauf sieht so aus: Rohdaten landen im Lake, werden dort für das Modelltraining aufbereitet, und die Vorhersagen fließen zurück ins Warehouse, wo Fachbereiche sie neben den klassischen Kennzahlen auswerten.
Wann was?
Nimm ein Data Warehouse, wenn:
- BI und Reporting im Vordergrund stehen
- Du konsistente, geprüfte Kennzahlen für Management und Fachbereiche brauchst
- Deine Daten überwiegend strukturiert sind
- Viele Nutzer per SQL und BI-Tools zugreifen
Nimm einen Data Lake, wenn:
- Du Rohdaten aller Formate sammeln willst
- Machine Learning und Data Science zentrale Anwendungsfälle sind
- Speicherkosten bei großen Volumina entscheidend sind
- Die künftige Nutzung der Daten noch offen ist
Die Entscheidung ist selten exklusiv: Wer beides braucht, lässt Rohdaten in den Lake fließen und lädt kuratierte Ausschnitte ins Warehouse – der Lake als Quelle, das Warehouse als veredelte Sicht für das Business.
Konvergenz: Das Lakehouse
Die Trennung weicht auf. Lakehouse-Architekturen legen Warehouse-Fähigkeiten – ACID-Transaktionen, Schema-Verwaltung, schnelle SQL-Abfragen – direkt auf den günstigen Objektspeicher des Lakes. Möglich machen das offene Tabellenformate wie Delta Lake, Apache Iceberg und Apache Hudi. Der Effekt: BI-Analysten und ML-Teams arbeiten auf denselben Daten, ohne Kopien zwischen zwei Systemen zu synchronisieren. Für viele Neueinsteiger ist das Lakehouse heute der Default; wer bereits ein etabliertes Warehouse betreibt, ergänzt es meist pragmatisch um einen Lake für Rohdaten und ML – die Architektur folgt dem Bedarf, nicht umgekehrt.