• Kernkomponenten (on-prem, S3-kompatibel, Kubernetes-basiert):
  • Objekt-Storage: MinIO oder Ceph RGW (S3-kompatibel), mit Bucket-Policies und Versionierung
  • Table-Format: Apache Iceberg oder Delta Lake für ACID, Schema-Evolution, Time-Travel
  • Compute: Kubernetes mit GPU-Nodes, NVIDIA Device Plugin, optional MIG für Partitionierung
  • Streaming: Kafka/Redpanda für Ereignisse und Zeitreihen-Streaming, Schema Registry (Avro/Protobuf)
  • Verarbeitung: Spark/Flink für Batch/Streaming; Dask als leichte Alternative
  • Orchestrierung: Airflow/Argo Workflows für DAGs, Argo Events für Trigger
  • Feature Store: z. B. Feast; Online-Store (Redis) für Echtzeit-Inferenz, Offline-Store (Iceberg/Parquet)
  • ML-Artefakt- und Modell-Registry: MLflow oder vergleichbar
  • Daten- und Metadaten-Katalog: Open-Source-Katalog plus Policies (z. B. OPA) oder Ranger
  • Datenqualität: Validierungs-Framework (z. B. Great Expectations) in CI/CD integriert
  • Versionskontrolle für Daten: LakeFS/DVC für Datasets und Reproduzierbarkeit
  • Zugriffssteuerung: RBAC, Row/Column-Level-Masking, Pseudonymisierungspipelines
  • Datenfluss (Bronze/Silver/Gold-Logik):
  • Ingestion (Bronze):
  • Edge-Connectoren erfassen Bilder/Video (Industriekamera), Zeitreihen (OPC UA/Modbus via Collector), Ereignisse (Maschinenzustände)
  • Speicherung roh in versionierten Buckets (WORM-Option für Audit) mit minimalen Metadaten
  • Kuratierung (Silver):
  • Vereinheitlichung von Zeitstempeln/Zeitzonen, Resampling, Synchronisation zwischen Kamera-Frames und Sensorwerten
  • Qualitätsprüfungen (Ausreißer, Lücken), automatische Pseudonymisierung/Maskierung bei PII (z. B. Mitarbeiter-ID in Logs, Gesichter in Video optional verpixelt)
  • Strukturiertes Ablegen in Iceberg/Delta-Tabellen (Partitionsschema: werk/jahr/monat/tag, zusätzlich by line_id, shift)
  • Feature-Build (Gold):
  • Feature-Engineering: z. B. Frequenzmerkmale, Rolling-Stats, Embeddings für Bilder
  • Schreiben in Feature Store (offline) mit Version/Timestamp
  • Materialisierung kritischer Features in Online-Store für Echtzeit-Inferenz
  • Training/Inference:
  • Trainingsjobs als containerisierte Pipelines (Argo), Datenzugriff über Snapshots (Iceberg time-travel), GPU-Ressourcen über K8s-Requests
  • Artefakte (Weights, Preprocessor, Config) in Registry; Hash-basierte Nachvollziehbarkeit
  • Deployment in Edge- oder Zonen-Cluster mit Canary/Rollback; Modelle mit Signaturen
  • Governance/DSGVO:
  • Pseudonymisierung so früh wie möglich (am besten im Edge-Collector); Schlüsselverwaltung on-prem (HSM/Key Vault)
  • Zweckbindung in Katalog dokumentiert; Freigaben in CI/CD-Gates
  • Lineage über Ingestion→Feature→Modell→Inference nachverfolgbar
  • Audit-Logs unveränderbar (WORM, Append-only Topics)

Dieses Pattern passt zu Qualitätsinspektion, Anomalieerkennung, prädiktiver Instandhaltung mit hohem Medienanteil.

5) Architekturpattern B: Warehouse-zentriert mit Lake-Adjunct

