Real-Time Data Mesh — Streaming-Datenarchitektur für Enterprise

Zentralisierte Data Warehouses und Data Lakes haben die Enterprise-Welt zwei Jahrzehnte lang bedient. Doch in einer Zeit, in der das Business Echtzeit-Entscheidungen verlangt, reicht eine monolithische Datenarchitektur nicht mehr aus. Real-Time Data Mesh ist die Antwort — und kein leeres Schlagwort.

Was ist Data Mesh und warum Real-Time¶

Data Mesh ist ein Architekturparadigma, das die Datenverantwortung von einem zentralen Datenteam zu den Domänenteams verlagert, die die Daten produzieren und am besten verstehen. Zhamak Dehghani stellte das Konzept 2019 vor, aber erst in den letzten zwei Jahren haben wir die Werkzeuge und Erfahrung gewonnen, um es mit einer Streaming-Schicht umzusetzen.

Warum Real-Time? Weil Batch-ETL mit täglicher Verzögerung für eine wachsende Zahl von Anwendungsfällen unzureichend ist. Betrugserkennung, Echtzeit-Personalisierung, Supply-Chain-Monitoring, operative Dashboards — alle erfordern Daten im Sekundenbereich, nicht im Stundenbereich.

Die 4 Prinzipien von Data Mesh¶

• Domain Ownership: Jedes Team besitzt seine Daten End-to-End — von der Produktion über die Qualität bis zur Veröffentlichung. Marketing besitzt Marketingdaten, Logistik besitzt Logistikdaten.
• Data as a Product: Daten sind kein Nebenprodukt von Anwendungen, sondern ein erstklassiges Produkt. Sie haben SLAs, Dokumentation, semantische Versionierung und einen Eigentümer.
• Self-Serve Data Platform: Das Infrastrukturteam stellt eine Plattform bereit, die es Domänenteams ermöglicht, Datenprodukte zu veröffentlichen und zu konsumieren, ohne tiefes Kafka- oder Flink-Wissen zu benötigen.
• Federated Computational Governance: Globale Regeln (Namenskonventionen, Sicherheit, Interoperabilität) werden automatisiert durchgesetzt, aber die Entscheidungsbefugnis verbleibt bei den Domänen.

Die Real-Time-Streaming-Schicht¶

Das Herzstück eines Real-Time Data Mesh ist die Streaming-Plattform. In der Praxis bedeutet das:

• Apache Kafka als zentraler Event-Bus — jede Domäne veröffentlicht ihre Events in eigene Topics
• Apache Flink für Stream-Processing — Transformationen, Aggregationen, Windowing in Echtzeit
• Debezium CDC (Change Data Capture) — erfasst Änderungen in bestehenden Datenbanken und veröffentlicht sie als Events, ohne Eingriff in den Anwendungscode

Topic-Namenskonventionen sind entscheidend für die Governance. Wir verwenden das Format:

<domain>.<entity>.<version>.<event-type>

# Beispiele:
logistics.shipment.v2.status-changed
billing.invoice.v1.created
crm.customer.v3.profile-updated

Datenverträge — Grundlage der Interoperabilität¶

Jedes Datenprodukt muss einen expliziten Vertrag haben. Wir definieren ihn als YAML und versionieren ihn in Git zusammen mit dem Domänencode:

# data-contract.yaml
domain: logistics
product: shipment-events
version: "2.1"
owner: logistics-team@core.cz
sla:
  freshness: 30s
  availability: 99.9%
schema:
  type: avro
  registry: https://schema-registry.internal/logistics/shipment/v2
fields:
  - name: shipment_id
    type: string
    pii: false
  - name: status
    type: enum
    values: [created, in_transit, delivered, returned]
  - name: updated_at
    type: timestamp
    description: "ISO 8601, always UTC"

Vergleich mit zentralisierter Architektur¶

Aspekt	Zentralisiertes DWH/Lake	Real-Time Data Mesh
Latenz	Stunden bis Tage	Sekunden
Datenverantwortung	Zentrales Team	Domänenteams
Team-Skalierung	Engpass beim Datenteam	Unabhängige Skalierung
Governance	Top-down, manuell	Föderiert, automatisiert
Onboarding neuer Quellen	Wochen (ETL-Entwicklung)	Tage (Self-Serve)

Praktische Erfahrungen und Empfehlungen¶

Nach mehreren Enterprise-Implementierungen haben wir ein klares Bild davon, was funktioniert:

Klein anfangen. Ein Data Mesh entsteht nicht über Nacht. Wählen Sie 2-3 Domänen mit einem klaren Real-Time-Anwendungsfall und bauen Sie die Plattform iterativ auf.

In die Plattform investieren, nicht in Pipelines. Der häufigste Fehler ist der Aufbau individueller Streaming-Pipelines für jede Domäne. Bauen Sie stattdessen eine Self-Serve-Plattform mit Templates, CI/CD für Datenverträge und automatischer Kafka-Topic-Bereitstellung.

Schema Registry ist Pflicht. Ohne eine zentrale Schema Registry mit Kompatibilitätsregeln (Backward/Forward Compatibility) zerfällt Ihr Mesh bei der ersten Breaking Change.

Observability vom ersten Tag an. Jedes Datenprodukt muss Metriken haben: Lag, Durchsatz, Fehlerrate, Freshness. Wenn Sie nicht wissen, dass Daten mit Verzögerung fließen, haben Sie keine Echtzeit-Architektur — Sie haben eine Illusion.

Real-Time Data Mesh ist nicht einfach. Aber für Organisationen mit mehr als 5 Datendomänen und wachsenden Anforderungen an die Datengeschwindigkeit ist es eine Investition, die sich innerhalb von Monaten auszahlt.

Unsere Erfahrung: Data Mesh für eine Retail-Gruppe¶

Für eine Retail-Gruppe haben wir eine Data-Mesh-Architektur mit einer Real-Time-Streaming-Schicht implementiert. Konkrete Ergebnisse:

• 8 Domänenteams — jedes mit Ownership über seine Datenprodukte und Self-Serve-Zugang zur Plattform
• Kafka-basierte Datenprodukte + Datahub-Katalog — zentrale Discovery und Governance über föderierte Daten
• Time-to-Insight von 3 Wochen auf 2 Tage — Self-Serve-Zugang eliminierte den Engpass beim zentralen Datenteam
• Data Quality Score von 72 % auf 96 % — automatisierte Qualitätsprüfungen als Bestandteil der Datenverträge
• Self-Serve-Adoption 80 % in 6 Monaten — Domänenteams veröffentlichen und konsumieren aktiv Datenprodukte