Data Lake, Data Mesh oder Data Warehouse? Ein Entscheidungsrahmen für industrielle KI unter Datenhoheit

Problem vor Technologie: Die meisten Industrie-KI-Initiativen scheitern nicht am Modell – sondern an der Datenlogistik. Typische Lage: Ein PoC erkennt Produktionsfehler auf einem Labor-Datensatz, aber in der Fabrik gibt es fünf SCADA-Varianten, wechselnde Schichtmodelle im MES, ein ERP ohne belastbare Änderungshistorie und ein Netzwerk, das im Schichtwechsel zuverlässig überlastet ist. Dazu kommen DSGVO, Exportkontrollen und der legitime Anspruch, sensible Daten nicht in eine US-Cloud zu schieben.

Die Wahl des Datenarchitektur-Musters – Data Warehouse, Data Lake/Lakehouse oder Data Mesh – ist deshalb kein Glaubenskrieg, sondern eine Frage des Problemraums. In diesem Artikel zeige ich aus der Praxis industrieller KI-Systeme, wie Sie das passende Muster auswählen, wie Sie es auf On-Premise-Infrastruktur umsetzen und wo die harten Trade-offs liegen. Mein Bias ist klar: Souveränität ermöglicht Intelligenz. Wenn Datenhoheit nicht verhandelbar ist, bauen wir so, dass Governance und Betriebsfähigkeit in rauen Umgebungen Priorität haben.

Was wollen wir überhaupt erreichen?

Bevor wir Architekturen vergleichen, drei typische Zielbilder aus Industrieprojekten:

  • Vorhersagbare, auditierbare Datenflüsse: Jeder KPI, jedes Feature fürs Training und jeder LLM-Output muss auf Rohdaten und Prozesse zurückführbar sein (Lineage). Reproduzierbarkeit schlägt „Move fast“.
  • Edge-to-Core-Betriebsfähigkeit: Daten entstehen an Maschinen, Zügen, Flugzeugen oder im Feld. Upload ist intermittierend. Systeme müssen offline-first funktionieren und asynchron konsolidieren.
  • Zweckgebundener Zugriff: Nicht jeder darf alles. DSGVO, Betriebsrat, Geheimschutz. Wir brauchen technische Durchsetzung: Datenminimierung, Pseudonymisierung, Policy Enforcement, Audit.

Die drei Muster in Kürze

  • Data Warehouse: Zentralisiertes, stark modelliertes Repository für strukturierte Daten (SQL), optimiert für konsistente Kennzahlen und Reports. Typisch: ETL in star/snowflake-Schemata, SCD, BI-Tools. Stärke: Konsistenz, schwächer bei un-/halbstrukturierten, hochvolumigen Sensordaten.
  • Data Lake/Lakehouse: Roh- und kuratierte Daten auf objektspeicherbasiertem Storage (z. B. MinIO/Ceph on-prem), spaltenorientierte Formate (Parquet) und Tabellenformate (Apache Iceberg/Hudi/Delta) für ACID, Time Travel, Schema-Evolution. Stärke: Vielfalt, Skalierung, ML-Workloads. Erfordert robuste Governance-Schicht.
  • Data Mesh: Organisationsmuster. Domänen (z. B. „Fertigung“, „Instandhaltung“, „Flotte“) verantworten „Data Products“ mit klaren Verträgen (Schemata, SLAs, Versionen). Eine zentrale Plattform stellt Self-Service-Infrastruktur, Sicherheitsstandards und Governance. Stärke: Skalierung über Teams/Standorte, schwächer wenn die Plattform-„Schienen“ fehlen.

Industrie-spezifische Anforderungen, die die Wahl prägen

  • Heterogene Protokolle und Datenraten: OPC UA, Modbus, MQTT, CAN, proprietäre SCADA-Historian-Exporte, ERP/SQL. Mix aus Batch und Stream. Bild-/Video, Zeitsensoren, Text (Wartungslogs), 3D-Punktwolken.
  • Netzwerk- und Standortgrenzen: Air-gapped Netze in Defense, sporadische VPN-Tunnel aus dem Feld, rechtliche Grenzen zwischen Ländern. Replikation muss asynchron, signiert und fehlertolerant funktionieren.
  • Audit und Zertifizierung: Bahn- und Luftfahrtregulatorik, Defense-IT. Nachvollziehbarkeit von Datenmanipulationen, Freigabeprozessen, Modellständen. Änderungsprozesse müssen techn. abbildbar sein (Change Logs, genehmigte Pipelines).
  • DSGVO und Betriebsrat: Personenbezug in Wartungslogs, Kameraaufnahmen, Sprachdaten. Strenge Zweckbindung, Datensparsamkeit, Löschkonzepte. Keine Schattenkopien in ausländischen Clouds.

