Manufacturing Data Lake vs. Data Warehouse: Wo Produktionsdaten eigentlich hingehören

Wichtigste Erkenntnisse

• Data Lake = rohe, schema-on-read Speicherung für beliebige Datentypen. Konzipiert für Breite und Flexibilität.
• Data Warehouse = strukturierte, schema-on-write Speicherung für kuratierte Business-Daten. Konzipiert für Abfrageperformance.
• OEE‑Plattformen verwenden typischerweise eine Zeitreihendatenbank auf der operativen Ebene plus ein Warehouse für Reporting und einen Lake für ML‑Training.
• Lake vs. Warehouse ist die falsche Frage; die richtige Frage ist, wofür jeweils optimiert wird.
• Anlagen, die versuchen, alles in das eine oder das andere zu packen, landen entweder mit langsamen Reports oder teurem Speicher.

Kurzantwort: Ein Data Lake speichert rohe Daten in beliebigen Formaten, das Schema wird beim Lesen angewandt. Ein Data Warehouse speichert kuratierte, strukturierte Daten, das Schema wird beim Schreiben angewandt. Die Fertigung benötigt typischerweise beides: eine Zeitreihendatenbank für operative OEE‑Daten, ein Warehouse für Reporting und einen Lake für ML‑Training und explorative Analysen. Der Versuch, alles in nur einem der beiden zu erledigen, führt zu entweder langsamen Berichten oder teurem Speicher. Siehe auch Audit zur Datenqualität in der Fertigung.

Was ein Data Lake ist

Ein Data Lake ist Massenspeicher für rohe Daten — Sensordatenströme, Logs, Bilder, Video, strukturierte Tabellen, JSON‑Dokumente. Das Schema wird beim Lesen angewandt. Beispiele:

• Cloud‑Objektspeicher: AWS S3, Azure Data Lake Storage, Google Cloud Storage.
• On‑Premises: HDFS, MinIO.

Lakes sind pro TB günstig und flexibel. Sie sind nicht für SQL‑Abfragen auf strukturierten Daten optimiert.

Was ein Data Warehouse ist

Ein Data Warehouse speichert strukturierte Daten, das Schema wird beim Schreiben angewandt. Kuratiert, modelliert, indexiert für Abfrageperformance. Beispiele:

• Cloud: Snowflake, BigQuery, Redshift, Databricks SQL.
• On‑Premises: Teradata, Vertica, Postgres im großen Maßstab.

Warehouses sind für analytisches SQL optimiert. Sie sind pro TB teurer und erfordern Schema‑Disziplin.

Worin sie sich unterscheiden

Die dreischichtige Fertigungsdaten‑Architektur

Die meisten Fertigungsbetriebe benötigen drei Ebenen:

1. Operative Ebene (Zeitreihendatenbank). PLC‑Tags, Sensordaten, Echtzeit‑OEE‑Berechnung. Sub‑sekundäre Latenz. InfluxDB, TimescaleDB, AVEVA PI.

2. Reporting‑Ebene (Data Warehouse). Aggregierte OEE, MTBF, MTTR nach Linie, nach SKU, nach Schicht. BI‑Dashboards. Snowflake, BigQuery, Redshift.

3. Analytics‑Ebene (Data Lake). Rohe Sensordatenströme, Bilder, Video, Kontextdaten. ML‑Training, explorative Analysen. S3, ADLS.

Daten fließen von der operativen Ebene in die Reporting‑Ebene (aggregiert) und von der operativen Ebene in den Lake (roh, zur späteren Verwendung).

Häufige Architekturfehler

1. Eine einzige Ebene für alles. Zeitreihendatenbanken tun sich als Warehouses schwer; Warehouses tun sich als Zeitreihenspeicher schwer; Lakes tun sich schwer als beides.

2. Lake ohne Governance. Wird zum Data Swamp — niemand weiß, was dort ist oder wie es zu nutzen ist.

