Titel: Datenarchitekturen für industrielle KI: Data Lake, Data Mesh, Data Warehouse – Entscheidungen unter DSGVO- und On-Premise-Constraints

Wenn industrielle Unternehmen mit KI ernst machen wollen, scheitert es selten am Modell – fast immer an der Dateninfrastruktur. In der Industrie reden wir nicht über „schöne Demos“, sondern über SCADA-Daten mit Latenzanforderungen, Bilddaten aus der Fertigung, Messreihen aus Prüffeldern, DOM-Events aus Bedienoberflächen, Protokolle aus Steuerungen, CAD/PLM-Daten und dazu Business-Kontext aus MES/ERP. Alles mit harten Auflagen: Datensouveränität, DSGVO, OT/IT-Segmentierung, Air-Gaps, Nachvollziehbarkeit. Das Problem ist nicht „welches Modell“, sondern „welche Architektur trägt diese Zwänge und bleibt betrieblich gesund“.

Dieser Beitrag ist ein praxisnaher Leitfaden: Wann Data Warehouse, wann Data Lake, wann Data Mesh – und wie sieht eine belastbare Architektur für industrielle KI unter Souveränitätsanforderungen aus? Meine Perspektive: Ohne saubere, domänengerechte Datenpipeline ist jedes ML-Modell wertlos. Souveränität ermöglicht Intelligenz.

1) Industrielle Randbedingungen vor der Architekturwahl

Bevor man Begriffe vergleicht, muss man klären, welche Engineering-Realität die Architektur tragen soll:

  • Datentypen:
  • Zeitreihen aus SPS/PLC, OPC UA/Modbus, Historian-Systemen (ms–s Auflösung)
  • Bilder/Video (Inspektion, Montagevalidierung), Punktwolken (LiDAR), CAD
  • Ereignisströme (Maschinenzustände, Alarme), Logfiles
  • Tabellarische Business-Daten (MES, ERP, QM, Instandhaltung)
  • Latenzanforderungen:
  • Edge/Inline-Inferenz (10–100 ms) vs. Near-Real-Time-Analytik (Sekunden/Minuten) vs. Batch-Training (Stunden)
  • Souveränität/DSGVO:
  • Keine US-Cloud-Abhängigkeiten; Verarbeitung on-prem oder in souveräner Infrastruktur
  • Nachvollziehbarkeit und Zweckbindung; Pseudonymisierung/Maskierung; Auditierbarkeit
  • Netz und Betrieb:
  • OT/IT-Trennung, DMZ, eingeschränkter Egress, teils Air-Gap
  • Patch- und Wartungsfenster, Offline-Fähigkeit, deterministische Deployments
  • Compute und Speicher:
  • GPU-Kapazitäten für CV/LLM-Training/Inference
  • Durchsatzanforderungen für Objekt-Storage und Streaming
  • Lebenszyklus:
  • Versionierung von Daten und Modellen; Retention; Reproduzierbarkeit
  • Validierung und Freigaben in regulierten Umfeldern

Die Architektur muss diese Rahmenbedingungen durchgängig abbilden – nicht umgekehrt.

2) Data Warehouse, Data Lake, Data Mesh – praktisch definiert

  • Data Warehouse:
  • Stark strukturierte, kuratierte, integrierte Daten (Star/Snowflake-Schemata)
  • Typisch für BI/Reporting, Compliance, KPI-Standardisierung
  • ETL/ELT, ACID-Transaktionen, SQL-first
  • Stärken: Datenqualität, Konsistenz, Governance auf relationaler Ebene
  • Schwächen: Unhandlich für unstrukturierte Daten (Bilder, Audio), Feature-Engineering begrenzt, teils träge bei Streaming
  • Data Lake:
  • Objekt-Storage als zentrales Medium (S3-kompatibel), Dateien in offenen Formaten
  • Mit modernen Table-Formaten (Iceberg/Delta/Hudi) ACID/Schema-Evolution/Time-Travel möglich
  • Ideal für gemischte Datentypen und ML-Workflows (Batch + Streaming)
  • Stärken: Flexibilität, Kostenstruktur, große Dateien/Medien, ML-Freundlichkeit
  • Schwächen: Governance muss bewusst aufgebaut werden; Gefahr von „Datalake als Müllhalde“, wenn Standards fehlen
  • Data Mesh:
  • Kein Tool, sondern Organisations- und Architekturprinzip: Domänen besitzen und verantworten „Data Products“
  • Zentrale Plattform stellt Standards, Self-Service und Durchsetzungsmechanismen (Katalog, Identität, Policies)
  • Stärken: Skalierung über Domänen, bessere Kontexttreue der Daten
  • Schwächen: Ohne starke Plattform- und Governance-Fähigkeiten chaotisch; Overhead für kleine Teams

Wichtig: Data Lake vs. Warehouse ist eine technische Entscheidung; Mesh ist eine Organisationsentscheidung über Domänenverantwortung. Häufig landet man in einem Lakehouse (Lake mit Table-Format und SQL-Fähigkeit) plus ausgewählten Warehouse-Komponenten für Reporting.

3) Entscheidungsrahmen: Was dominiert – Reporting, ML oder Medien-/Dokumentdaten?

  • Use Case A: KPI-Transparenz, Compliance, klassische BI steht im Vordergrund
  • Tendenz: Warehouse-zentriert, Lake als Rohdaten-/Archiv-Beifang
  • Motivation: Governance-first, standardisierte Kennzahlen, stabile Schemata
  • Use Case B: Computer Vision, Prädiktion an Maschinen, multimodale Daten
  • Tendenz: Lakehouse-zentriert, Streaming, Feature Store, GPU-Trainingspfad
  • Motivation: Große Dateien, Feature-Engineering, Versionierung, gemischte Workloads
  • Use Case C: Übergreifende Werke/Anlagen mit klaren Domänen (Fertigungslinien, Instandhaltung, Qualität)
  • Tendenz: Mesh-Prinzipien auf einem Lakehouse: Domain Data Products, gemeinsame Standards, Self-Service
  • Motivation: Skalierung ohne zentralen Flaschenhals, klare Verantwortungen

Die meisten industriellen Landschaften sind Mischformen. Entscheidend ist, für den ersten und zweiten Leuchtturm-Use-Case die tragende Architektur klar zu wählen und nicht „alles auf einmal“.

4) Architekturpattern A: On-Prem Lakehouse für Computer Vision + Zeitreihen

Ziel: Eine Pipeline, die Bilder/Video, Zeitreihen und Ereignisse bedient, DSGVO-konform ist, On-Prem läuft und Training/Inference trägt.