Was ist ein Data Lake?

Der Begriff Data Lake geht auf einen Blogbeitrag von James Dixon, damals Chief Technology Officer bei Pentaho, vom 14. Oktober 2010 zurück. Dixon stellte dem Data Mart — aufbereitet, gefiltert, für eine einzelne Frage vorgeformt — den See gegenüber: ein großer Wasserkörper im natürlichen Zustand, aus dem sich jeder das nimmt, was er braucht, statt vorab in Flaschen abgefüllt zu bekommen.

Technisch beschreibt ein Data Lake einen zentralen Speicher, der Daten in ihrem Ursprungsformat hält — Tabellen, Bilder, Protokolldateien, Freitext, Zeitreihen nebeneinander, unabhängig von der Quelle. Der Speicherort selbst ist meist ein Objektspeicher: güns­tig, praktisch unbegrenzt skalierbar, ohne die Struktur eines klassischen Dateisystems.

Der Unterschied zum Data Warehouse liegt am Zeitpunkt der Strukturierung: Ein Warehouse verlangt ein festes Schema, bevor Daten hineinkommen (Schema-on-Write) — jede neue Datenquelle ist ein Modellierungsprojekt. Ein Data Lake nimmt Daten roh auf und legt das Schema erst beim Lesen an (Schema-on-Read) — die Frage, die eine Anwendung stellt, entscheidet über die Struktur, nicht ein Projekt Monate vorher.

In einem Produktionsunternehmen laufen Daten zusammen, die keinem gemeinsamen Schema folgen: Zeitreihen aus der Steuerung, Prüfbilder aus der optischen Qualitätskontrolle, PDF-Zertifikate von Lieferanten, Stammdaten aus dem ERP, Freitext aus Störungsmeldungen. Ein Data Warehouse verlangt für jede dieser Quellen ein Modell, bevor der erste Datensatz ankommt — bei fünf Quellen fünf Modellierungsprojekte, von denen keines beginnen kann, solange nicht feststeht, wofür die Daten später gebraucht werden.

Ein Data Lake kehrt die Reihenfolge um: Die Daten kommen roh und vollständig herein, die Frage nach ihrer Struktur wird verschoben, bis eine Anwendung sie tatsächlich stellt. Das kostet nichts an Objektspeicher — der ist güns­tig genug, um auch Daten zu halten, für die es noch keinen Anwendungsfall gibt — und es verhindert, dass ein Modellierungsprojekt zur Voraussetzung für den ersten Blick in die Daten wird.

Damit ergänzt der Data Lake ein Ordnungsprinzip wie den Unified Namespace: Ein Namensraum hält den aktuellen Stand jeder Quelle, ohne Verlauf. Historische Werte, die er nicht vorhält, brauchen einen Ort zum Absetzen — genau das ist die Aufgabe des Data Lake.

Ein Data Lake schreibt keine Struktur vor — genau das macht ein völlig unstrukturiertes Ablegen so verlockend und so riskant zugleich. In der Praxis hat sich deshalb ein Schichtmodell durchgesetzt, das Rohdaten in mehreren Stufen zu nutzbaren Daten macht, ohne das Original zu verlieren. Am weitesten verbreitet ist die Medaillon-Architektur mit den Stufen Bronze, Silver und Gold — die Bezeichnungen stammen aus der Dokumentation von Databricks, sind aber inzwischen herstellerübergreifend gebräuchlich.

Der Vorteil liegt darin, dass jede Zone unabhängig neu berechnet werden kann, solange die Rohzone unverändert bleibt. Stellt sich später heraus, dass eine Bereinigungsregel falsch war, wird nicht neu erhoben, sondern aus der Bronze-Zone neu abgeleitet.

Innerhalb jeder Zone brauchen Dateien einen Platz, der sich ohne Suchen wiederfindet. Bewährt hat sich eine Ordnung nach Quelle, Werksstruktur und Zeit — wer bereits einen Unified Namespace betreibt, erkennt das Muster wieder: auch hier zahlt sich eine einmal beschlossene, am Werk orientierte Benennung aus, angelehnt an dieselbe Gliederung nach ISA-95 / IEC 62264-1 (Enterprise, Site, Area, Work Center).

Ein Pfad in der Rohzone könnte so aussehen:

bronze/werk-nord/halle-2/linie-3/abfueller/2026-09-24/sensordaten.parquet

Und nach der Bereinigung in der Silver-Zone, thematisch statt technisch partitioniert:

silver/produktion/temperatur/jahr=2026/monat=09/

Drei Regeln haben sich bewährt: Partitionierung nach dem Merkmal, nach dem später am häufigsten gefiltert wird (meist Zeit); ein Dateiname, der die Herkunft erkennen lässt, ohne dass eine Anwendung ihn parsen muss; und ein Metadatenkatalog, der diese Struktur dokumentiert — ohne ihn ist die schönste Ordnung nur so lange bekannt, wie die Person da ist, die sie angelegt hat.

Drei Schichten tragen einen Data Lake in der Praxis:

