Data Lake vs Data Mesh vs Data Warehouse für industrielle KI: Was trägt, was bremst, und wie eine souveräne Architektur aussieht

Das eigentliche Problem ist nie “KI einführen”, sondern zuverlässig Daten in Produktionsqualität für konkrete ML-Aufgaben bereitzustellen – über Standorte, heterogene OT/IT-Systeme und regulatorische Grenzen hinweg. Wenn die Pipeline wackelt, sind Klassifikatoren nutzlos, Vorhersagen driftig und LLMs halluzinieren. Dieser Beitrag legt die Hypeschicht ab und beschreibt, welche Architekturbausteine sich in industriellen Umgebungen bewähren, wo Data Warehouse, Data Lake und Data Mesh passen – und wo sie schaden. Mit klarem Bias: Datensouveränität vor Bequemlichkeit, offene Formate vor Lock-in, On-Premise, wenn Datenlage und Recht es verlangen.

Ausgangslage: Industrielle Daten sind widerspenstig

Typische industrielle KI-Anwendungsfälle, die wir bauen:

  • Visuelle Qualitätskontrolle: Bilder/Video, inferierte Fehlertypen, harte Latenzbudgets am Band, hohe Varianz in Beleuchtung/Ausrichtung, Label-Drift durch Produktvarianten.

  • Predictive Maintenance: Zeitreihen (Schwingung, Strom, Temperatur), Ereignisse (Alarme), Langzeithistorie für seltene Ausfälle, Datenlücken, Sensorwechsel, unbalancierte Klassen.

  • Prozessoptimierung: Multimodale Daten – Rezepte, Prozessparameter, Energieprofile, OEE; Need für Feature-Zusammenführung über Linien und Schichten hinweg.

  • Technische Dokumentation/RAG/LLM: Unstrukturierter Text (PDF, CAD-Metadaten, Wartungshandbücher), Versionsstände, Rechte/Schwärzungen, Zugriff pro Rolle, kein Abfluss in US-Clouds.

Rahmenbedingungen:

  • Echtzeit- bis Near-Real-Time-Verarbeitung (ms–s) am Edge, Batch im Backend.

  • Jahrzehnte-Lebenszyklen der Maschinen, heterogene Protokolle (OPC UA/MQTT/Profinet/alte SPS).

  • DSGVO, Betriebsrat, Exportkontrolle; Audits und “Right to be forgotten” sind nicht verhandelbar.

  • Verteilte Standorte, Offline-Fähigkeit, Air-Gapped-Netze in Defense/Schienenfahrzeug/Avionik.

Vor diesem Hintergrund sind “Was nehmen wir? Warehouse, Lake, Mesh?” keine Glaubensfragen, sondern Architekturentscheidungen mit klaren Trade-offs.

Data Warehouse: Stark für Kennzahlen, schwach für rohe industrielle Vielfalt

Wofür es gebaut wurde:

  • Strukturierte, relationale Daten; konsolidierte Kennzahlen; OLAP; SCD-Handling; stabile, gut definierte Schemata.

Was funktioniert in der Industrie:

  • KPI-Reporting (OEE, Scrap Rate, MTBF/MTTR), Compliance-Reporting, Stammdaten-Harmonisierung (Artikel, Linien, Schichten).

  • SQL-first-Governance, ausgereifte Rechteverwaltung, Datenqualität mit klaren Constraints.

Wo es kippt:

  • Rohsensorik, Bilder/Video, Log-Streams – das landet als Blobs und entzieht sich den Stärken des Warehouses.

  • Hohe Ingest-Raten und schema-driftige Quellen erzeugen ETL-Hydras, die BI-lastig geprägte Teams überfordern.

  • ML-Training braucht Feature-Historien, Time-Travel, Point-in-Time-Joins, Wiederholbarkeit. In klassischen Warehouses ist das machbar, aber oft teuer und fragil.

  • Vendor-Lock-in droht schnell, gerade bei proprietären Sprachen/Engines.

Fazit: Ein Warehouse bleibt wichtig – aber als Sidecar für kaufmännische/operative Auswertungen, nicht als zentrales KI-Rohdatensilo.

Data Lake: Freiheit für Rohdaten – mit Governance-Schulden, die man aktiv tilgen muss

Wofür es gut ist:

  • Kostengünstige, skalierbare Ablage heterogener Daten: Zeitreihen, Bilder, Protokolle, Texte.

  • Schema-on-read erlaubt Wandel – neue Sensoren, neue Label, neue Featuredefinitionen.

  • Batch und Streaming lassen sich zusammenbringen, solange das Speichersubstrat und das Tabellensystem ACID und Schema-Evolution beherrschen.

Die Stolpersteine:

  • Ohne ACID-Tabellenformate droht Small-File-Hölle, inkonsistente Sichten, riskante Upserts.

  • “Selbstbedienung” wird schnell zum Swamp, wenn Datenverträge, Katalog und Zugriffskontrolle fehlen.

  • GDPR trifft Lake stärker: Time-Travel + Löschrecht = man braucht Deletions, Retention-Strategien, Re-Materialisierung von Derivaten.

  • Streaming + Out-of-Order-Events erfordert klar definierte Wasserzeichen und Idempotenz.

Fazit: Der Lake ist das richtige Rückgrat für industrielle KI – aber nur, wenn man ihn bewusst mit Transaktions- und Governance-Fähigkeiten zur Lakehouse-Plattform hochzieht.

Data Mesh: Organisationsprinzip, kein Tool – und teuer, wenn man es zu früh versucht

Idee:

  • Domänen besitzen Daten als Produkte, inkl. Qualität, Dokumentation, SLAs. Plattformteam stellt Infrastruktur und Standards.

Was daran im Industriekontext hilft:

  • Autonomie über Werke/Bereiche hinweg; Domänenwissen bleibt dort, wo es entsteht.

  • Skaliert Organisationen mit vielen voneinander abhängigen Datenquellen und Teams.

Die Schattenseite:

  • Mesh löst keine technischen Grundlagen. Man braucht trotzdem eine robuste Plattform: Storage, Compute, Katalog, CI/CD, Observability.

  • Governance wird schwieriger, wenn jede Domäne frei modelliert. Ohne harte Standards (Namenskonventionen, Zeitstempel, Einheiten, Identitäten) fragmentiert alles.

  • Für kleine bis mittlere Setups ist ein federiertes Lakehouse mit klaren Schnittstellen oft wirksamer als ein voll ausgeprägtes Mesh.

Fazit: Mesh “on top” eines Lakehouse, wenn mehrere Domänenteams parallel liefern. Nicht als Ausrede, eine gemeinsame Plattform zu vermeiden.

Die souveräne Zielarchitektur: Federiertes Lakehouse mit Feature-Plattform und Warehouse-Sidecar

Was wir in regulierten, verteilten Umgebungen aufbauen, grob in Schichten:

1) Ingestion-Schicht

  • Hot Path (Streaming):

  • Feldbus/OT: OPC UA-Subscriptions, MQTT, proprietäre Gateways. Sampling-/Publishing-Strategien sauber definieren (rate vs change, Deadband).

  • Ereignisbus: Kafka/ähnlich für hochvolumige Telemetrie, mit strikt versionierten Topics und Schemas.

  • Change Data Capture (CDC) aus MES/ERP per Debezium-ähnlichen Connectors. Idempotente Upserts, deduplizierende Keys.

  • Cold Path (Batch):

  • Historische Dumps (CSV/Parquet), Bilder/Video vom Edge, SFTP aus Altsystemen. Immer in Quarantäne-Landing-Zone, dann Validierung.

Qualitäts- und Compliance-Gates bereits beim Ingest:

  • Schema-Validierung und Evolution unter Kontrolle (Backward/Forward-Compatibility).

  • PII-Erkennung und -Handhabung: Spaltenschutz, Pseudonymisierung, Sensitivitäts-Tags.

  • Einheiten/Zeitzonen-Normalisierung; strikte UTC-Speicherung mit lokaler View bei Bedarf.

  • Idempotenz: Deduping über Event-IDs/Hashes, Replays ohne Doppelzählung.