• Einsatz, wenn:
  • Sie rechtssichere, harmonisierte KPIs brauchen (OEE, MTBF, Liefertreue).
  • Datenquellen überwiegend strukturiert und langsam veränderlich sind.
  • BI/Controlling im Vordergrund steht, und ML nur auf abgeleiteten, stabilen Features aufsetzt.
  • Architektur-Noten:
  • Staging → Core (3NF) → Marts (Star/Snowflake). CDC-Feeds aus ERP/MES. SCD Type 2 für Historisierung.
  • Data Vault kann helfen, bei oft wechselnden Quellschemata.
  • Für ML: Materialisieren Sie Feature-Snapshots per Batch aus Marts; akzeptieren Sie, dass sehr große Rohsensorik/Bilder außerhalb des Warehouses leben.
  • Grenzen:
  • Rohbilder, hochfrequente Sensorik und Text werden oft „gequetscht“ (BLOBs) oder ausgelagert. Für moderne CV/NLP-Workloads ist das unpraktisch.
  • Schema-Evolution ist teuer. ML-Iterationen leiden, wenn jedes neue Feature eine Modellierungslawine auslöst.

2) Data Lake/Lakehouse – der Arbeitsbereich für ML

  • Einsatz, wenn:
  • Sie breite Datentypen und hohe Volumina haben (Bild, Zeitreihen, Logs).
  • ML-Teams schnell neue Features bauen und reproducible Trainingsdaten frieren müssen.
  • Sie Batch/Stream kombinieren (Offline/Online-Features, Backfills).
  • Architektur-Noten:
  • Zonen: raw (immutable), structured/bronze, curated/silver, application/gold – mit klaren Promotion-Regeln.
  • ACID-Tabellenformat (Iceberg/Hudi/Delta) auf Object Storage; Trino/Spark als Abfrage-/Transformationslayer.
  • Stream-zu-Lake: Upserts/Merges aus Flink in Iceberg-Tabellen, Change-Feeds für Downstream.
  • Für ML: Feature-Views in Feast lesen offline aus Iceberg (Batch) und online aus Kafka/Redis/Postgres, strikt versioniert.
  • Grenzen:
  • Ohne starke Governance degeneriert ein Lake zum Datensumpf. Metadaten, Tests und Lineage sind nicht optional.
  • SQL-first-Teams brauchen Einarbeitung in Lakehouse-Patterns, sonst bleiben Silos.

3) Data Mesh – Skalierung über Domänen

  • Einsatz, wenn:
  • Mehrere Werke/Business Units eigenständig arbeiten, aber gemeinsame Plattformstandards akzeptieren.
  • Sie Bottlenecks eines zentralen Datenteams auflösen wollen.
  • Domänen bereit sind, Data Product Ownership inkl. Betrieb und SLAs zu übernehmen.
  • Architektur-Noten:
  • Zentrale Plattform: Identity/Access, Storage, Streaming, K8s, Katalog, Observability, CI/CD – als Self-Service.
  • Domänen betreiben Data Products als Versionierte Artefakte: Daten, Code, Schemata, Tests, Dokumentation.
  • Produktverträge definieren Input/Output-Schemata, Qualitäts-SLOs, Update-Kadenz, Rückwärtskompatibilität.
  • Governance ist leichtgewichtig, aber verpflichtend: Gatekeeping via Pipelines und Policies, nicht via Meetings.
  • Grenzen:
  • Ohne starken Plattform-Backbone wird Mesh zu föderiertem Chaos. Starten Sie klein (2–3 Domänen), nicht unternehmensweit „Big Bang“.
  • Erfordert Seniorität in den Domänen; „Data Product Owner“ ist kein Nebenjob.

Industrie-Use-Case: Visuelle Qualitätskontrolle in vier Werken