3. Warehouse ohne Rohdatenarchiv. Einmal aggregiert, geht der rohe Kontext verloren. Künftiges ML‑Training lässt sich nicht rekonstruieren.

4. Lake‑first‑Strategie. Alles in einen Lake zu kippen ohne operative Ebene bedeutet, dass OEE‑Reporting nicht in Echtzeit funktioniert.

Lakehouse: der jüngere Mittelweg

Lakehouses (Databricks, Snowflake‑Hybrid, Iceberg / Delta Lake auf Objektspeicher) versuchen, die Flexibilität des Lakes mit der Performance des Warehouses zu verbinden. Für reifere Deployments sind diese zunehmend attraktiv — eine Ebene weniger, die zu betreiben ist.

Für die meisten Anlagen ist ein sauberes Dreischicht‑Setup jedoch weiterhin einfacher zu betreiben als ein einzelnes Lakehouse, das versucht, alles zu leisten.

Wie OEE‑Daten fließen sollten

1. PLC/Sensordaten → Zeitreihendatenbank (operative Ebene). OEE live berechnet.
2. Aggregierte OEE → Warehouse (Reporting‑Ebene). BI‑Dashboards laufen hier.
3. Rohe Zeitreihen → Lake (Analytics‑Ebene). Zur Aufbewahrung für ML‑Training und explorative Analysen.
4. Ausgaben von ML‑Modellen → Zeitreihendatenbank (füttert die operative Sicht zurück).

Häufige Fehler

1. Die Analytics‑Ebene überspringen. Kein Roharchiv bedeutet später keine ML‑Trainingsdaten.

2. Die Reporting‑Ebene überspringen. Abfragen von Zeitreihen für BI‑Reports sind langsam und teuer.

3. Enge Kopplung zwischen den Ebenen. Pipelines sollten lose gekoppelt sein, damit jede Ebene unabhängig weiterentwickelt werden kann.

4. Kein Data Steward. Ohne Verantwortlichkeit verfallen sowohl Lake als auch Warehouse.

Wie eine moderne OEE‑Plattform passt

Eine moderne OEE‑Plattform übernimmt die operative Ebene und integriert sich an der Nahtstelle mit Warehouse und Lake. Die Plattform speichert Zeitreihendaten für Echtzeit‑OEE, exportiert Aggregate ins Warehouse und archiviert rohe Daten im Lake.

Das OEE‑Modul von Fabrico übernimmt die operative Ebene mit nativer Zeitreihenspeicherung, exportiert Aggregate in Standard‑Warehouses (Snowflake, BigQuery) und archiviert Rohdaten in Objektspeicher für ML‑ und explorative Nutzung.

Sehen Sie, wie Fabrico dies automatisch erfasst — OEE für die Fertigung erkunden oder eine Demo buchen.

Weiterführende Lektüre

• Audit zur Datenqualität in der Fertigung
• OEE für die Chargenfertigung
• MQTT in der Fertigung
• Pareto‑Diagramm in der Fertigung

Häufig gestellte Fragen

Brauche ich sowohl einen Lake als auch ein Warehouse?

Die meisten Produktionsanlagen profitieren von beidem. Kleine Betriebe kommen möglicherweise mit nur einem Warehouse und einer Zeitreihendatenbank aus.

Ist ein Lakehouse dasselbe wie beides zu haben?

Grundsätzlich ja, in der Praxis reift die Technologie noch. Dreischicht‑Setups sind erprobter.

Wo passt der Historian hin?

Der Historian ist die operative Ebene (Zeitreihendatenbank). Lake und Warehouse liegen darüber.

Kann ich ML im Warehouse durchführen?

Für aggregierte Daten: ja. Für rohe Sensordatenströme oder Bilddaten ist der Lake praktischer.

Wie viel Daten sollte der Lake aufbewahren?

So viel wie bezahlbar ist. Lakes sind günstig; zukünftige Anwendungsfälle für alte Daten sind unvorhersehbar.