Data Lake: Speicher-Fundament mit einer Lücke, die zum Swamp führt
Die Kernaussagen auf einen Blick.
- Ein Data Lake ist ein zentraler Objektspeicher, der strukturierte, semi- und unstrukturierte Rohdaten in offenen Dateiformaten günstig und nahezu unbegrenzt skalierbar ablegt.
- Er löst das Speicherproblem, benötigt für Transaktionssicherheit, verbindliche Schemas und Governance jedoch zusätzliche Komponenten.
- Vor dem produktiven Einsatz sollten drei Punkte geregelt sein: verlässliche Schreibvorgänge, Lösch- und Korrekturfähigkeit für die DSGVO und ein Katalog mit klaren Zugriffsregeln.
- Empfehlenswert ist, den bestehenden Data Lake mit einem offenen Tabellenformat wie Delta Lake oder Apache Iceberg schrittweise zu einer Lakehouse-Architektur weiterzuentwickeln und die vorhandene Speicherinfrastruktur dabei weiterzuverwenden.
Inhaltsverzeichnis
Der Data Lake enthält alle Daten, wird aber nicht für das Reporting genutzt
Ein Unternehmen befüllt drei Jahre lang einen Data Lake auf Azure Data Lake Storage: Exporte aus den Quellsystemen, Klickdaten, Maschinen-Logs, Sensordaten. Die Speicherkosten bleiben überschaubar und die Ladeprozesse funktionieren. Als das erste Vorstandsreporting auf den Data Lake verlagert werden soll, fehlen jedoch belastbare Nachweise zur Aktualität und Vollständigkeit der Daten. Kurz darauf trifft die erste DSGVO-Löschanfrage ein, und die an sich übliche Anfrage entwickelt sich zu einem aufwendigen technischen Vorhaben, weil einzelne Datensätze über Tausende Dateien verteilt liegen.
Diese Situation tritt in vielen historisch gewachsenen Datenplattformen auf. Der Data Lake erfüllt seine Aufgabe als zentraler Speicher zuverlässig. Probleme entstehen, wenn verbindliches Reporting, Compliance-Prozesse oder produktive Anwendungen direkt auf den Rohdaten aufbauen sollen.
Reicht der Data Lake als analytische Plattform, oder fehlt eine Schicht darüber? Warum nutzt das Reporting die Daten im Lake nicht, obwohl sie dort vollständig gespeichert sind? Wie lassen sich einzelne Datensätze in einem dateibasierten Speicher zuverlässig korrigieren oder löschen? Soll die Plattform wieder stärker auf ein klassisches Warehouse setzen oder den bestehenden Data Lake erweitern?
Ein Data Lake löst das Speicherproblem. Ob daraus eine verlässliche analytische Plattform entsteht, hängt von den darüberliegenden Verwaltungs-, Governance- und Tabellenschichten ab.
Was ist ein Data Lake?
Ein Data Lake ist ein zentraler Speicher für strukturierte, semistrukturierte und unstrukturierte Rohdaten: Tabellen aus Quellsystemen, JSON-Events und Logdateien, Bilder und Sensordaten. Die Daten liegen in offenen Dateiformaten wie Parquet, JSON oder CSV; in modernen Architekturen meist auf Cloud-Objektspeichern wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage. Das Schema wird beim Lesen angewendet (Schema-on-Read): Die Struktur wird erst bei der Verarbeitung oder Auswertung interpretiert und nicht zwingend bereits beim Schreiben geprüft.
Der Begriff Data Lake wurde 2010 von James Dixon geprägt. Er beschreibt den Data Lake als Gegenbild zum vorgefilterten Data Mart: Während ein Data Mart Daten bereinigt und verdichtet wie Wasser in Flaschen, bewahrt der Data Lake Daten möglichst vollständig und in ihrer ursprünglichen Form auf. Ein Data Lake macht damit Daten verfügbar, die ein vorab modelliertes System verwerfen würde, und ermöglicht auch spätere Analysen, deren Anforderungen heute noch nicht bekannt sind. Speicher und Rechenleistung können unabhängig voneinander skaliert werden: Mehrere Werkzeuge lesen denselben Bestand, bezahlt wird beides getrennt.
Eine Data-Lake-Architektur umfasst mehr als den reinen Objektspeicher. Eine produktiv nutzbare Umsetzung benötigt typischerweise vier Bausteine: die Anbindung der Quellsysteme, die die Daten im Batch- oder Streaming-Verfahren bereitstellt, die Speicher-Ebene auf dem Objektspeicher, einen Katalog mit Metadaten, der Herkunft und Bedeutung der Datenbereiche dokumentiert, und die Auswerte-Ebene mit SQL-Engines, Spark oder Notebooks. Die Ladeprozesse folgen dem ELT-Muster: Daten werden zuerst unverändert geladen und erst bei Bedarf aufbereitet. Ein klassisches Warehouse dreht die Reihenfolge um und transformiert vor dem Laden (ETL).
Aus dem Data Lake führen typischerweise zwei parallele Nutzungsrouten: eine direkte Route über Datenaufbereitung und Validierung in Data Science und Machine Learning, und eine BI-Route über ETL in eine Real-Time-Datenbank und Data Marts für Reports und Auswertungen.
Der Objektspeicher allein stellt jedoch noch keine verbindlichen Datenstrukturen oder Transaktionen bereit. Transaktionssicherheit, Schema-Prüfung und Zugriffsregeln müssen durch zusätzliche Plattformkomponenten umgesetzt werden. Wie Speicher, Tabellenformat und Governance zu einer Plattform zusammenwachsen, zeigen wir im Überblick zum Lakehouse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Warum Unternehmen Data Lakes bauen
Die wesentlichen Stärken eines Data Lake liegen in der flexiblen und kostengünstigen Speicherung großer Datenmengen.
Kosten und Skalierung
Objektspeicher ist pro Terabyte deutlich günstiger als der Speicher eines analytischen Datenbanksystems und lässt sich ohne langfristige Kapazitätsplanung erweitern. Neue Datenquellen lassen sich anbinden, auch wenn der Verwendungszweck noch nicht feststeht.
Datenvielfalt für ML und Data Science
Machine-Learning-Modelle brauchen Rohdaten, Verhaltensdaten, Texte, Bilder. Der Data Lake stellt sie zentral bereit: für Sensor- und Maschinendaten, Klickdaten aus Web und Shop oder historische Trainingsbestände.
Offene Formate, entkoppelter Compute
Weil die Daten in offenen Dateiformaten liegen, lesen SQL-Engines, Spark, Notebooks und Streaming-Werkzeuge denselben Bestand. Das reduziert die Abhängigkeit von einer einzelnen Engine oder Plattform.
Historisch entwickelte sich das Data-Lake-Konzept aus Hadoop-basierten Architekturen: verteilte Dateisysteme (HDFS) im eigenen Rechenzentrum, betrieben von eigenen Teams. Mit dem Umzug in die Cloud ist der Betriebsaufwand dieser Cluster weggefallen; die grundlegenden Architekturprinzipien wurden auf Cloud-Objektspeicher übertragen. Wer heute einen Data Lake aufbaut, startet auf S3, ADLS oder GCS.
Wann wird ein Data Lake zum Data Swamp?
Von einem Data Swamp spricht man, wenn vorhandene Daten aufgrund fehlender Metadaten, Qualitätssicherung oder Verantwortlichkeiten nicht mehr zuverlässig genutzt werden können. Vier typische Schwachstellen begünstigen diese Entwicklung.
Schreibvorgänge sind nicht transaktional abgesichert
Ein Objektspeicher verwaltet Dateien. ACID-Transaktionen fehlen auf dieser Ebene. Wird ein Ladeprozess unterbrochen, bleiben unvollständige Datenstände zurück; parallele Schreibprozesse führen ohne Koordination zu inkonsistenten Ständen.
Schema wird beim Schreiben nicht durchgesetzt
Schema-on-Read heißt auch: Ein Quellsystem kann seine Struktur ändern, ohne dass es sofort auffällt. Diese schleichende Strukturveränderung (Schema-Drift) ist einer der häufigsten Gründe für Vertrauensverlust in den Lake.
Löschungen erfordern Änderungen an den Rohdateien
Das Recht auf Löschung nach Art. 17 DSGVO verlangt, einzelne personenbezogene Datensätze zu entfernen. In einem rohen Lake heißt das: betroffene Datensätze über Millionen Dateien finden, neu schreiben, alte Stände entsorgen.
Ohne Katalog sind Daten schwer auffindbar
Die Datenmenge wächst häufig schneller als Dokumentation und Verantwortlichkeiten. Daten werden mehrfach gespeichert, weil Bestände nicht auffindbar sind; sensible Daten liegen neben unkritischen, ohne unterschiedenen Zugriff.
Ob ein Lake bereits auf dem Weg zum Swamp ist, zeigen vier Symptome:
- Das Reporting läuft weiter auf einem anderen System, weil dem Lake niemand traut.
- Lösch- und Korrekturanfragen werden als Projekte geplant, mit eigenem Aufwand und Risiko.
- Data-Science-Teams kopieren sich Extrakte heraus und pflegen eigene Stände.
- Aktualität und Vollständigkeit der Daten können nicht zuverlässig nachgewiesen werden.
Treten mehrere dieser Symptome gleichzeitig auf, liegt in der Regel ein grundlegendes Architektur- und Governance-Problem vor. Zusätzliche manuelle Regeln allein reichen dann meist nicht aus. Erforderlich sind technische Komponenten, die Transaktionen, Schemaregeln und Metadaten verbindlich unterstützen.
Was unterscheidet Data Lake, Data Warehouse und Lakehouse?
Die drei Architekturansätze unterscheiden sich darin, wann Daten strukturiert werden und welche Garantien die Plattform bereitstellt.
| Achse | Data Lake | Data Warehouse | Lakehouse |
|---|---|---|---|
| Datentypen | alle, von strukturiert bis unstrukturiert | strukturiert | alle, mit Tabellenstruktur wo nötig |
| Schema-Zeitpunkt | beim Lesen (Schema-on-Read) | vor dem Laden (Schema-on-Write) | beim Schreiben prüfbar, offen erweiterbar |
| Transaktionen | fehlen auf Speicher-Ebene | im System vorhanden | über das Tabellenformat |
| Typische Workloads | Rohdaten-Ablage, Data Science | SQL, BI, Reporting | BI, Data Science, Streaming auf einem Bestand |
| Governance | muss zugebaut werden | reif, auf das System begrenzt | zentral über einen Katalog |
| Kosten-Charakteristik | günstig pro Terabyte | höher, an das System gebunden | Objektspeicher-Preis plus Compute nach Bedarf |
Ein Data Warehouse schafft Verbindlichkeit durch ein vorab definiertes Datenmodell; dafür verlangt es strukturierte Daten. Die Daten sind dabei häufig eng an das jeweilige System oder dessen Speicherformat gebunden. Was diese Modellierungs-Disziplin leistet und wo ihre Grenze als alleinige Plattform liegt, erklären wir im Überblick zum Data Warehouse.
Viele Plattformen betreiben heute beide Systeme nebeneinander: Der Lake dient als Landezone, in der alle Rohdaten ankommen, das Warehouse übernimmt daraus die modellierten Daten für Berichte und Kennzahlen. Dieses Modell ist etabliert, verursacht jedoch zusätzlichen Betriebs- und Abstimmungsaufwand. Daten werden in mehreren Systemen gespeichert, die Lade- und Transformationsprozesse beider Systeme müssen separat betrieben werden, und jede Auswertung hängt davon ab, in welchem der beiden Systeme der passende Datenstand liegt. Ein Data Lakehouse soll diese Workloads auf einem gemeinsamen Datenbestand zusammenführen.
Nach Problemen mit einem unstrukturierten Data Lake wird häufig eine vollständige Rückkehr zum klassischen Warehouse erwogen. Dadurch entstehen jedoch erneut Einschränkungen bei flexiblen und unstrukturierten Daten: Rohdaten für Machine Learning passen wieder schlecht in die Plattform, und jede neue Quelle wartet auf Modellierung. Ursache des Data Swamp ist in der Regel nicht der Objektspeicher selbst, sondern das Fehlen von Metadaten, Transaktionen und Governance. Der offene und skalierbare Speicheransatz kann weiterhin sinnvoll genutzt werden. Wie sich die drei Architekturen Achse für Achse vergleichen lassen, führen wir im Vergleich von Warehouse, Lake und Lakehouse aus.
Wie wird aus dem Data Lake ein Lakehouse?
Die beschriebenen Probleme haben eine gemeinsame technische Ursache: Dem reinen Objektspeicher fehlt eine verwaltete Tabellen- und Transaktionsschicht für Schreibvorgänge, Schema und Historie. Genau diese Schicht liefern offene Tabellenformate: Sie verwalten Metadaten und Transaktionen über den vorhandenen Parquet-Dateien; dadurch können Dateien als konsistente und verwaltete Tabellen genutzt werden. Delta Lake dokumentiert dafür ACID-Transaktionen auf offenem Objektspeicher; die Apache-Iceberg-Spezifikation beschreibt denselben Ansatz als herstellerneutralen Standard.
Vier Schichten, der bestehende Speicher bleibt die Basis.
Storage und Compute sind im Data Lake bereits da. Tabellenformat und Governance kommen als neue Schichten dazu.
Damit lassen sich Operationen umsetzen, die auf einem reinen Dateispeicher nur schwer zuverlässig möglich sind: Updates und Löschungen auf Datensatz-Ebene, geprüfte Schema-Änderungen und der Zugriff auf frühere Versionen einer Tabelle (Time Travel). Die bestehenden Daten können dabei im Objektspeicher verbleiben. Die vorhandene Speicherinfrastruktur kann weiter genutzt werden, und die offenen Formate halten den Bestand für mehrere Engines lesbar.
Zusätzliche Struktur entsteht durch eine Aufteilung der Daten nach Verarbeitungs- und Qualitätsstufen. Databricks beschreibt dieses Muster als Medaillon-Architektur mit Bronze-, Silber- und Gold-Schicht: Rohdaten bleiben erhalten, bereinigte und modellierte Stände entstehen kontrolliert darüber.
- Wie Transaktionen, Time Travel und Schema-Entwicklung auf dem Objektspeicher arbeiten, zeigen wir im Überblick zu Delta Lake.
- Wann das zweite offene Tabellenformat die passende Wahl ist, klären wir im Überblick zu Apache Iceberg.
- Wie aus Rohdaten über Bronze, Silber und Gold eine verlässliche Serving-Schicht entsteht, führen wir in der Medaillon-Architektur aus.
In der Praxis sollte die Erweiterung zunächst an einem klar abgegrenzten und geschäftlich relevanten Datenbereich erprobt werden: Tabellenformat einführen, Zugriff über einen Katalog regeln, dann die Schichtung aufbauen. Nach erfolgreicher Validierung kann das Vorgehen schrittweise auf weitere Datenbereiche übertragen werden.
Grenzen
Ein Data Lake bietet weiterhin eine kostengünstige und flexible Grundlage für große und vielfältige Datenbestände. Mit einer zusätzlichen Tabellen- und Governance-Schicht kann er auch produktive analytische Workloads unterstützen. Einige Erwartungen erfüllt er trotzdem nicht, auch im ausgebauten Zustand.
Ein offenes Tabellenformat ersetzt keine fachliche Datenmodellierung. Delta Lake oder Iceberg machen Schreibvorgänge verlässlich. Einheitliche Kennzahlendefinitionen müssen weiterhin fachlich modelliert und abgestimmt werden.
Governance erfordert einen zentralen Katalog sowie klar definierte Verantwortlichkeiten. Zugriffsregeln, Lineage und Ownership entstehen organisatorisch. Das Tabellenformat stellt lediglich einen Teil der technischen Grundlage bereit; wer welche Daten verantwortet und freigibt, muss entschieden und gepflegt werden. Dazu gehören auch die technischen Schutzmaßnahmen: Verschlüsselung, rollenbasierte Zugriffsrechte je Datenbereich und das Maskieren personenbezogener Daten, bevor sie im Lake landen.
Datenqualität muss in den Lade- und Transformationsprozessen geprüft und verbessert werden. Ein Data Lake kann fehlerhafte Daten ebenso zuverlässig speichern wie korrekte Daten. Prüfregeln, Bereinigung und Überwachung gehören in die Pipelines; ohne Qualitätsregeln verlagern sich die Probleme lediglich in die aufbereiteten Datenschichten.
Für transaktionale Anwendungen mit kurzen Antwortzeiten ist ein Data Lake nicht vorgesehen. Einzelne Transaktionen, etwa Bestellungen oder Buchungen, gehören in operative Datenbanken. Der Lake bedient analytische Lasten.
Niedrige Speicherkosten führen nicht automatisch zu niedrigen Gesamtkosten. Ohne Lebenszyklus-Regeln wächst der Bestand unbegrenzt, und Abfragen über viele kleine, unkomprimierte Dateien treiben die Compute-Kosten. Datenlebenszyklen, Dateiverdichtung und Bereinigung müssen als regelmäßige Betriebsaufgaben eingeplant werden.
Diese Grenzen sprechen für eine klare Rollenteilung: Der Data Lake stellt die zentrale Speicherschicht bereit, zusätzliche Plattformschichten übernehmen Transaktionen, Qualitätssicherung, Governance und Zugriffskontrolle. Wer beides zusammen plant, bekommt eine Plattform, die BI, Data Science und Streaming auf einem Datenbestand bedient.
Sobald verbindliche Berichte, Compliance-Anforderungen oder produktive Modelle auf dem Lake laufen sollen, gehört der Ausbau zur Management-Schicht auf die Roadmap. Je größer der unstrukturierte Bestand wird, desto aufwendiger wird eine nachträgliche Einführung von Metadaten, Governance und Tabellenstrukturen.
Fazit
Aus einem Data Lake wird eine verlässliche Datenplattform, wenn Transaktionen, Schemaregeln, Metadaten und Zugriffskontrollen ergänzt werden.
Ein Data Lake ist besonders sinnvoll, wenn neben strukturierten Daten auch Logs, Events, Texte, Bilder oder andere flexible Datenformen verarbeitet werden sollen und Machine Learning, Data Science oder Streaming Rohdaten brauchen. Besonders relevant ist diese Bewertung für Unternehmen, die bereits einen Lake auf S3, ADLS oder GCS betreiben und entscheiden müssen, was daraus wird.
Typische Ausgangslagen, in denen die Entscheidung ansteht:
- ein vorhandener Data Lake, der aufgrund unklarer Qualität oder Aktualität nicht als Reporting-Grundlage genutzt wird
- Lösch- und Korrekturanfragen, die regelmäßig umfangreiche manuelle Arbeiten erfordern
- Data-Science-Teams, die sich Extrakte kopieren und eigene Datenstände pflegen
- eine anstehende Plattform-Entscheidung zwischen Warehouse-Ausbau und offener Architektur
Besteht das Workload-Profil dagegen vollständig aus strukturiertem SQL-Reporting und bleibt das absehbar so, reicht ein gut modelliertes Warehouse als Plattform aus. In diesem Fall kann der Data Lake auf eine klar begrenzte Rolle als Rohdatenablage beschränkt bleiben.
Mein Vorschlag: Die bestehende Entscheidung für offenen Objektspeicher beibehalten und den vorhandenen Lake gezielt ausbauen. Als Pilot eignet sich ein relevanter Datenbereich, der mit einem offenen Tabellenformat und klar geregeltem Katalogzugriff umgesetzt wird. An diesem Pilot lässt sich prüfen, ob sich das Modell fachlich, technisch und betrieblich bewährt, bevor die gesamte Plattform umgebaut wird.
Reicht euer Data Lake als Fundament?
- welche eurer Datenbereiche echte Kandidaten für den Ausbau zum Lakehouse sind
- welche Governance-, Compliance- und Kostenrisiken vor dem nächsten Ausbau geprüft werden müssen
- welcher Architekturpfad eure Speicher-Investition erhält und verlässliche Auswertungen ermöglicht
FAQ
Ein Data Lake ist ein zentraler Speicher, der strukturierte, semi- und unstrukturierte Rohdaten in offenen Dateiformaten wie Parquet oder JSON ablegt, heute meist auf Cloud-Objektspeicher wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage. Das Schema wird erst beim Lesen angewendet (Schema-on-Read), wodurch der Lake günstig skaliert und alle Datentypen aufnimmt.
