2) Storage- und Tabellen-Schicht

  • Objekt-Storage On-Prem (S3-kompatibel, z. B. Ceph) als kosteneffiziente Basis.

  • ACID-Tabellenformate auf dem Lake für:

  • Upserts/Merges (z. B. CDC aus ERP/MES).

  • Time-Travel für reproduzierbare Trainingsläufe.

  • Schema-Evolution mit Constraints.

  • Partitions- und Clustering-Strategie anhand Zugriffspfaden (zeit-, anlagen-, linienbasiert). Small-File-Vermeidung via Kompaktionen.

  • Layering:

  • Bronze: Rohdaten, append-only, minimal normalisiert.

  • Silver: Bereinigt, harmonisiert, einheitenkorrigiert, mit stabilen Keys.

  • Gold: Domänenspezifische Datenprodukte mit SLAs; ML-Feature-Derivate und KPIs.

3) Metadaten, Katalog, Governance

  • Zentraler Katalog mit:

  • Datenprodukte, Eigentümer, Qualitätssignale, Datenverträge.

  • Technische/geschäftliche Lineage (von Topic/Datei über Tabellen bis zu Modellen).

  • Zugriffspolicies (Row-/Column-Level), Audit-Logs, Freigabe-Workflows.

  • Datenverträge als Code (Schema + Qualitätsregeln + SLAs versioniert im Git). CI-Checks blocken inkompatible Releases.

  • DSGVO-Mechanik:

  • Data Subject Map: Wo können PII sein? Welche Ableitungen existieren?

  • Lösch- und Sperr-Workflows: Deletion Vectors/Soft-Deletes auf Tabellenebene; Re-Materialisierung abhängiger Artefakte; “Right to be forgotten”-Nachweis via Audit.

4) Feature-Plattform

  • Einheitliche Definition von Features als Code (inkl. Berechnungslogik, Fensterung, Aggregationen).

  • Offline-Store auf Lakehouse-Tabellen (reproduzierbare Trainingssets).

  • Online-Store für Inferenz (ms-Lookups) – lokal pro Werk/Standort, synchronisiert asynchron aus Silver/Gold.

  • Point-in-Time-Korrektheit: Keine Leaks aus Zukunftsdaten bei Training; Join-Strategien über Event-Time + Wasserzeichen.

  • Drift-/Qualitätsmonitore pro Feature (Verteilung, Nullraten, Range, Korrelationen).

5) Compute, Orchestrierung, Reproduzierbarkeit

  • On-Prem Compute-Cluster (Kubernetes oder HPC-Scheduler) für:

  • ETL/ELT/Streaming-Jobs.

  • Trainingsläufe (GPU/CPU), Hyperparameter-Suchen.

  • Batch-Inferenz.

  • Artefakt- und Modell-Registry:

  • Modelle mit Verweis auf Daten-Snapshot-IDs, Feature-Versionen, Code-Commit.

  • Reproduzierbarkeit: gleicher Input -> gleiche Metriken.

  • Orchestrierung:

  • Workflow-Engine für DAGs (Abhängigkeiten Bronze->Silver->Gold->Feature->Training/Serving).

  • GitOps für Datenprodukte und Pipelines (Pull Requests, Reviews, Rollbacks).

6) Serving und Edge-Integration

  • CV/Anomalie-Modelle nahe an der Linie (Edge-Nodes mit GPU), harte SLOs; Stufen: Schattenmodus -> Canary -> Vollausrollung.

  • Batch-Inferenz für Planung/Optimierung im Backend; Ergebnisse als Gold-Tabellen zurück in Warehouse/KPIs.

  • LLM/RAG:

  • On-Prem Vektorsuche/Indexe über freigegebene Dokumente; Embeddings lokal generieren.

  • Zugriffskontrolle pro Dokument/Abschnitt; Schwärzung, Versionierung.

  • Agenten in kontrollierten Laufzeitumgebungen, mit Telemetrie, Policy-Checks und Audit. Alpi-M übernimmt Observability/Governance für solche LLM-Workloads.

7) Warehouse-Sidecar

  • Materialisierte Gold-Sichten für BI/Controlling/KPI – erzeugt aus Lakehouse-Tabellen per CTAS/ELT.

  • Kein doppeltes ETL. Eine Quelle der Wahrheit: Lakehouse. Warehouse ist Consumer mit klarer Domänenverantwortung.