Ziel: Standardisierte KPI- und Compliance-Reports, Plan/Ist-Abgleiche, operative Dashboards – trotzdem ML-Anschluss halten.

  • Kernkomponenten:
  • Relationales Warehouse on-prem (z. B. Postgres/Greenplum/ClickHouse – je nach Abfrageprofil)
  • CDC aus Quellsystemen (Debezium/Log-basiert) in Kafka, ELT in Staging-Tabellen
  • Transformationen ins Star/Snowflake-Schema (dbt/Airflow)
  • Data Lake als Rohdatenablage/Archiv (Iceberg), optional Offload großer Tabellen
  • Datenqualität mit Tests auf Schema, Referenzintegrität, KPI-Definitionen als Code
  • ML-Anschluss:
  • Feature-Generierung aus Warehouse-Views, Replikation in Lake/Iceberg für Versionierung und Training
  • Modell-Scoring per Batch-Jobs, Ergebnisse zurück ins Warehouse für Reporting
  • Governance:
  • Strikte Business-Definitionen für Metriken als zentraler Artefakt-Bestand
  • Zugriffe über Rollen; PII-Spaltenmaskierung

Geeignet, wenn Reporting dominiert, aber erste ML-Projekte vorbereitet werden sollen.

6) Architekturpattern C: Data Mesh unter Souveränität

Ziel: Domänen (z. B. Fertigungslinie, Instandhaltung, Qualität, Logistik) verantworten „Data Products“, aber die Plattform bleibt einheitlich und souverän.

  • Prinzipien:
  • Vertrags- und schema-getriebene Schnittstellen (Avro/Protobuf), versioniert
  • Jede Domäne liefert kuratierte Data Products (z. B. timeseries_lineA_v2, defects_vision_v1) mit klaren SLOs
  • Zentrale Plattform stellt:
  • Einheitliche Identität/RBAC, Policy Enforcement (OPA/Ranger)
  • Katalog und Lineage
  • Self-Service-Ingestion und -Transformation (vorbereitete Templates, CI/CD)
  • Gemeinsames Storage- und Streaming-Backbone (kein „jeder betreibt seinen eigenen Kafka“)
  • Finanzierung/Operating-Modell: Domänen zahlen/planen Kapazitäten, Plattform liefert Standards
  • Fallstricke vermeiden:
  • Kein Mesh ohne starke Plattform – sonst nur verteiltes Chaos
  • Keine inkonsistenten Formate/Qualitätsniveaus je Domäne – Standards sind nicht optional
  • Messbare SLOs (Latenz, Aktualität, Datenqualität) pro Data Product

Dieses Pattern passt zu größeren Organisationen mit mehreren Werken/Standorten, die parallel skalieren müssen.

7) DSGVO und Datensouveränität: Technik, nicht nur Papier

In industriellen Daten sind oft personenbezogene Reste: Bediener-IDs in Logeinträgen, Badge-Events, Audio/Video von Arbeitsplätzen, Wartungsprotokolle mit Namen. DSGVO-Konformität ist eine technische Eigenschaft der Plattform:

  • Pseudonymisierung am Rand:
  • Mapping-Tabellen mit Einweg-IDs, Schlüsselmaterial on-prem, Zugriff streng limitiert
  • Wo möglich, Hashing/Salt und Aggregation statt Rohdaten
  • Datenminimierung:
  • Nicht jede Spalte überall; selektive Projektion früh in der Pipeline
  • Für CV: Gesichts-/Personenmaskierung bei Kameras im Produktionsumfeld
  • Zweckbindung und Einwilligungen:
  • Data Product beschreibt Zwecke; Freigaben werden in CI/CD Gate geprüft
  • Zweckänderungen → neue Versionen/Workflows, nicht stillschweigend
  • Auditierbarkeit:
  • Unveränderliche Log-Pfade (WORM-Buckets, Append-only Topics)
  • Lineage bis zum Modell-Output, inklusive verwendeter Feature-Sets und Codeversionen
  • Keine US-Cloud-Abhängigkeit:
  • On-Prem- oder souveräne Clouds; eigene Registries/Artifact Stores
  • Updates/Patches über kontrollierte Mirrors; kein „Phone-Home“ in Air-Gap-Zonen

Ohne diese Eigenschaften ist „KI in der Produktion“ rechtlich und betrieblich nicht tragfähig.

8) MLOps und Observability – von klassischem ML bis LLM-Agenten

Reproduzierbarkeit und Governance sind in der Industrie nicht „Nice-to-have“: