Data Lake, Data Mesh oder Data Warehouse für industrielle KI? Ein Architekturleitfaden unter Souveränitätszwang

Die meisten industriellen KI-Projekte scheitern nicht am Modell, sondern an der Datenpipeline. In der Produktion sind Daten fragmentiert zwischen PLC/SCADA, Sensorik, Bildverarbeitung, Historian, MES, ERP. Netzwerke sind teil‑air‑gapped, Latenzbudgets eng, Datenschutz und Exportkontrollen nicht verhandelbar. Wer hier mit einem generischen “wir bauen mal einen Data Lake in der Cloud” startet, landet zuverlässig im Data Swamp oder in der Compliance-Hölle. Dieser Beitrag beschreibt, wie man in diesem Umfeld eine belastbare Daten- und KI-Infrastruktur entwirft – problemgetrieben, souverän, on‑premise‑fähig – und wo Data Lake, Data Mesh und Data Warehouse jeweils ihren Platz haben.

Ausgangslage in der Industrie: technische Randbedingungen, die Architekturentscheidungen diktieren

  • Heterogene Protokolle und Datenformen: OPC UA, MQTT, Profinet, proprietäre PLC‑Protokolle; Timeseries aus Historian; hochvolumige Bild- und 3D‑Daten; Log- und ERP‑Transaktionen.
  • OT/IT‑Trennung: strikte Netzwerkzonen, unidirektionale Gateways, zeitweise offline Sites, strenge Change‑Kontrolle.
  • Realtime‑Anforderungen: Inline‑Qualitätskontrolle an der Linie (ms–s), latenzkritische Entscheidungsunterstützung für Bediener.
  • Datensouveränität: keine US‑Cloud‑Abhängigkeit, DSGVO/Exportkontrolle, Auditierbarkeit, Reproduzierbarkeit.

Vor diesem Hintergrund ist “die eine” Architektur die falsche Frage. Richtig ist: Welche Daten- und Rechenflüsse brauchen welche Eigenschaften – und welches Muster adressiert diese Eigenschaften minimalinvasiv?

Data Lake vs Data Warehouse vs Data Mesh – was taugt wofür?

  • Data Warehouse: Stark bei konsistenten, strukturierten, unternehmensweiten Kennzahlen (MES/ERP). Schwach bei Rohsignalen, Bilddaten, schemadehnbaren Events. Gut für Berichte, schlecht für CV‑Training.
  • Data Lake: Stark bei großen, roh‑ oder semistrukturierten Daten (Bilder, Timeseries, Logs), late binding von Schemas, kosteneffiziente Speicherung. Risiko: ohne Governance kippt der Lake zum Swamp.
  • Data Mesh: Organisationsmuster, nicht Technologie. Datenhoheit und Domain‑Teams verantworten “Data Products” mit klaren Verträgen. Stark gegen zentrale Bottlenecks, schwach, wenn Domänen keine Datenverantwortung übernehmen oder Werkzeuge fehlen.

In der Industrie performt ein hybrides Muster am besten: Ein souveränes Lakehouse als Speicher‑ und Compute‑Rückgrat, eingebettet in ein föderiertes Data Mesh mit klaren Domänengrenzen und einem schlanken, aber verbindlichen Governance‑Layer. Ein klassisches Enterprise‑Data‑Warehouse ergänzt das Bild dort, wo Finanz/Operations‑KPIs mit Slowly Changing Dimensions gebraucht werden.

Das Muster “Souveränes Industrial Lakehouse im Mesh”

Kernelemente:

  • Objekt‑Storage on‑prem mit S3‑API (z. B. Ceph/MinIO): zentraler, versionierbarer Speicher für Rohdaten, Features und Artefakte. WORM‑Buckets für Audit‑kritische Daten.
  • Tabulare Abstraktion mit Iceberg/Delta: Schema‑Evolution, Time‑Travel, ACID für Batch und Stream‑Upserts. Partitionierung nach Zeit/Asset/Station.
  • Streaming‑Fabric: Kafka/Redpanda als Bus für Events, Telemetrie, Change‑Data‑Capture aus MES/ERP. Schema‑Registry (Avro/Protobuf) als Teil des Vertrags.
  • Batch‑Compute und Stream‑Compute: Spark für Batch/Featurization, Flink für kontinuierliche Aggregationen/Anomalie‑Scores.
  • Feature‑Store‑Pattern: offline store im Lakehouse, online store (z. B. Redis/Postgres) pro Domäne für inferenznahe Features.
  • MLOps‑Schicht: Container‑Registry, Model‑Registry, Pipeline‑Orchestrierung, reproduzierbares Training, Evaluationsharness, Observability.
  • Governance‑Plane: Identität/Access (OIDC/RBAC/ABAC), Data‑Product‑Katalog, Qualitäts‑Checks, Lineage, Genehmigungs‑Workflows.
  • Domänenzonen: Physische/logische Isolation pro Anlage/Fertigungslinie mit einem lokalen Edge‑Gateway. Mesh statt Monolith: Datenprodukte werden dort erzeugt und versioniert, wo sie entstehen.

Ingestion: von der Linie in den Lake – robust, schemagesteuert, air‑gap‑fähig

  • OT‑Edge‑Gateway: Entkopplung der Linie. Adapter für OPC UA/MQTT/Dateidrops, Pufferung (Store‑and‑Forward), Validierung gegen Schema‑Registry, Pseudonymisierung falls notwendig, signierte Protokollierung. Netzwerkseitig DMZ/One‑Way‑Gateways respektieren.
  • Change Data Capture: Für MES/ERP‑Tabellen CDC via Debezium in Kafka; Downstream‑Materialisierung in Lakehouse‑Tabellen (Iceberg/Delta MERGE INTO) für analytik‑ und trainingsfreundliche Sichten.
  • Bild-/3D‑Daten: Direkt in den Objekt‑Storage mit Content‑Addressable Naming, Sidecar‑JSON mit Metadaten/Labels/Bounding Boxes. Hash‑basierte Deduplizierung, konsistente Namenskonvention.
  • Timeseries: Entweder als Parquet‑Segmentierung mit Zeit/Asset‑Partition oder als spezialisierten Store, aber stets mit Exportpfad ins Lakehouse für Training.
  • Verträge: AsyncAPI/OpenAPI für Events/Services, Avro/Protobuf Schemas mit Versionierung und Kompatibilitätsregeln. Breaking Changes nur via neue Topic/Namespace.

Speicher und Datenorganisation: vom Rohsignal bis zum Data Product

  • Zonen statt Chaos:
  • Raw: 1:1‑Ingest, unveränderlich, WORM‑Buckets wo nötig.
  • Bronze: bereinigte, standardisierte, aber detailreiche Daten; Zeitreihen resampled, Bilder normalisiert.
  • Silver: domänenspezifische Features, featurisierte Datasets, Balanced Splits, Weak‑Labeling‑Artefakte.
  • Gold: konsumfertige Data Products mit harten SLOs (z. B. “inferable features innerhalb 200 ms verfügbar”).
  • Metadaten: Einheitlicher Katalog und Ownership‑Angaben; Qualitätsmetriken (Vollständigkeit, Pünktlichkeit), Freshness‑SLOs je Produkt.
  • Versionierung: Daten‑, Feature‑, Label‑ und Modellversionen gemeinsam tracken; Reproduzierbarkeit ist Audit, nicht Komfort.

Compute‑Plane: Training, Feature Engineering, Inferencing

  • Batch‑Pipelines: Spark/Arrow‑basierte Featurization, Data Balancing, Augmentierung; Iceberg/Delta unterstützt atomic Upserts und Time‑Travel für reproduzierbares Training.
  • Stream‑Pipelines: Flink für Feature‑Berechnung in Near‑Realtime (z. B. Rolling Z‑Scores, EWMA, Stateful Joins mit Equipment‑Context).
  • GPU‑Training on‑prem: Kubernetes mit NVIDIA GPU Operator oder Slurm für planbares Training. A100/H100 mit MIG für gleichzeitige Workloads. Artifakt‑Cache lokal, keine externen Abhängigkeiten.
  • Inferenzmuster:
  • Inline an der Linie: Low‑latency Inferenz mit Triton Server; Feature‑Cache im Online Store; Circuit‑Breaker und Fallback zur Regel‑Engine.
  • Zentrale Batch‑Scoring‑Jobs: Für nicht zeitkritische Qualitätsbewertungen oder Flottenanalysen.

MLOps unter Souveränitätsanforderungen