• Objektspeicher als Fundament: S3-kompatible Speichersysteme legen Dateien flach ab, ohne die Größenbeschränkungen und die Verwaltung eines klassischen Dateiservers.
• Apache Parquet als Dateiformat: ein spaltenorientiertes Format der Apache Software Foundation, das nur die tatsächlich gebrauchten Spalten liest statt ganzer Zeilen. Eine Tabelle mit 200 Spalten, aus denen eine Auswertung zehn braucht, liest damit ein Zwanzigstel der Daten — nicht das Zwanzigfache, wie es ein zeilenorientiertes Format tun würde.
• Offene Tabellenformate wie Apache Iceberg, Delta Lake oder Apache Hudi legen sich über Parquet-Dateien und bringen, was reiner Objektspeicher nicht kann: Schema-Änderungen ohne Neuschreiben aller Daten, Zeitreisen zu einem früheren Stand, und Transaktionssicherheit bei gleichzeitigen Schreibvorgängen. Ein Data Lake, der auf einem dieser Formate aufsetzt, wird in der Fachliteratur oft Lakehouse genannt — ein Data Lake mit den Transaktionsgarantien eines Data Warehouse.

Keine dieser Komponenten macht aus einem Datenordner einen Data Lake. Das tut erst der Metadatenkatalog: ein Verzeichnis, das zu jeder Tabelle und Datei festhält, woher sie stammt, welches Schema sie hat, wer sie pflegt und wie aktuell sie ist. Ohne Katalog lässt sich nicht unterscheiden, ob ein Ordner leer ist, weil es keine Daten gibt, oder weil niemand mehr weiß, dass es sie gibt.

1. Zonen und Zuständigkeiten festlegen

   Bronze, Silver, Gold — oder eine eigene Variante davon — werden benannt, und für jede Zone steht fest, wer sie verantwortet. Das ist die Entscheidung, die später am teuersten zu ändern ist.

2. Rohdaten anbinden

   Quellen veröffentlichen unverändert in die Bronze-Zone — ohne Transformation, ohne Vorabauswahl. Was nicht ankommt, kann später nicht neu abgeleitet werden.

3. Bereinigen und katalogisieren

   Duplikate, fehlerhafte Werte und uneinheitliche Formate werden in der Silver-Zone korrigiert, jede Tabelle im Metadatenkatalog eingetragen.

4. Für Anwendungen veredeln

   Aus der Silver-Zone entstehen Gold-Tabellen für einen konkreten Zweck — ein Bericht, ein Dashboard, ein Trainingsdatensatz. Ein neuer Anwendungsfall bekommt eine neue Gold-Tabelle, keinen neuen Export aus der Quelle.

• Kein Data Warehouse. Er ersetzt keine Standardberichte mit fester Struktur — dafür bleibt ein Warehouse oder eine Gold-Zone mit Warehouse-Charakter die bessere Wahl.
• Kein Ersatz für Echtzeitsysteme. Ein Data Lake liest historische Bestände, keine Millisekunden-Reaktion auf eine Anlage. Dafür bleiben Steuerung, MES und ein Namensraum wie der Unified Namespace zuständig.
• Kein Selbstläufer. Ohne Zonen, Katalog und Zuständigkeit entsteht kein Data Lake, sondern ein Ordner, in den alles hineinfließt und aus dem nichts mehr herausfindet.
• Kein Produkt. Es gibt keine Software, deren Installation einen Data Lake erzeugt — nur Software, die eine Zonenstruktur und einen Katalog gut oder schlecht trägt.

Bereits 2014 warnte das Analystenhaus Gartner in einer Pressemitteilung vor der „Data Lake Fallacy“ — der Annahme, ein Speicher allein schaffe schon Nutzen. Ohne Governance wird aus dem Data Lake ein Data Swamp: ein Speicher, in dem Daten liegen, aber niemand mehr weiß, welche vertrauenswürdig, aktuell oder überhaupt noch in Gebrauch sind. Die Warnung ist über zehn Jahre alt und in der Praxis noch immer die häufigste Ursache für gescheiterte Data-Lake-Vorhaben.

• Katalog fehlt oder veraltet. Tabellen ohne Eintrag sind schneller angelegt als gepflegt — und nach einem Jahr niemandem mehr zuzuordnen.
• Rohzone wird direkt angefragt. Wer Fachanwendungen auf die Bronze-Zone statt auf Silver oder Gold zugreifen lässt, verteilt Bereinigungslogik über jede einzelne Anwendung neu.
• Kein Lifecycle. Ohne Regeln, wann Rohdaten archiviert oder gelöscht werden, wächst der Speicher unbegrenzt — und mit ihm die Unübersichtlichkeit.
• Ungeklärte Zuständigkeit. Eine Zone ohne Verantwortlichen wird nicht betrieben, sondern nur repariert, wenn etwas auffällt.

pronubes ist die Plattform zwischen Shopfloor und IT. Sie erfasst Produktionsdaten sicher, normalisiert sie und führt sie in eine gemeinsame Struktur — und bringt Entscheidungen als Vorgaben zurück in die Prozesse.

• pronubes Edge sammelt Rohdaten an der Quelle ein, puffert bei Verbindungsverlust und veröffentlicht unverändert in die Rohzone.
• pronubes Zones bildet die Zonen- und Werksstruktur ab — dieselbe Benennung, die auch der Unified Namespace nutzt, wird gepflegt statt in Dokumenten verstreut.
• pronubes Insights macht Katalog und Datenqualität sichtbar: welche Tabelle wie aktuell ist und wo die Bereinigung noch aussteht.

Der Data Lake bleibt damit kein Ordner, sondern ein betriebener Bestandteil der Landschaft. Mehr zur Plattform