Data Mesh vs. Data Silo: Die föderierte Infrastruktur für das moderne Unternehmen

Das klassische Modell des „Data Lake" ist gescheitert. Unternehmen haben Millionen in Infrastruktur investiert, um Daten an einem Ort zu sammeln, nur um festzustellen, dass diese Daten dort „verrotten", weil der Kontext fehlt. Das Data Mesh bricht mit diesem Paradigma: Statt Daten in einen zentralen See zu schütten, verbleiben sie dort, wo sie entstehen – in der Verantwortung der jeweiligen Fachdomäne (z. B. Logistik, Sales, Produktion).

Technisch gesehen wandelt sich die Infrastruktur von einer monolithischen Speicherarchitektur hin zu einer dezentralen Microservice-Architektur für Daten.

Die 4 Säulen des Data Mesh (Technischer Fokus)

1. Domain-Oriented Decentralized Data Ownership

Jede Fachabteilung betreibt ihre eigenen Daten-Infrastrukturen innerhalb des Firmen-Clusters. Die Logistik-Abteilung verwaltet ihre eigenen SQL-Instanzen, S3-Buckets und Kafka-Topics.

• Infrastruktur-Impact: Wir nutzen Kubernetes Namespaces und Resource Quotas, um jeder Domäne eine isolierte, aber standardisierte Umgebung bereitzustellen.

2. Data as a Product

Daten sind kein Abfallprodukt, sondern ein Produkt, das über definierte Schnittstellen (APIs) „verkauft" wird. Jedes Datenprodukt muss auffindbar, adressierbar, vertrauenswürdig und interoperabel sein.

• Technik: Jedes Datenprodukt erhält einen Sidecar-Container (ähnlich einem Service Mesh), der sich um Logging, Tracing und die Zugriffskontrolle kümmert. Daten werden über standardisierte Formate wie Apache Iceberg oder Delta Lake bereitgestellt.

3. Self-Serve Data Platform

Damit nicht jede Fachabteilung ein eigenes Data-Engineering-Team braucht, stellt das zentrale IT-Team (z.B. ayedo) eine Plattform bereit, die Tools zur Verfügung stellt.

• Komponenten: Automated Provisioning von Datenbanken via Infrastructure as Code (Terraform/Crossplane), standardisierte CI/CD-Pipelines für Daten-Transformationen (dbt) und ein globales Monitoring.

4. Federated Computational Governance

Dies ist der schwierigste Teil: Wie stellen wir sicher, dass dezentrale Daten zusammenpassen? Die Governance wird im Code automatisiert („Computational").

• Technik: Globale Standards für IDs (z.B. Kunden-IDs) und Sicherheitsrichtlinien (DSGVO) werden über Open Policy Agent (OPA) im gesamten Mesh erzwungen. Wenn ein Domänen-Team Daten ohne Verschlüsselung freigeben will, blockiert die Plattform dies automatisch.

Der “Data Product Container”: Das technische Herzstück

Ein Datenprodukt im Data Mesh ist mehr als nur eine Tabelle. Es ist ein Verbund aus:

• Code: Die Pipelines (z.B. Python/Spark), die die Rohdaten verarbeiten.
• Daten & Metadaten: Der eigentliche Inhalt sowie Beschreibungen, Herkunft (Lineage) und Schema-Definitionen.
• Infrastruktur: Die zugrundeliegenden Ressourcen (Storage, Compute), auf denen der Code läuft.

Durch die Kapselung dieser drei Elemente in einer standardisierten Einheit (dem Container) können Datenprodukte über Domänengrenzen hinweg konsumiert werden, ohne dass das zentrale Team intervenieren muss.

Herausforderung: Die technische Vernetzung

Um ein funktionales Data Mesh zu betreiben, implementieren wir eine Data Fabric als technisches Bindegewebe:

1. Event-Driven Backbone: Ein unternehmensweites Kafka- oder Redpanda-Cluster, das den Echtzeit-Datenaustausch zwischen den Domänen ermöglicht.
2. Schema Registry: Ein zentraler Dienst, der sicherstellt, dass die Datenstrukturen (Avro/Protobuf) über alle Domänen hinweg kompatibel bleiben.
3. Global Data Catalog: Ein automatisierter Katalog (z.B. DataHub oder Amundsen), der per Crawler alle dezentralen Datenprodukte erfasst und für Analysten suchbar macht.

FAQ: Data Mesh Deep-Dive

Ist Data Mesh nicht nur eine Ausrede für neue Datensilos? Nein. Silos entstehen durch mangelnde Interoperabilität und fehlende Standards. Das Data Mesh erzwingt durch die “Federated Governance” globale Standards. Die Daten sind dezentral gespeichert, aber zentral auffindbar und kombinierbar.

Welche Rolle spielt GraphQL im Data Mesh? GraphQL eignet sich hervorragend als “Unified API Layer”. Man kann ein föderiertes Schema aufbauen, bei dem eine Abfrage Daten aus verschiedenen Domänen-Produkten zusammenführt, ohne dass der Nutzer wissen muss, wo diese physisch liegen.

Wie verhindern wir doppelte Datenhaltung (Storage Costs)? Im Data Mesh gilt: “Storage is cheap, brain power is expensive.” Eine gewisse Redundanz wird in Kauf genommen, um die Autonomie der Teams zu wahren. Die Kosteneffizienz kommt durch die Vermeidung von Fehlern und die drastisch verkürzte Zeit für die Datenbereitstellung.

Was ist der Unterschied zwischen Data Mesh und einem Data Fabric? Data Mesh ist primär ein organisatorisches und architektektonisches Konzept (Domänenfokus). Data Fabric ist die technologische Implementierung (Tools, Automatisierung, Metadaten-Management), die das Mesh erst möglich macht.

Brauchen wir für Data Mesh zwingend Kubernetes? Nicht zwingend, aber es ist das ideale Betriebssystem dafür. Die Fähigkeit, Ressourcen deklarativ zu beschreiben und über Namespaces sauber zu trennen, macht die Verwaltung eines komplexen Meshes erst handhabbar.