Real-Time Data Mesh — streamovací datová architektura pro enterprise

Centralizované datové sklady a data lakes sloužily enterprise světu dvě dekády. Ale v éře, kdy business vyžaduje rozhodování v reálném čase, monolitická datová architektura nestačí. Real-time data mesh je odpovědí — a není to jen buzzword.

Co je Data Mesh a proč real-time¶

Data Mesh je architektonický paradigma, který posouvá vlastnictví dat z centrálního datového týmu ke doménovým týmům, které data vytvářejí a rozumějí jim nejlépe. Zhenzhong Dehghani tento koncept představila v roce 2019, ale teprve v posledních dvou letech jsme získali nástroje a zkušenosti, abychom ho implementovali se streaming vrstvou.

Proč real-time? Protože batch ETL s denním zpožděním je pro rostoucí počet use cases nedostatečný. Fraud detection, real-time personalizace, supply chain monitoring, operativní dashboardy — všechny vyžadují data v řádu sekund, ne hodin.

4 principy Data Mesh¶

• Domain ownership: Každý tým vlastní svá data end-to-end — od produkce přes kvalitu až po publikaci. Marketing vlastní marketingová data, logistika vlastní logistická data.
• Data as a product: Data nejsou vedlejší produkt aplikací, ale první třída produktů. Mají SLA, dokumentaci, sémantické verzování a vlastníka.
• Self-serve data platform: Infrastrukturní tým poskytuje platformu, která doménovým týmům umožňuje publikovat a konzumovat datové produkty bez nutnosti rozumět Kafce nebo Flinku do hloubky.
• Federated computational governance: Globální pravidla (naming konvence, bezpečnost, interoperabilita) jsou automatizovaně vynucována, ale rozhodovací pravomoc zůstává u domén.

Real-time streaming vrstva¶

Srdcem real-time data mesh je streaming platforma. V praxi to znamená:

• Apache Kafka jako páteřní event bus — každá doména publikuje své eventy do vlastních topiců
• Apache Flink pro stream processing — transformace, agregace, windowing v reálném čase
• Debezium CDC (Change Data Capture) — zachytává změny v existujících databázích a publikuje je jako eventy, bez zásahu do aplikačního kódu

Konvence pojmenování topiců je klíčová pro governance. Používáme formát:

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

# Příklady:
logistics.shipment.v2.status-changed
billing.invoice.v1.created
crm.customer.v3.profile-updated

Datové kontrakty — základ interoperability¶

Každý datový produkt musí mít explicitní kontrakt. Definujeme ho jako YAML a verzujeme v gitu spolu s kódem domény:

# data-contract.yaml
domain: logistics
product: shipment-events
version: "2.1"
owner: [email protected]
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"

Srovnání s centralizovanou architekturou¶

Aspekt	Centralizovaný DWH/Lake	Real-Time Data Mesh
Latence	Hodiny až dny	Sekundy
Vlastnictví dat	Centrální tým	Doménové týmy
Škálování týmů	Bottleneck na datovém týmu	Nezávislé škálování
Governance	Top-down, manuální	Federated, automatizovaná
Onboarding nového zdroje	Týdny (ETL development)	Dny (self-serve)

Praktické zkušenosti a doporučení¶

Po několika enterprise implementacích máme jasno v tom, co funguje:

Začněte malým. Nevznikne data mesh přes noc. Vyberte 2-3 domény s jasným real-time use case a vybudujte platformu iterativně.

Investujte do platformy, ne do pipeline. Nejčastější chyba je budovat custom streaming pipeline pro každou doménu. Místo toho postavte self-serve platformu s šablonami, CI/CD pro datové kontrakty a automatickým provisioningem Kafka topiců.

Schema registry je povinná. Bez centrální schema registry s kompatibilními pravidly (backward/forward compatibility) se vám mesh rozpadne při prvním breaking change.

Observability od prvního dne. Každý datový produkt musí mít metriky: lag, throughput, error rate, freshness. Pokud nevíte, že data proudí se zpožděním, nemáte real-time architekturu — máte iluzi.

Real-time data mesh není jednoduchý. Ale pro organizace s více než 5 datovými doménami a rostoucími požadavky na rychlost dat je to investice, která se vrátí v řádu měsíců.

Naše zkušenost: Data mesh pro retailovou skupinu¶

Pro retailovou skupinu jsme implementovali data mesh architekturu s real-time streaming vrstvou. Konkrétní výsledky:

• 8 doménových týmů — každý s vlastnictvím nad svými datovými produkty a self-serve přístupem k platformě
• Kafka-based datové produkty + Datahub katalog — centrální discovery a governance nad federovanými daty
• Time-to-insight z 3 týdnů na 2 dny — self-serve přístup eliminoval bottleneck na centrálním datovém týmu
• Data quality score z 72 % na 96 % — automatizované quality checks jako součást datových kontraktů
• Self-serve adoption 80 % za 6 měsíců — doménové týmy aktivně publikují a konzumují datové produkty