Data Lake, Data Mesh oder Data Warehouse? Eine Architekturanleitung für industrielle KI unter DSGVO und On-Premise-Zwängen

Das eigentliche Problem in industriellen KI-Projekten ist selten das Modell. Die meisten Modelle scheitern im Feld an Daten: fehlende Taktzeit-Synchronisation zwischen Sensorströmen, ungeklärte Schemaevolution, fehlende Nachvollziehbarkeit, keine saubere Trennung von PII (personenbezogenen Daten), langsames Retraining, oder einfach daran, dass die Produktion nachts das Netzwerk segmentiert und Ihre Pipeline am Montagmorgen leere Datasets sieht. Wer in solchen Umgebungen Data Lake, Data Mesh oder Data Warehouse ohne klares Betriebs- und Governance-Design einführt, zementiert technische Schulden.

Dieser Leitfaden richtet sich an CTOs und Heads of Digitalization in regulierten Industrien. Er erklärt, wie Sie die drei Paradigmen richtig einordnen, welche Architekturmuster in der Praxis tragfähig sind, welche Trade-offs Sie bewusst eingehen sollten und wie Sie DSGVO- und On-Premise-Anforderungen ohne US-Cloud-Abhängigkeit erfüllen.

Kernaussage vorab:

  • Warehouse ist ein Abfrage- und Governance-Pattern für saubere, kuratierte, hochstrukturierte Daten und BI/Reporting.

  • Lake ist ein Speicher- und Verarbeitungspattern für rohe bis veredelte Daten, Batch und Streaming, Schema-on-read mit optionaler Transaktionsschicht.

  • Mesh ist ein Organisations- und Verantwortungsmodell, das Data Products an Domänen bindet. Es ist kein Tool.

Setzen Sie die drei nur gemeinsam sinnvoll ein, wenn Sie sie als komplementäre Bausteine verstehen – mit klarer Priorität auf Datensouveränität und Betriebsreife on-prem.

1) Ausgangslage in der Industrie: Warum Dateninfrastruktur das Bottleneck ist

  • Heterogenität im OT: PLCs, SCADA, OPC-UA, Feldbusse, Vision-Systeme, proprietäre Protokolle. Unterschiedliche Taktungen (ms bis Minuten), harte Netzsegmentierung, Air-Gaps.

  • Datenarten: Zeitreihen (Sensors), Events (Alarme), Bilder/Video (Qualitätssicherung), Text (Wartungsberichte), Binärformate (Firmware/Logfiles).

  • Regulatorik und Souveränität: Daten dürfen das Werk/Netz nicht verlassen; PII ist strikt zu trennen; Auditierbarkeit ist Pflicht; Schatten-IT ist tabu.

  • Operationaler Zwang: Modelle müssen am Edge laufen, Stream-Ingestion darf die Linie nicht stören, Batch-Prozesse müssen wartungsfensterfreundlich sein.

  • Organisationsrealität: Domänen wie Qualität, Instandhaltung, Produktion, Einkauf arbeiten getrennt, aber teilen Datenabhängigkeiten.

Aus diesen Randbedingungen folgt: Die Architektur ist wichtiger als das Tooling. Und On-Premise-Fähigkeit, DSGVO-konforme Governance und Wiederholbarkeit sind nicht verhandelbar.

2) Entscheidungsrahmen: Welches Paradigma löst welches Problem?
Stellen Sie vor der Tooldiskussion drei Fragen:

  • Datenflusscharakter: Batch, Streaming oder beides? In der Produktion ist es fast immer beides. Das bevorzugt Lake-Pattern (objektbasiert) mit Stream-Ingestion und optionalem Warehouse für kuratierte Sichten.
  • Verantwortlichkeiten: Sind Datenabhängigkeiten stark domänenübergreifend und ändert sich die Organisation langsam oder schnell? Bei vielen Domänen lohnt sich Mesh – aber nur, wenn Sie ein starkes Plattform-Team haben.
  • Compliance/Residency: Müssen Sie on-prem bleiben? Dann wählen Sie Bausteine, die im eigenen Rechenzentrum oder auf dem Shopfloor laufen, inklusive GPU-Training, Feature-Serving, Katalog, Registry und Observability.

