Data Lake Architektur: Aufbau, Governance und die häufigsten Fehler

Ein Data Lake ist kein Datengrab. In der Praxis wird er trotzdem häufig zu einem: schlecht strukturiert, ohne Governance, mit Daten, die niemand mehr versteht oder findet. Dieser Artikel erklärt, was eine tragfähige Data-Lake-Architektur auszeichnet, wann sie sinnvoll ist, und welche Fehler vermieden werden müssen.

Was ein Data Lake ist und was nicht

Ein Data Lake ist ein zentrales Speicherrepository, das strukturierte, semi-strukturierte und unstrukturierte Rohdaten in beliebigem Format aufnimmt. Daten werden ohne vorherige Transformation gespeichert, das heißt Schema und Semantik werden zum Lesezeitpunkt aufgelöst (Schema-on-Read).

Das unterscheidet ihn grundlegend vom klassischen Data Warehouse:

• Data Warehouse: Schema-on-Write, relationale Struktur, optimiert für SQL-Abfragen und Reporting. Daten werden beim Laden bereinigt, transformiert und modelliert.
• Data Lake: Schema-on-Read, heterogene Formate (JSON, Parquet, CSV, Avro, Bilder, Logs), optimiert für Exploration, Machine Learning und Batch-Verarbeitung.

Ein Data Lake ist kein Ersatz für ein Data Warehouse. Er ist ein anderes Werkzeug für andere Anforderungen. Wer das nicht versteht, baut beides falsch.

Wann ein Data Lake sinnvoll ist

Ein Data Lake rechtfertigt sich, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Das Datenvolumen übersteigt das, was in einem strukturierten Warehouse wirtschaftlich gespeichert werden kann (Logs, Sensordaten, Klickstreams, Dokumente).
• Die Anforderungen sind noch nicht klar definiert: Datenwissenschaftler müssen Rohdaten explorieren, bevor ein konkretes Modell oder ein Reporting-Anwendungsfall feststeht.
• Machine-Learning-Pipelines benötigen unbearbeitete Historien für Training und Feature Engineering.
• Daten aus heterogenen Quellen sollen ohne aufwendige ETL-Vorabtransformation landingfähig sein.

Wenn keine dieser Bedingungen zutrifft und das Unternehmen primär strukturiertes Reporting und Ad-hoc-SQL benötigt, ist ein Data Warehouse die richtige Wahl.

Das Lakehouse: ein pragmatisches Mittelmodell

In vielen Projekten hat sich das Lakehouse-Muster als praktikable Alternative etabliert. Es kombiniert die Speicherflexibilität eines Data Lake mit transaktionaler Konsistenz und SQL-fähigen Schichten darüber. Technologisch umgesetzt durch Frameworks wie Apache Iceberg, Delta Lake oder Apache Hudi auf einem Object-Store (S3, Azure Data Lake Storage, GCS).

Das Lakehouse ist kein Hype-Begriff, sondern eine architektonische Entscheidung: Es macht Sinn, wenn ein Unternehmen beides braucht, strukturiertes Reporting und Rohdatenverarbeitung, aber die Infrastruktur konsolidieren will. Die Tradeoffs sind real: mehr Komplexität in der Verwaltung, höhere Anforderungen an das Datenbankteam.

Referenzarchitektur: die Zonen eines Data Lake

Eine produktionstaugliche Data-Lake-Architektur ist in Zonen gegliedert. Die gängige Struktur:

Landing Zone (Raw Zone) Rohdaten landen hier ohne Transformation, exakt so wie sie von der Quelle geliefert werden. Diese Zone ist append-only und unveränderlich. Für Audits und Fehleranalysen ist die Möglichkeit, auf die exakten Quelldaten zurückgreifen zu können, unverzichtbar.

Cleansed Zone (Curated Zone) Daten wurden hier bereinigt: Schema-Normalisierung, Deduplizierung, Encoding-Probleme behoben, offensichtliche Qualitätsprobleme gefiltert. Format typischerweise Parquet oder Avro, partitioniert nach Datum oder Quellsystem.

Enriched Zone (Conformed Zone) Daten aus verschiedenen Quellen werden hier verknüpft, angereichert und in ein einheitliches semantisches Modell überführt. Dieser Layer bildet die Grundlage für Analytics und ML.

Serving Zone Aggregierte, anwendungsfallspezifische Datensätze für Dashboards, APIs und ML-Inferenz. Oft ein Data Mart oder ein Feature Store.

Die Ingestion erfolgt über Batch- oder Streaming-Pipelines (Apache Kafka, Apache Flink, AWS Kinesis oder vergleichbare Werkzeuge). Ein Data Catalog (AWS Glue, Apache Atlas, Collibra) ist kein optionales Add-on, sondern eine strukturelle Voraussetzung dafür, dass Nutzer Daten überhaupt finden.

Governance: die unterschätzte Voraussetzung

Die häufigste Ursache dafür, dass ein Data Lake zum Data Swamp wird, ist nicht die falsche Technologie. Es ist fehlende Governance.

Konkret bedeutet das:

