Data Mesh

Einfach erklärt

Das klassische Problem: Ein zentrales Data-Team verwaltet alle Daten des Unternehmens. Mit wachsender Größe wird dieses Team zum Engpass – jedes andere Team wartet auf Datenzugang, Pipelines und Analysen. Das Ergebnis: Monate Wartezeit für einen neuen Report, veraltete Daten, frustrierte Teams.

Data Mesh kehrt das um: Statt alle Daten zentral zu sammeln, bleiben sie bei den Teams, die sie erzeugen. Das Marketing-Team besitzt Marketing-Daten, das Produkt-Team Produkt-Daten. Jedes Team ist verantwortlich für Qualität, Dokumentation und Zugänglichkeit – Daten als Produkt.

Der Begriff wurde 2019 von Zhamak Dehghani (ThoughtWorks) geprägt und hat seitdem besonders in großen Tech-Unternehmen wie Netflix, Airbnb und Zalando Verbreitung gefunden.

Zentralisiert vs. Data Mesh:

Aspekt	Zentrales Warehouse	Data Mesh
Eigentümerschaft	Zentrales Daten-Team	Domänen-Teams
Skalierung	Bottleneck	Unabhängig
Qualitätsverantwortung	Zentrales Team	Produzierende Teams
Governance	Top-down	Federated
Time-to-Data	Wochen bis Monate	Tage

Technischer Deep Dive

Die vier Prinzipien im Detail

1. Domain-oriented Ownership Jede Geschäftsdomäne (Commerce, Marketing, Logistik) besitzt ihre Daten vollständig – von der Erfassung bis zur Bereitstellung. Das Team, das die Daten am besten versteht, ist auch für ihre Qualität verantwortlich.

2. Data as a Product Daten werden nicht als Nebenprodukt behandelt, sondern als echtes Produkt mit Nutzern, SLAs und Qualitätsstandards:

• Entdeckbar: Dokumentiert in einem Data Catalog
• Adressierbar: Stabile, versionierte Zugangspunkte
• Vertrauenswürdig: Definierte SLAs für Freshness und Availability
• Selbstbeschreibend: Schema, Lineage, Beispieldaten

3. Self-Serve Data Platform Eine zentrale Plattform stellt Infrastruktur bereit, die Teams befähigt, Datenprodukte ohne Spezialkenntnisse zu erstellen und zu betreiben – Storage, Processing, Catalog, Monitoring als Self-Service.

4. Federated Computational Governance Gemeinsame Standards (Formate, Sicherheit, Datenschutz) werden zentral definiert, aber dezentral ausgeführt. Kein Team muss auf Genehmigungen warten, solange es die Standards einhält.

Data Product Interface

# data-product.yaml – jedes Team definiert sein Datenprodukt
name: customer-orders
owner: commerce-team
domain: commerce
version: "2.1.0"

output_ports:
  - type: bigquery_table
    location: project.commerce.customer_orders
    schema: ./schema/orders.json
    sla:
      freshness: 1h
      availability: 99.9%

documentation:
  description: "Alle Kundenbestellungen seit 2020"
  data_dictionary: ./docs/orders.md
  sample_data: ./samples/orders_sample.json

Federated Governance

Zentrale Plattform definiert:
  ✓ Datenformate und Standards (Parquet, Avro)
  ✓ Sicherheits- und Datenschutzregeln (DSGVO-Compliance)
  ✓ Interoperabilitäts-Protokolle
  ✓ Qualitäts-Mindeststandards

Teams entscheiden selbst:
  ✓ Technologie-Stack (BigQuery, Snowflake, dbt)
  ✓ Interne Datenmodelle
  ✓ Pipeline-Implementierung
  ✓ Deployment-Frequenz

Data Mesh für KI und ML

Data Mesh ist besonders wertvoll für KI-Systeme in großen Organisationen:

ML-Team benötigt Features für Empfehlungsmodell:
  → Commerce-Team stellt customer_orders als Data Product bereit
  → Marketing-Team stellt user_behavior als Data Product bereit
  → ML-Team kombiniert beide ohne zentrale Pipeline-Anfragen

Feature Store als Data Product:
  → ML-Team veröffentlicht berechnete Features (user_embedding, purchase_propensity)
  → Andere Teams können diese Features konsumieren
  → Versioniert, dokumentiert, mit SLA

Typische Herausforderungen

• Kulturwandel: Teams müssen Dateneigentümerschaft als Verantwortung akzeptieren, nicht als Bürde
• Plattform-Investment: Eine Self-Serve-Plattform zu bauen kostet Zeit und Ressourcen
• Governance-Balance: Zu viele Regeln → zentralisierter Effekt; zu wenige → Chaos
• Datenqualität: Ohne zentrales Team kann Qualität inkonsistent werden – klare SLAs sind entscheidend