Bereitstellungsmodell: Federiert statt chaotisch

  • Zentrale Plattform liefert:
  • Storage, Compute, Katalog, Identity/Access, Observability, CI/CD, Standard-Bibliotheken (Zeit, Einheiten, Keys).
  • Domänenteams liefern Datenprodukte:
  • Repositories pro Domäne, definierte Output-Tabellen/Topics, Qualitätssignale.
  • Versionierte Datenverträge. Abwärtskompatibilität ist Regel, Brüche sind Ausnahme und require Migration.
  • Hub-and-Spoke:
  • “Hub” ist das Lakehouse + Katalog.
  • “Spokes” sind Werke/Business-Domänen mit eigenem Takt, aber kompatiblen Standards.

Entscheidungsmatrix: Wann was?

  • Primär BI, klare relationale Schemata, wenig ML: Data Warehouse im Zentrum; Lake als Archiv für später.
  • ML-/DL-schwere Roadmap (CV, Zeitreihen, RAG), heterogene Daten: Lakehouse im Zentrum, Warehouse als Sidecar.
  • Viele autonome Werke/Domänen, Reife im Team: Mesh-Prinzipien auf Lakehouse, kein Tool-Only-Mesh.
  • Strenge Souveränität/DSGVO, sensible Daten, Air-Gap: On-Prem-Lakehouse, offene Formate, keine US-Cloud-Abhängigkeit.

Wesentliche Engineering-Details und Fallstricke

  • Partitionierung und Small Files:
  • Zeitbasierte Partitionen mit sinnvoller Körnung (Stunde/Tag je Volumen).
  • Automatische Kompaktionen, Write-Batching, Merge-Strategien für CDC.
  • Schema-Evolution:
  • Nur additive Änderungen ohne Migration. Brechende Änderungen via neue Tabelle/Version + deprecation.
  • Unit- und Contract-Tests im CI. Datenmigrationen wie Code behandeln.
  • Zeit und Ordnung:
  • Immer Event-Time speichern. Processing-Time nur für Monitoring.
  • Wasserzeichen für späte Events; Idempotenzschlüssel im Ingest.
  • Einheiten und Normalisierung:
  • Einheitliche, maschinenlesbare Einheiten. Konvertieren bei Ingest, Ursprung erhalten.
  • Identitäten:
  • Stabile Maschinen-/Komponenten-IDs; Mapping-Tabellen bei Upgrades.
  • Pseudonyme für Personenbezug. Hashes mit Salt; Re-Identifikationsrisiken aktiv minimieren.
  • Right to be forgotten:
  • Löschvorgänge transaktional. Deletion Vectors auf Tabellenebene.
  • Downstream-Artefakte (Features, Modelle, Indizes) re-materialisieren; Audit-Trail führen.
  • Reproduzierbarkeit:
  • Jeder Trainingslauf referenziert Data-Snapshot, Code-Commit, Feature-Version.
  • Deterministische Seeds, Containerisierte Läufe, fixierte Dependencies.
  • Drift-Überwachung:
  • Datendrift (Verteilungen), Konzeptdrift (Labels→Performance), Performancedrift (SLO).
  • Alerts an Domänenteams; automatisierte Canary-Rollbacks.
  • Edge-Resilienz:
  • Store-and-forward bei Netzabbrüchen.
  • Lokale Pufferung, Replays, Duplikatentfernung.

Migration in realistischen Schritten

1) Inventory und Domänenzuschnitt

  • Quellen erfassen: OT/IT, Datenarten, Volumina, Latenzen, Compliance-Klassen.

  • Domänen festlegen, erste Datenprodukte definieren, Datenverträge schreiben.

2) Minimal funktionsfähige Plattform (On-Prem)

  • Objekt-Storage, Katalog, Message-Bus, Orchestrierung, Identity/Access.

  • Bronze/Silver-Pfade, Quarantäne, Grund-Monitoring.

3) Proof-of-Value an je einem Use Case pro Domäne

  • Echte Ende-zu-Ende-Kette: Ingest → Lakehouse → Feature → Training → Serving → Monitoring → KPI.

  • Erfolgskriterien: Cycle Time von Datenänderung bis Modell-Update, Ausfallzeiten, Fehlerraten, Nachweis DSGVO-Löschrecht.

4) Feature-Plattform und Warehouse-Sidecar

  • Features als Code zentralisieren, Online/Offline splitten.

  • Gold-KPIs in Warehouse materialisieren; BI anschließen.

5) Skalierung und Federation

  • Mehr Domänen onboarden, Mesh-Prinzipien verstärken, Standards hart halten.

  • Technische Schulden regelmäßig tilgen: Kompaktionen, Archivierungspläne, Retention.

Souveränität als Leitplanke, nicht als nachträglicher Sticker