• Kein Data Catalog: Niemand weiß, was im Lake liegt, wer es angelegt hat, und was es bedeutet. Daten werden redundant abgelegt oder finden keine Abnehmer.
• Kein Ownership-Modell: Jedes Team schreibt in den Lake, niemand ist verantwortlich für Qualität. Die Raw Zone füllt sich mit nicht-verwertbaren Fragmenten.
• Kein Zugriffskonzept: Alle sehen alles, oder niemand kommt an relevante Daten heran. Beides blockiert die Nutzung.
• Keine Datenlinienverfolgung (Data Lineage): Wenn ein ML-Modell falsche Vorhersagen liefert, kann niemand nachvollziehen, welche Quelldaten das Training beeinflusst haben.

Governance ist kein Bürokratieprojekt. Es ist das, was den Lake von einer Ablagesammlung zu einem verlässlichen Asset unterscheidet.

DSGVO und Datenschutz in der Architektur

Im DACH-Kontext kommt ein regulatorischer Layer hinzu, den man architektonisch von Anfang an einplanen muss, nicht nachrüsten.

Kritische Punkte:

• Personenbezogene Daten gehören nicht unverschlüsselt in die Raw Zone. Entweder wird direkt beim Ingest pseudonymisiert oder verschlüsselt, oder personenbezogene Daten werden in einer separierten Zone mit strengerer Zugriffskontrolle gehalten.
• Recht auf Löschung (Art. 17 DSGVO): In einem append-only Lake ist das nicht trivial. Lösungen sind kryptografisches Shredding (den Schlüssel verwerfen), oder ein Architekturmuster, das personenbezogene Attribute in einer separierten, löschbaren Lookup-Tabelle hält.
• Datenresidenz: Die meisten DSGVO-konformen Deployments im DACH-Raum setzen auf europäische Cloud-Regionen (Frankfurt, Amsterdam, Zürich). Die Wahl der Region muss in den Architekturentscheid eingeflossen sein, nicht als Nachgedanke.
• Verarbeitungsverzeichnis: Jeder Datenfluss in den Lake muss im Verarbeitungsverzeichnis abgebildet sein. Ein Data Catalog hilft dabei, ist aber kein Ersatz dafür.

Typische Fehler, die den Lake zum Swamp machen

Aus der Praxis: die Muster, die immer wieder scheitern.

1. Alles rein, nichts raus. Ingestion ist kein Problem, Nutzung schon. Wenn keine Serving-Layer und keine klaren Anwendungsfälle definiert sind, landen Daten im Lake und bleiben dort.

2. Fehlende Schema-Versionierung. Quellsysteme ändern ihr Schema. Wenn niemand diese Änderungen trackt und der Downstream-Konsument davon überrascht wird, bricht die Pipeline.

3. Kein Monitoring der Datenqualität. Stille Fehler akkumulieren sich über Monate. Wenn ein ML-Modell trainiert wird, sind die Trainingsdaten bereits korrumpiert.

4. Falsches Kostenmodell. Object Storage ist günstig, aber Compute ist es nicht. Unkontrollierte Ad-hoc-Abfragen auf schlecht partitionierten Rohdaten (etwa mit Amazon Athena oder BigQuery) können die monatlichen Kosten sprunghaft erhöhen. Partitionierungs- und Clusterstrategie sind keine optionalen Optimierungen.

5. Zu früh zu viel. Ein Lake, der alles können soll (Streaming, Batch, ML, Reporting, Operational Analytics) bevor ein erster Anwendungsfall live ist, wird nie fertig. Inkrementell aufbauen, mit einem klaren Use Case beginnen.

Fazit: was eine tragfähige Data-Lake-Architektur ausmacht

Ein Data Lake ist kein Selbstzweck. Er ist dann sinnvoll, wenn Rohdatenvolumen, Explorationsanforderungen oder ML-Pipelines eine flexible Speicherschicht erfordern, die ein klassisches Warehouse nicht bietet.

Was ihn nutzbar macht: Zonierung, ein Data Catalog vom ersten Tag an, klares Ownership, DSGVO-konforme Datenhaltung und ein inkrementeller Aufbau entlang konkreter Anwendungsfälle. Was ihn zum Swamp macht: Governance als Nachgedanke, unklare Verantwortlichkeiten und die Illusion, dass Speicher allein eine Datenstrategie ist.

Für Unternehmen, die beides brauchen, strukturiertes Reporting und Rohdatenverarbeitung, ist das Lakehouse-Muster heute die pragmatischste Antwort. Für alle anderen gilt: mit der einfachsten Architektur anfangen, die den nächsten konkreten Schritt ermöglicht.

Data-Lake-Architektur besprechen

DNA Solutions berät Unternehmen im DACH-Raum bei der Architektur und dem Aufbau von Data Platforms, von der ersten Zonierungsentscheidung bis zur produktionsfähigen Governance-Struktur. Wenn Sie vor einer Entscheidung zwischen Data Lake, Data Warehouse und Lakehouse stehen, oder einen bestehenden Lake sanieren müssen: Sprechen Sie uns an.