3) Data Warehouse in der Industrie: Wann sinnvoll, wann schädlich?
Sinnvoll:

  • Standardisierte KPIs und Compliance-Reporting (OEE, Ausschussquoten, MTBF).

  • Finanz- und Planungsintegration, bei der starre Semantik und Row-Level-Security wichtig sind.

  • Langfristige, kuratierte Sichten mit hohem Datenqualitätsanspruch und wenigen Quellen.

Schädlich, wenn:

  • Sie versuchen, hochvolumige Rohdaten (Bild/Video, Hochfrequenz-Zeitreihen) in ein Warehouse zu pressen. Das treibt Kosten/Komplexität und mindert Agilität.

  • Schemaevolution häufig ist. Warehouses mögen seltene, kontrollierte Änderungen, nicht tägliche Variantensprünge am Sensor.

  • Sie Feature Engineering und Trainingsdaten direkt aus Warehouse-Tabellen „zusammenklicken“. Ohne Lineage, Versionierung und Time-Travel laufen Sie in Reproduzierbarkeitsprobleme.

Technikmuster:

  • Columnar-Engine für Kuratierung und BI; externe Tabellen können auf Lake-Dateien (z. B. Parquet) zeigen, wenn Transaktionslayer vorhanden ist.

  • Separate Security Domains: Warehouse hat Zugriff nur auf „gold“-Sichten, keine Rohdaten.

4) Data Lake richtig bauen: Ohne Transaktionsschicht wird es Wildwuchs
Ein industrietauglicher Lake besteht aus:

  • Objektstorage on-prem (S3-kompatibel) für Roh- und veredelte Daten. Für Edge-Standorte: Replikations- oder Puffermechanismen bei Netzausfällen.

  • Offene Formate (Parquet, ORC) für Tabellen, lossless Formate (PNG/TIFF/MP4) für Medien; Metadaten in Sidecar-Dateien (z. B. JSON) oder Manifesten.

  • Transaktionsebene für ACID auf Dateien, Schemaevolution, Time-Travel und Partitionierung. Ohne diese Ebene werden parallele Writer, Upserts und Deletes zum Albtraum.

  • Medaillon-Prinzip:

  • Bronze: roh, append-only, unveränderlich, mit technischer Zeit und Source-Metadaten.

  • Silver: gereinigt, normiert, vereinheitlichte Schemas, angereicherte Techniken (z. B. Einheitenumrechnung).

  • Gold: domänenspezifische, analytische Sichten oder Feature-Sets mit klaren SLAs.

  • Lineage und Data Contracts: Jeder Downstream-Datensatz kennt seinen Upstream, inklusive Schemahash, Transformationsversion und Zeitfenster. Dazu gehört ein Schema-Registry für Streams (z. B. Avro/Protobuf-Schemas).

Streaming-Ingestion:

  • Edge-Gateways in Produktionszellen: Sammeln OPC-UA/MQTT/Kamera-Streams, normalisieren Timestamps (PTP/NTP), schreiben in lokale Queues. Bei WAN-Ausfall: lokaler Persistenzpuffer, späteres Backfill.

  • Zentrale Message-Bus-Schicht on-prem (Publish/Subscribe), die in Bronze-Tabellen/Dateien mündet. Transformationsjobs versioniert, idempotent, testbar.

5) Data Mesh: Organisationsprinzip, kein Tool
Ein Mesh funktioniert nur, wenn:

  • Jedes Domänenteam (z. B. Qualität, Instandhaltung) ein Data Product verantwortet, mit:

  • klar definiertem Datenvertrag (Schema, Qualität, Aktualität, Datenschutz),

  • dokumentiertem Zugriffspfad (APIs/Tabellen, Katalogeintrag),

  • Monitoring und Alerting auf die SLAs.

  • Ein zentrales Plattform-Team eine „Thin Platform“ stellt:

  • GitOps/CI-CD für Daten-Pipelines und Modelle,

  • Einheitliche AuthN/AuthZ, Secret-Management, Schlüsselverwaltung,

  • Data Catalog/Discovery, Lineage, Schema Registry,

  • Infrastruktur für Lake/Warehouse, Self-Service Provisioning.

  • Governance „by design“ ist: PII wird früh klassifiziert, Policies werden technisch erzwungen (z. B. Maskierung, Pseudonymisierung, Zugriff nur via genehmigte Views).