Industriefähige Daten- und KI-Infrastruktur: Data Lake, Mesh, Warehouse richtig kombinieren – mit Souveränität, MLOps und On-Prem-GPU

Die meisten Industrieunternehmen scheitern bei KI nicht an den Modellen, sondern an der Infrastruktur. Drei typische Befunde wiederholen sich:

  • Es gibt eine Datenhalde ohne klare Verträge, aber man erwartet produktionsreife Modelle.

  • Governance wird erst nach dem Go-Live „draufgeschraubt“ – zu spät für DSGVO, Audit und Reproduzierbarkeit.

  • Prototypen nutzen Cloud-PaaS, die später on-prem nicht verfügbar sind – das Ergebnis ist ein Rewrite.

Dieser Beitrag beschreibt aus Engineering-Perspektive, wie eine belastbare Daten- und KI-Infrastruktur für industrielle Umgebungen aussieht. Konkret: Wie ordnen sich Data Lake, Data Mesh und Data Warehouse in der Praxis? Welche technischen Muster tragen Datensouveränität und DSGVO? Wie setzt man MLOps auf, das in der Fertigung oder im Bahn- und Verteidigungsumfeld zuverlässig funktioniert? Und wann lohnt sich ein On-Prem-GPU-Cluster gegenüber Cloud-Training?

1) Industrielle Randbedingungen zuerst: das Problem-Set

Bevor wir über Technologien sprechen, muss das Problem sauber umrissen sein. Industrienahe KI hat einige nicht verhandelbare Eigenschaften:

  • Heterogene Quellen und schwankende Qualität: PLCs, SCADA/Historian, industrielle Kameras, Messfahrzeuge, ERP/MES – oft inkonsistente Timestamps, wechselnde Schemas, sporadische Connectivity.

  • OT/IT-Segregation: Netztrennung, Air-Gap-Zonen, zertifizierungsrelevante Umgebungen. „Schnell mal in die Cloud schieben“ ist meist keine Option.

  • Langfristige Nachvollziehbarkeit: Jahre an Historie, Audits, Änderungsnachweise für Safety- und Qualitätsprozesse.

  • Personenbezug nicht ausgeschlossen: Bediener-IDs in Logs, Qualitätsdaten mit Rückschluss auf Schichten/Teams – DSGVO ist auch in der Industrie real.

  • Exportkontrollen und Souveränität: Abhängigkeit von US-Clouds ist in Defense, Rail und Teilen der Fertigung politisch und rechtlich heikel.

  • Produktionsfenster: Deployments und Rollbacks müssen in Wartungsfenstern passen, nicht in Sprint-Demos.

Aus diesen Randbedingungen folgen Architekturprinzipien: on-prem-first, offene Standards, klare Datenverträge, reproduzierbare Pipelines, explizite Governance.

2) Data Lake, Data Mesh, Data Warehouse – kein „vs“, sondern ein Schichtenmodell

Das Framing „Lake vs Mesh vs Warehouse“ führt in die Irre. In der Industrie brauchen Sie alle drei – aber mit klarer Aufgabenverteilung.

  • Data Lake (Lakehouse-fähig): Zentrale, kosteneffiziente Speicherung roh bis aufbereitet, mit ACID-Tabellenformat für Schemainformation, Time Travel und Löschungen. Objektstorage (S3-kompatibel) plus ein Tabellenformat wie Apache Iceberg oder Delta ist de facto Standard on-prem. Ordnen Sie Daten in Schichten: Raw/Bronze (unverändert), Silver (bereinigt, normalisiert), Gold (domänenspezifisch modelliert).
  • Data Warehouse: Reporting- und BI-optimierte Sichten (Sternschema, Dimensionsmodelle), Materialisierungen und konsistente KPIs. On-prem sind ClickHouse, Postgres/Timescale oder ein Query-Engine-Ansatz (Trino/Presto auf dem Lake) üblich. Warehouse ergänzt, ersetzt aber nicht das Lakehouse.
  • Data Mesh: Organisatorische und technische Klammer, um Daten- und ML-Produkte domänennah zu verantworten. Zentrale Plattform liefert Self-Service-Tools, Sicherheit, Standards; Domänenteams liefern Datenprodukte mit klaren Verträgen, SLOs und Ownership.

Die alltägliche technische Umsetzung in Brownfield-Industrie sieht so aus:

Ingestion

  • Streaming: Kafka/Redpanda für Events, Sensorik, Maschinentelemetrie; Schema Registry für Avro/Protobuf.

  • Batch: SFTP-Drops, Historian-Exporte, Bild- und Videoimporte, mit Checksummen und Idempotenz.

  • Change Data Capture: Debezium o.Ä. für ERP/MES/CMMS-Inkremente.

  • Edge-Vorverarbeitung: Vorfilterung und Pseudonymisierung möglichst nah an der Quelle.

Speicherung und Format

  • Objektstorage on-prem (z.B. Ceph oder MinIO), kein reines NFS für große Volumina.

  • Tabellenformat (Iceberg/Delta) auf allen Silver-/Gold-Bereichen: ACID, Schemaevolution, Partitionierung, Time Travel, Deletes/Upserts.

  • Layout-Standards: einheitliche Partitionierung (z.B. by plant_id/date), eindeutige Business Keys, technische Metadaten (Erzeuger, Version).

Transform und Orchestrierung

  • Reproduzierbare Pipelines in Spark/Flink/DuckDB/SQL, orchestriert via Airflow/Argo Workflows.

  • Datenqualitätschecks (z.B. Great Expectations) als „Gate“ vor Promotion nach Silver/Gold.

  • Lineage-Erfassung (OpenLineage) für vollständige Nachvollziehbarkeit.

Katalog, Verträge, Governance

  • Data Catalog/Discovery (z.B. DataHub/Amundsen/Marquez) on-prem, verbunden mit Lineage und Qualitätssignalen.

  • Datenverträge: Schema plus Semantik, Qualitäts-SLOs (z.B. Freshness, Fehlerquote), SLAs für Löschung/Retention.

  • Policy-Engine (z.B. OPA) und IAM (z.B. Keycloak) für rollen- und attributbasierte Zugriffe, inkl. Spaltenmaskierung und Zeilenfilter.

Warehouse-Ebene

  • Materialisierte, BI-fähige Sichten für Controlling/Qualität – die Gold-Schicht treibt diese Materialisierungen.

  • Query-Engine (Trino) erlaubt Federation: Lakehouse, Warehouse, relationale Systeme unter einem SQL-Dach.

Dieses Schichtenmodell vermeidet das Anti-Pattern „S3 als dump & hope“ und macht Lake, Mesh und Warehouse komplementär nutzbar.

3) Datensouveränität und DSGVO: technische Maßnahmen, nicht nur Policies

„DSGVO-konform“ ist kein Label, sondern eine Kette technischer Eigenschaften. Relevante Bausteine:

  • Datenminimierung und Zweckbindung
  • Feature Selektion früh: im Edge- oder Ingest-Schritt irrelevante personenbezogene Daten konsequent abschneiden.
  • Pseudonymisierung vor Persistenz: Hash/Tokenisierung von IDs, Trennung der Zuordnung in einem separaten, stärker geschützten Tresor.
  • Jede Gold-Tabelle trägt ihren Zweck im Metadatenkatalog; Pipelines erzwingen Zweck-Durchsetzung durch explizite Promotions.
  • Löschbarkeit und Retention
  • Subjektbezogene Löschungen: Indexe über Subjekt-IDs, Iceberg/Delta „Delete“-Manifeste, periodische Compactions.
  • Versionierte Transformationsketten, damit Löschungen deterministisch durch alle Schichten propagieren.
  • Backup-/Archiv-Strategie mit Löschpfad: auch Snapshots müssen selektiv purged werden; WORM-Storage dort, wo gesetzlich geboten, aber mit dokumentierten Ausnahmeprozessen.
  • Zugriffskontrolle und Audit
  • Einheitliche Identität (Keycloak, ADFS-Integration), fein-granulare Policies (ABAC) bis auf Spaltenebene.
  • Trennung von Pflichten: Datenprodukt-Owner, Platform Owner, Security.
  • Vollständige Audit-Trails: wer hat wann welches Dataset genutzt; unveränderlich abgelegt (Write-Once-Mechanismen, Hash-Chains).
  • Kryptografie und Schlüsselverwaltung
  • BYOK/HSM, Schlüssellebenszyklen, Trennung von Daten und Schlüsseln, rotierende Schlüssel mit Re-Encryption-Jobs.
  • Transportverschlüsselung intern konsequent (mTLS), nicht nur am Perimeter.