Ein On-Prem-Referenzbaukasten

Unabhängig vom Muster braucht eine souveräne Daten- und KI-Infrastruktur wiederkehrende Bausteine. Bewährt haben sich:

  • Ingestion
  • Industrielle Protokolle: Connectoren für OPC UA/MQTT an der Edge (Container auf IPC/Industrial PCs), gepuffert (z. B. lokale Kafka/Redpanda-Cluster), mit Store-and-Forward.
  • CDC aus Business-Systemen: Change Data Capture aus ERP/MES/SQL (z. B. Debezium) in einen Streaming-Bus.
  • Datei-Gateways: Signierte File Drops (Bilder, CAD, Punktwolken), Quarantäne + Virenscan, verpflichtende Metadaten.
  • Edge-zu-Core-Replikation: Pull-basiert aus dem Core, mit Signaturprüfung und Quotas, um Air-Gaps und Firewalls zu respektieren.
  • Storage und Formate
  • Objektstorage on-prem: MinIO oder Ceph, mandantenfähig, versionierend, Server-Side-Encryption mit HSM-gestützter Schlüsselverwaltung.
  • Tabellenformate: Apache Iceberg/Hudi/Delta für ACID, Time Travel, Schema-Evolution, Partitionierung (zeit-/anlagen-/domänenbasiert).
  • Columnar Formate: Parquet/ORC für Analyse und ML; Avro/Protobuf für Streams (Schema Registry).
  • Warehouse-Engine: Für BI/Reporting z. B. ClickHouse, Exasol, Vertica oder Postgres-basierte Lösungen – abhängig von Lizenzen/Betriebsmodell.
  • Verarbeitung
  • Batch: Spark oder Trino/Presto für SQL-Transformationen, Feature-Backfills, Trainingsdatenmaterialisierung.
  • Stream: Apache Flink oder Kafka Streams für Online-Feature-Pipelines, CDC-Transformationen, Event-Sourcing.
  • Orchestrierung: Argo Workflows auf Kubernetes oder Apache Airflow für deklarative, versionierte Pipelines (Infrastructure as Code).
  • Metadaten und Governance
  • Data Catalog und Lineage: OpenMetadata/Amundsen plus OpenLineage/Marquez; verpflichtende Datasets als deklarative Artefakte (YAML), Review-Prozess via GitOps.
  • Schema- und Vertragsmanagement: Schema Registry (Avro/Protobuf), Contract-Tests in CI, Versionierung und Deprecation-Policy.
  • Zugriff: RBAC/ABAC mit OIDC, Policy-Engine (z. B. Open Policy Agent), Zweckbindung als Attribut, Audit-Logs manipulationssicher (WORM-Buckets).
  • Datenqualität und Tests
  • Data Unit-/Integrationstests: Great Expectations oder Soda, Thresholds als Code, Blocker bei Verletzung.
  • Quarantäne/Purgatory: Unsichere Daten landen erst nach Freigabe im kuratierten Bereich.
  • Backfills als geprüfte Releases: Keine stillen Neuberechnungen.
  • MLOps
  • Feature Store: Feast (online/offline), Abgleich zwischen Stream-Serving und Batch-Training.
  • Experiment-Tracking/Registry: MLflow oder vergleichbar, Artefakt-Store im On-Prem-Objectstore.
  • Serving: KServe/Seldon auf Kubernetes, Canary/Shadow, A/B, Observability via Prometheus/Grafana/Loki.
  • LLM-spezifisch: RAG-Pipelines mit on-prem Vektorstore (pgvector, OpenSearch), Prompt-/Output-Logging, PII-Redaktion, Policy-Gates. Für Agenten zusätzlich Tool-Use-Logging und Safety-Checks.

Wie die Muster auf diesen Baukasten mappen

1) Data Warehouse – der robuste Kern für Kennzahlen