Data Lake: Definition, Architektur, Formate, Abgrenzung

Ein Data Lake ist ein zentraler Datenspeicher, der Rohdaten (Daten in ihrer Ursprungsform, ohne vorherige Umformung) günstig auf sogenannten Objekt-Speichern ablegt: große Cloud-Ablagen wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage. Der Speicher nimmt beliebige Formate an, also Tabellen, halb-formatierte Daten wie JSON und komplett unformatierte Inhalte wie Bilder oder PDFs. Die Struktur der Daten (das Schema, also welche Felder es gibt und wie sie heißen) wird erst beim Lesen festgelegt. Ein klassisches Data Warehouse verlangt dagegen ein festes Tabellen-Schema, in das jede Datei bereits vor dem Ablegen gepresst werden muss.

Was ist ein Data Lake?

Ein Data Lake ist ein zentraler Sammel-Speicher, in dem eine Organisation Rohdaten aus Fachsystemen (ERP, CRM), laufenden Datenströmen, Anwendungen und externen Quellen in ihrer Ursprungsform ablegt. Technisch besteht er aus drei Bausteinen: einem Objekt-Speicher als Ablage-Schicht (das eigentliche Dateilager in der Cloud), offenen Dateiformaten für die gespeicherten Daten (herstellerunabhängige Formate wie Parquet, Avro, JSON) und einem Katalog für die Metadaten (ein Verzeichnis, welche Tabellen es gibt, wo sie liegen und wer sie nutzen darf). Die Rechenarbeit erledigen separate Auswertungs-Werkzeuge wie Apache Spark, Trino, Presto oder Flink, die auf den Speicher über Standard-Zugriffswege zugreifen.

Der Begriff stammt von James Dixon, damals technischer Leiter bei Pentaho, der 2010 in einem Blogpost den Data Lake als Gegenmodell zum aggregierten Data Mart beschrieb: Wasser im See ist roh, ungefiltert und in seinem Ursprungszustand; wer eine Flasche abfüllen will, tut das aus dem See, ohne dass der See für diesen Zweck vorstrukturiert werden muss. Technisch fiel die Idee mit dem Aufkommen von Hadoop (HDFS, MapReduce) zusammen und wanderte mit der Cloud-Ära vom lokalen Cluster auf Objekt-Speicher der Hyperscaler.

Der Schema-on-Read-Ansatz ist die zentrale Mechanik. Ein Data Warehouse verlangt, dass die Struktur der Daten vor dem Schreiben feststeht (Schema-on-Write); Änderungen am Quell-System ziehen Modell- und ETL-Änderungen nach sich. Ein Data Lake nimmt Daten so an, wie sie kommen, und interpretiert das Schema erst beim Lesen. Damit entkoppeln sich Ingest-Geschwindigkeit und analytisches Modell: neue Quellen landen ohne Modellierungs-Vorlauf im Lake, das analytische Modell entsteht bei Bedarf in nachgelagerten Verarbeitungs-Schritten.

Die Speicher-Ökonomie ist der zweite Treiber. Objekt-Speicher kostet pro Terabyte einen Bruchteil dessen, was On-Premises-Warehouse-Storage oder Cloud-Warehouse-Storage kosten, und ist elastisch: Speicher- und Compute-Ressourcen skalieren getrennt. Ein Data Lake speichert damit Datenmengen, deren Aufbewahrung im Warehouse-Modell zu teuer wäre (etwa mehrjährige Log-Historien, IoT-Telemetrie, Klickstrom-Ereignisse oder Rohdaten für ML-Training). Ohne begleitende Governance, Katalog- und Qualitäts-Prozesse verkommt der Lake zum Data Swamp: dieselbe Technik, aber ohne Auffindbarkeit und Vertrauen.

Abgrenzung zu Data Warehouse, Data Lakehouse und Data Swamp

Der Begriff Data Lake wird in Praxis-Diskussionen häufig mit verwandten Konzepten vermischt, die entweder eine andere Speicher-Philosophie beschreiben oder denselben Lake in einer anderen Betriebsreife bezeichnen.