Problem: Vier Werke, unterschiedliche Kameras, wechselnde Beleuchtung, variierende Taktzeiten. Ziel: Ein CV-Modell, das Fehlerklassen robust erkennt, plus Nachvollziehbarkeit für Reklamationen.

  • Warehouse-Variante:
  • Sinnvoll für KPI-Reporting (Ausschussquoten, Schichtvergleich). Bilder bleiben extern, nur Referenzen im DWH.
  • Training muss Daten außerhalb des DWH beziehen, Feature-Engineering ist entkoppelt. Audits über zwei Welten hinweg.
  • Lakehouse-Variante:
  • Rohbilder + Metadaten im Lake (raw), kuratierte Datasets mit Labeln/Bounding Boxes als Iceberg-Tabellen.
  • Trainingssets sind reproduzierbar per Snapshot-ID. Serving-Features (z. B. Lichtintensität, Liniengeschwindigkeit) aus Stream in Online-Store.
  • Audit: Lineage verbindet Claim → Bild → Label → Modellversion → Trainingsset-Snapshot.
  • Mesh-Variante:
  • Jedes Werk liefert ein „Vision Data Product“ mit standardisiertem Metadatenschema (Optik, Kamera-ID, Kalibrierung) und Qualitäts-SLOs (Anteil fehlerhafter Bilder < x%).
  • Zentrales ML-Team konsumiert die Data Products, trainiert ein globales Modell plus werksspezifische Adaptionen.
  • Governance: Versionsverträge und Test-Suites stellen sicher, dass ein Werkswechsel nicht das Trainingsset bricht.

Entscheidungsrahmen: Wählen Sie bewusst – oder kombinieren Sie

Stellen Sie sich die folgenden Fragen. Ihre Antworten mappen auf Muster oder Hybrid:

  • Ist die primäre Anforderung „eine Wahrheit“ für KPIs/Reports? → Starten Sie mit einem robusten Warehouse, bauen Sie Lakehouse als Rohdaten-/ML-Schicht daneben.
  • Sind un-/halbstrukturierte und hochvolumige Daten zentral (Bilder, Zeitreihen, Logs)? → Lakehouse ist Pflicht. Warehouse wird Downstream-Konsument für Business-Views.
  • Haben Sie 3+ Domänen/Standorte mit echter Eigenständigkeit und motivierten Data Product Ownern? → Planen Sie Mesh als Organisationsform – aber erst, wenn die Plattformgrundlagen sitzen.
  • Müssen Sie streng on-prem/air-gapped arbeiten? → Vermeiden Sie externe Abhängigkeiten, setzen Sie auf Open-Source-fähige On-Prem-Komponenten, sichern Sie Artefakt-Repositories und bauen Sie Replikationspfade bewusst (Pull, signiert, auditiert).
  • Ist LLM-Nutzung (z. B. Wartungsassistent, SOP-Q&A) im Scope? → Planen Sie RAG-Pipelines on-prem, Vektorstore lokal, Prompt-/Output-Logs mit PII-Redaktion und Policy-Gates. Ohne Observability und Governance laufen Sie in Haftungsrisiken.

On-Prem-Umsetzung: Praktische Hinweise

  • Kubernetes als Standardisierungsanker: Vereinheitlicht Deployment, Isolation (Namespaces/NetworkPolicies), Quotas, Upgrades. Air-gapped? Spiegeln Sie Container-Registries lokal, signieren Sie Artefakte.
  • Objektstorage ernst nehmen: Verfügbarkeit (Erasure Coding), Throughput (Multi-Node), Lifecycle-Policies (WORM für Audit-Logs, TTL für Rohdrops), Schlüsselverwaltung mit HSM.
  • Datenverträge vor Datenmengen: Bevor Terabytes rollen, definieren Sie Schemata, Qualitäts-SLOs und Backward-Kompatibilität. Automatisieren Sie Contract-Tests in CI/CD, blockieren Sie Deployments bei Bruch.
  • Streaming nicht überziehen: Viele Probleme sind Batch-Probleme mit SLAs im Minutenbereich. Stream ist dort sinnvoll, wo Sie Online-Features, Event-getriebene Reaktionen oder CDC-Kaskaden brauchen.
  • Lakehouse-Tabellenformat wählen und durchziehen: Iceberg, Hudi oder Delta – aber konsistent. Mischen führt zu Reibung.
  • Lineage sichtbar machen: Entwickler sehen, welche Pipelines ein Dataset speisen und wen ein Schemawechsel bricht. Das verhindert Stillstand vor Go-Lives.
  • DSGVO-by-Design:
  • Pseudonymisierung: Token-Vault mit kontrolliertem Re-Ident-Zugang, Trennung von Schlüsseln und Daten.
  • Zweckbindung als Policy: Attribut am Access-Token; Queries ohne gültigen Zweck werden abgelehnt/loggt.
  • Löschwege planen: Identifizierbare Daten versioniert, aber mit Löschfangnetzen (Tombstones) und Re-Build-Mechanismen für abgeleitete Datasets.