Titel: Data Lake, Data Mesh oder Data Warehouse in der Industrie? Architekturentscheidungen unter Datensouveränität

Ausgangsproblem

Bevor wir über Technologien sprechen, müssen wir die eigentliche Ingenieursaufgabe präzisieren: In industriellen Umgebungen sind Daten verteilt (OT/IT, Edge/Cloud, Zulieferer/OEM), sie sind heterogen (Zeitsignale, Bilder, CAD, Protokolle), sie enthalten personenbezogene oder betriebsgeheime Informationen und sie werden oft in sicherheits- und qualitätskritischen Kontexten genutzt (Traceability, Zulassungen, Audits). Typische Randbedingungen:

  • Air-Gap oder strenge Netzwerkzonen, kein US-Cloud-Abfluss, DSGVO, Werksgeheimnisse.

  • Reproduzierbarkeit über Jahre: Ein Modell, das eine Qualitätsentscheidung trifft, muss später unter identischer Datenbasis nachvollziehbar sein.

  • Geringe Latenz am Edge (Kamera → Inferenz < 50 ms), aber schwere Offline-Verarbeitung im Cluster (Training, Re-Indexierung).

  • Versions- und Änderungsmanagement (Daten, Schemata, Features, Modelle) als Erstbürger, nicht als Add-on.

  • Kleine, belastbare Plattformteams: Operativ wartbare Lösungen schlagen „hippe“ Architekturen.

Mit dieser Realität im Hinterkopf ist „Data Lake vs Data Mesh vs Data Warehouse“ keine Glaubensfrage, sondern eine gezielte Architekturentscheidung entlang klarer Achsen: Latenz, Schema-Evolution, Domain-Autonomie, Compute-Lokalität, regulatorische Grenzen, Lineage/Reproduzierbarkeit und Betriebsaufwand.

Entscheidungsrahmen: Welche Architektur löst welches Problem?

Data Warehouse (klassisch)

Wofür gut:

  • Strukturiertes Reporting, Finanz- und Produktions-KPIs, stabile Dimensionen und Fakten, deterministische SQL-Workloads.

  • Strenge Schemas, gute Werkzeuge für Datenqualität, Berechtigungen, Datenmaskierung.

  • On-Premise-Optionen existieren (PostgreSQL/Timescale für kleinere Lasten, Exasol, Vertica, SQL Server, Oracle).

Grenzen in industriellen KI-Szenarien:

  • Ungeeignet für unstrukturierte Daten (Bilder, Videos, Punktwolken). Diese werden ohnehin in Objekt- oder Dateispeichern landen.

  • Schema-Evolution ist schwerfälliger; schnelle Iteration im ML-Feature-Engineering leidet.

  • Event-getriebene OT-Daten (Kafka, MQTT) passen oft besser in Streaming- und Lake/Lakehouse-Pattern.

  • Cloud-Warehouses bringen Souveränitätsrisiken (Transfer, US-Rechtszugriff). On-Prem-Alternativen sind vorhanden, aber teils kostspielig und weniger flexibel für ML.

Fazit:

  • Ein Warehouse ist in der Industrie kein Feind, sondern ein präzises Werkzeug: für reportingorientierte, stark strukturierte Datenprodukte. Für ML-first-Workloads reicht es selten allein.

Data Lake

Wofür gut:

  • Günstige, skalierbare Speicherung von Rohdaten (Parquet/ORC, Bilder, Logs) in S3-kompatiblem Objekt-Storage (On-Prem: MinIO, Ceph).

  • Schema-on-Read erlaubt flexible Exploration, Feature-Engineering, Labeling-Workflows.

  • ACID-Table-Formate (Apache Iceberg, Delta Lake, Hudi) heben den Lake zum „Lakehouse“: Time-Travel, Snapshots, Streaming Writes, Schema-Evolution.

Typische Engines:

  • Batch/Streaming: Spark, Flink, Dask.

  • SQL-Abfragen: Trino/Presto.

  • ML-Frameworks: PyTorch/TensorFlow, sklearn, XGBoost, eingebettet über Parquet/Iceberg-Connectoren.

  • Metadaten-Katalog: DataHub, Amundsen oder OpenMetadata; Zugriffskontrolle via Apache Ranger oder OPA.

Fallstricke:

  • Ohne Governance wird der Lake zum Sumpf: fehlende Datenverträge, keine Lineage, kleine Dateien ruinieren Performance.

  • Betrieb erfordert Disziplin: Compaction, File-Sizing, Partitionierungsstrategie, Z-Ordering/Clustering, Retention-Policies, S3-Bucket-Layouts.

Fazit:

  • Der Lake (bzw. Lakehouse) ist die Arbeitspferd-Basis für industrielle ML/AI: Rohdaten rein, reproduzierbare Datasets und Features raus, mit ACID-Tabellen und Katalog als Rückgrat.

Data Mesh

Wofür gut:

  • Organisatorisches Muster: Domänen (z. B. Montage, Quality, Maintenance) liefern kuratierte Datenprodukte mit klaren Verträgen, Versionen und SLAs.

  • Skaliert Governance dezentral, wenn mehrere Werke/Bereiche eigenverantwortlich liefern sollen.

Voraussetzungen (oft ignoriert):

  • Ein starkes zentrales Plattformteam, das Self-Service-Fähigkeiten bereitstellt: Datenkatalog, ACID-Table-Service, CI/CD, Observability, AuthN/Z, Kosten- und Kapazitätsmanagement.

  • Reife in Domänen: Product Owner für Datenprodukte, Pflege von Datenverträgen, Testbarkeit, On-Call-Bereitschaft für Data SLAs.

Grenzen:

  • Nicht für den Start. Ein Mesh ohne tragfähige Plattform scheitert an Tool- und Prozessbruchstellen.

  • Für kleine Organisationen ist ein Mesh-Target Operating Model überdimensioniert; ein „Lakehouse mit klaren Datenprodukten“ reicht.

Fazit:

  • Mesh ist ein Betriebsmodell, kein Tool. Es lohnt sich ab 3–5 aktiven Domänen mit wiederkehrenden Datenprodukten und einem etablierten Lakehouse-Fundament.

Architektur-Patterns aus der Praxis

1) Visuelle Qualitätskontrolle (Kamera, Edge, Re-Training im Cluster)

  • Ingestion:

  • Kameras → Edge-Knoten (Industrie-PC mit GPU). Vorpufferung und Store-and-Forward bei Netzunterbrechung.

  • Metadata-Ereignisse (Produkt-ID, Linie, Takt, Rezept) via OPC UA/PLC → Gateway → Kafka/Redpanda.

  • Speicherung:

  • Bilder/Clips als Objekte im On-Prem-S3 (MinIO) mit Buckets pro Domäne, Objekt-Lock für Audit-Trails.

  • Metadaten und Labels als Iceberg-Tabellen (Parquet). Snapshot-IDs sichern Reproduzierbarkeit.

  • Verarbeitung:

  • Streaming-Inferenz am Edge (Triton Inference Server oder ONNXRuntime). Latenz < 50 ms.

  • Offline: Spark/Flink-Pipelines für Label-Sampling, Hard-Negatives, Data Curation.

  • Feature Store (Feast) für nicht-bildhafte Features (z. B. Linie, Schicht, Temperatur).

  • Governance und Sicherheit:

  • Katalog (DataHub) mit Lineage bis zum Modell-Artefakt.

  • Zugriff via RBAC/ABAC (Keycloak + OPA), Least Privilege, getrennte Service-Accounts.

  • Verschlüsselung: at-rest (SSE-KMS in MinIO, Keys in Vault oder HSM), in-transit (mTLS).

  • MLOps:

  • Training orchestriert mit Argo Workflows oder Prefect; Datasets werden per Iceberg-Snapshot-ID gepinnt.

  • Modell-Registry (MLflow), versionierte Eval-Sets, Champion/Challenger, Canary-Rollout am Edge.

  • Monitoring: F1/Recall im Feld, Verteilungsdrift (PSI/KL), Rückkanal zu Labeling.

2) Prädiktive Instandhaltung im Bahn-/Maschinenfleet-Betrieb

  • Ingestion:

  • Sensorik → MQTT/OPC UA → Kafka. Event-Time mit Watermarks, Handling verspäteter Events.

  • Speicherung:

  • Timeseries in TimescaleDB für jüngste Daten (Hot), Windows/Features im Lakehouse (Iceberg) für Re-Training (Warm), Langzeit-Archiv im S3 (Cold).

  • Verarbeitung:

  • Streaming-Features (Rolling Stats, FFT) in Flink. Feature-Drift-Signale an Monitoring.

  • Modelle: Gradient Boosting oder LSTM/Temporal Fusion Transformer je nach Signalcharakteristik.

  • Deployment:

  • On-Prem Kubernetes mit NVIDIA GPU Operator (falls Deep Learning), ansonsten CPU-optimiert, Node-Affinity auf Produktionszellen.

  • GitOps (Argo CD) für deklarative Deployments, Inferenz-Telemetrie via OpenTelemetry.