Begriff	Achse	Kernunterschied
Data Warehouse	Speicher-Philosophie	Ein Warehouse ist eine relationale Analyse-Datenbank mit festem Schema (Schema-on-Write), auf strukturierte Geschäftsdaten optimiert. Der Data Lake speichert roh und formatoffen, das Schema entsteht beim Lesen.
Data Lakehouse	Weiterentwicklung	Ein Lakehouse fügt der Lake-Speicherung transaktionale Tabellenformate (Delta Lake, Apache Iceberg, Apache Hudi) und einen Katalog hinzu und liefert damit ACID, Schema-Enforcement und Time Travel. Der Lake bleibt die Speicher-Schicht darunter.
Data Swamp	Betriebsreife	Ein Data Swamp ist ein Data Lake ohne Katalog, Datenqualität und Governance. Technisch identisch, praktisch unbrauchbar, weil Daten nicht mehr auffindbar oder vertrauenswürdig sind.
Data Mart	Zweck	Ein Data Mart ist ein zweckgebundener, aggregierter Datenausschnitt für eine Fachdomäne (Sales, Finance). Der Data Lake ist der ungefilterte Rohbestand, aus dem Marts abgeleitet werden.
Object Storage	Ebene	Objekt-Speicher (S3, ADLS, GCS) ist die reine Storage-Technik. Ein Data Lake ist die analytische Nutzungs-Schicht darüber mit Katalog, Formaten und Zugriffs-Konventionen.

Die wichtigste Abgrenzung verläuft zwischen Data Lake und Data Warehouse. Beide sind Speicher-Architekturen für Analyse-Daten, unterscheiden sich aber grundlegend in der Modellierungs-Philosophie. Ein Warehouse zwingt die Modellierung an den Anfang der Pipeline (Ingest gegen ein definiertes Schema), ein Lake verschiebt sie ans Ende (Modellierung beim Lesen oder in Downstream-Layern). Beide Ansätze haben eigene Trade-offs: Warehouse-Governance ist stärker, Lake-Flexibilität ist höher. Moderne Lakehouse-Plattformen führen beide Welten in einer Speicher-Schicht zusammen.

Die zweite häufige Verwechslung betrifft Data Lake und Data Lakehouse. Ein Lakehouse ist kein separater Speicher, sondern eine Erweiterung des Lakes um transaktionale Tabellenformate und Katalog-Integration. Die zugrundeliegenden Parquet-Dateien liegen weiterhin auf S3, ADLS oder GCS; hinzu kommen Delta- oder Iceberg-Metadaten und ein Katalog wie Unity Catalog oder Polaris. Der Lake ist damit weiterhin die Speicher-Schicht, das Lakehouse die logische Schicht darüber.

Beispiel: Data Lake in einer Handels-Datenplattform

Ein Handelsunternehmen betreibt seinen Data Lake auf Amazon S3 und persistiert dort drei Datenklassen parallel. Change-Data-Capture-Streams aus dem ERP landen als Avro-Events auf Kafka und werden von einem Structured-Streaming-Job als Parquet-Dateien in eine Bronze-Zone geschrieben. Klickstrom-Ereignisse der Webshops kommen als JSON-Lines direkt aus dem CDN in dieselbe Zone. Produktbilder und PDFs liegen als Binärdaten im S3-Bucket, unverändert übernommen aus den Quellsystemen.

Der Zugriff läuft über eine Compute-Trennung: Data-Engineering-Jobs auf Apache Spark verarbeiten die Bronze-Zone in bereinigte Silver- und aggregierte Gold-Tabellen; BI-Werkzeuge greifen auf die Gold-Ebene zu; ML-Teams lesen für Feature-Engineering direkt aus Bronze oder Silver. Ein Katalog verwaltet Tabellen-Metadaten, Berechtigungen, Lineage und Datenqualitäts-Signale plattform-übergreifend. Erst der Katalog macht die Rohdaten auffindbar und verwaltbar; ohne ihn wäre die Umgebung ein Swamp mit identischem Storage-Footprint, aber ohne Betriebs-Reife.

Diese Architektur ist der typische heutige Data-Lake-Einsatz. Sie kombiniert offene Formate (Parquet, Avro), Objekt-Speicher als Fundament, eine verteilte Engine für Verarbeitung und einen Katalog für Governance. Wird die Bronze-Zone auf Delta Lake oder Apache Iceberg umgestellt, wandert die Architektur ohne Storage-Migration in ein Data Lakehouse; die Dateien bleiben, ergänzt um Transaktions-Logs und Katalog-Integration.