Data Mesh a decentralizovaná datová architektura
Již více než třicet let se podniková datová architektura řídí gravitačním modelem: všechna data se shromáždila v jednom centrálním bodě spravovaném specializovaným týmem, který jednal jako úzké hrdlo pro celou organizaci. Monolitický datový sklad, datové jezero centralizované, dokonce i moderní datové jezero, které jsme prozkoumali v předchozím článku: všechny sdílejí stejný architektonický předpoklad, kterým je, že data musí být shromážděné, zpracovává a obsluhuje jeden tým.
Tento model fungoval poměrně dobře, pokud byly organizace malé, domény podniků bylo málo a objem dat byl zvládnutelný. Ale když se firma rozroste do desítky produktových týmů, stovky zdrojů dat a petabajtů informací, model centralizovaný systém se zhroutí vlastní vahou. Centrální datoví inženýři se stávají krkem láhve, fronty požadavků se prodlužují, dodací lhůty se měří na čtvrtiny spíše než v týdnech a kvalita dat klesá, protože ten, kdo je produkuje, za ně nenese odpovědnost.
v roce 2019 Zhamak Dehghani, pak konzultant v ThoughtWorks, formalizováno radikálně odlišné paradigma: Data Mesh. Toto není novinka technologie nebo nový nástroj, ale změna organizační a architektonické mentality která aplikuje principy Domain-Driven Design a platform thinking na svět dat. Data Mesh je pro svět dat tím, čím byly mikroslužby pro svět aplikací: decentralizace odpovědnosti řízená obchodními doménami.
Podle analýzy společnosti Gartner z roku 2024 zahájilo iniciativy 25 % velkých organizací Data Mesh a očekává se, že toto procento dosáhne 50 % do roku 2027. Trh datových sítí a platforem datových tkanin překročí v roce 2025 4,2 miliardy dolarů, se složenou roční mírou růstu (CAGR) 22 %.
Co se dozvíte v tomto článku
- protože centralizovaný datový model se neškáluje ve složitých organizacích
- Čtyři základní principy Data Mesh od Zhamaka Dehghaniho
- Jak mapovat DDD ohraničené kontexty na datové domény s konkrétními příklady
- Co je datový produkt a jak definovat datové smlouvy, SLA a metriky kvality
- Samoobslužná architektura platformy Self-Serve Data Platform
- Federated Computational Governance: politika jako kód a automatizovaná shoda
- Praktická implementace s kódem: datový kontrakt, dbt model, API a pipeline
- Srovnání mezi Data Mesh a Data Fabric se srovnávací tabulkou
- Skutečné případové studie: Zalando, Netflix, JPMorgan Chase, Intuit
- Výzvy, anti-vzory a kdy NEPŘIPOJIT Data Mesh
- Italský kontext: MSP, kulturní výzvy a příležitosti PNRR
Přehled datových skladů, AI a digitální transformace
| # | Položka | Soustředit |
|---|---|---|
| 1 | Vývoj datového skladu | Od SQL Serveru po Data Lakehouse |
| 2 | Jste zde – Data Mesh a decentralizovaná architektura | Decentralizovat data |
| 3 | ETL vs ELT v cloudu | Moderní datové kanály |
| 4 | AI a strojové učení pro firmy | Obchodní prediktivní modely |
| 5 | Analýza v reálném čase | Streamování a rozhodování v reálném čase |
| 6 | Kvalita dat a pozorovatelnost | Sledujte stav dat |
| 7 | PNRR a digitální transformace | Příležitosti pro italské malé a střední podniky |
| 8 | End-to-End praktický kufřík | Budování datového jezera od nuly |
Problém centralizovaných datových skladů
Před prozkoumáním datové sítě je nezbytné porozumět problému, který řeší. Modelka Centralizovaná data nejsou ze své podstaty špatná: Slouží podnikům dobře po celá desetiletí. Má však strukturální omezení, která se stávají neudržitelnými mimo určité organizační měřítko.
Úzké místo centrálního datového týmu
V typické organizaci s centralizovaným datovým skladem existuje jeden datový tým strojírenství (často 5-15 lidí) obsluhující celou společnost. Každý požadavek, od stvoření tímto týmem prochází nový kanál k nápravě anomálie kvality dat. Výsledek je předvídatelný: týdny dlouhé fronty, bolestivé stanovení priorit a rozšířená frustrace.
Ve společnosti s 20 produktovými týmy obdrží centrální datový tým v průměru 150–200 požadavků za čtvrtletí. S kapacitou dodání 30-40 úkolů za čtvrtletí, 80 % požadavků zůstat ve frontě. Doménové týmy, frustrované čekáním, začnou vytvářet stínová řešení: Excel exporty, lokální databáze, ad hoc skripty, které nikdo neudržuje.
Pět strukturálních problémů centralizovaného modelu
- Organizační problém: Omezujícím faktorem se stává centrální datový tým celé organizace. Každá nová funkce, která vyžaduje data, je vázána na jejich kapacitu.
- Únik kontextu domény: Centrální datoví inženýři neznají domény podnikání do hloubky. Pro každý nový plynovod musí vyzpovídat doménové experty a prohrávat kritické nuance v požadavcích na překlad.
- Široké vlastnictví: Kdo je zodpovědný za kvalitu prodejních dat? Prodejní tým, který je vyrábí, nebo datový tým, který je transformuje? V centralizovaném modelu odpověď je nejednoznačná a nejednoznačnost způsobuje degradaci.
- Architektonické spojení: Všechna potrubí se sbíhají ve stejném DWH, vytváření implicitních závislostí. Změna v datovém modelu domény „objednávky“ se může zlomit „logistika“, „finance“ a „marketing“ současně.
- Lineární škálovatelnost: Centralizovaný model se škáluje pouze přidáváním lidí do centrálního týmu. Ale Brooksův zákon nás učí, že přidání lidí do projektu v zpoždění jej dále zpomaluje kvůli nákladům na koordinaci.
Paradox centralizace
Paradoxem je, že čím více společnost investuje do centralizovaného datového skladu, tím více datového týmu se stává úzkým hrdlem, čím více doménových týmů hledá alternativní řešení, tím více dat fragmentují se do neovládaných sil. Centralizovaný model generuje problém, který tvrdí vyřešit. A to je kontext, ve kterém se Data Mesh zrodil: ne jako technologie, ale jako organizační reakce na organizační problém.
Čtyři základní principy datové sítě
Data Mesh, jak ji v roce 2019 formalizoval Zhamak Dehghani a do hloubky prozkoumal ve své knize „Data Mesh: Poskytování hodnoty řízené daty ve velkém měřítku“ (2022) je založeno na čtyřech principech základy, které je třeba přijmout Spolu. Naneste jednu bez kluzáků jiné vedou k neoptimálním nebo dokonce kontraproduktivním výsledkům.
Čtyři pilíře datové sítě
| Princip | Popis | Analogie |
|---|---|---|
| 1. Doménově orientované vlastnictví | Doménové týmy vlastní a spravují svá vlastní data | Stejně jako mikroslužby: každý tým vlastní svou vlastní službu |
| 2. Data jako produkt | S daty se zachází jako s produkty se SLA, kvalitou a dokumentací | Jako veřejné API: má smlouvu, verzování a podporu |
| 3. Samoobslužná datová platforma | Interní platforma, která snižuje náklady na produkci a spotřebu dat | Jako interní PaaS: automatické zřizování, šablony, zábradlí |
| 4. Federated Computational Governance | Automatizované řízení prostřednictvím politiky jako kódu, zaručená interoperabilita | Jako standardy a protokoly: HTTP pro web, datový kontrakt pro data |
Podívejme se podrobně na každý princip s konkrétními příklady a architektonickými důsledky.
Princip 1: Vlastnictví dat orientovaných na doménu
První princip Data Mesh obrací odpovědnost za data: již není centrálním týmem vlastnit všechna firemní data, ale každý doménový tým vlastní, vyrábí a obsluhuje vaše data. Tento princip je přímo inspirován Návrh řízený doménou (DDD) od Erica Evanse, zejména ke konceptu Ohraničený kontext.
Mapování ohraničených kontextů na datové domény
Ohraničený kontext v DDD je sémantická hranice, ve které má doménový model a přesný a jednoznačný význam. V datové síti se každý ohraničený kontext stává potenciálem datová doména s vaším týmem, vašimi daty a vašimi povinnostmi.
Vezměme si konkrétní příklad: středně velkou platformu elektronického obchodu. Zde je návod ohraničené kontexty jsou mapovány na datové domény:
Elektronický obchod: Mapování ohraničeného kontextu na datové domény
| Ohraničený kontext | Datová doména | Hlavní údaje o produktu | Majitel týmu |
|---|---|---|---|
| Katalog produktů | Katalog produktů | Produkty, kategorie, ceny, zásoby | Katalogový tým (4 vývojáři + 1 data eng) |
| Objednávky | Správa objednávek | Objednávky, Řádky objednávek, Stav objednávky | Tým objednávek (5 vývojářů + 1 datová eng) |
| Uživatelé | Zákazník | Uživatelské profily, Segmentace, Chování | Zákaznický tým (3 vývojáři + 1 data eng) |
| Platby | Platby | Transakce, odsouhlasení, podvody | Platební tým (4 vývojáři + 1 datová eng) |
| Logistika | Splnění | Doprava, sledování, vrácení | Logistický tým (4 vývojáři + 1 datový eng) |
| Marketing | Marketing | Kampaně, konverze, atribuce | Marketingový tým (3 vývojáři + 1 data eng) |
Všimněte si jednoho zásadního aspektu: každý tým má alespoň jeden vestavěný datový inženýr v doméně. Tato osoba není součástí centrálního týmu, ale je do týmu integrována domény a sdílí její kontext, priority a agilní ceremonie. A ten rozdíl zásadní ve srovnání s centralizovaným modelem.
Architektura datových domén
Každá datová doména v Data Mesh má dobře definovanou architektonickou strukturu. Podívejme se jak uspořádat jednu doménu:
+------------------------------------------------------------------+
| DATA DOMAIN: ORDINI |
+------------------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | Sorgenti Dati | | Servizi Applicat | |
| | - PostgreSQL | | - Order API | |
| | - Event Stream | | - Order Worker | |
| | - Legacy ERP | | - Notification | |
| +--------+---------+ +--------+---------+ |
| | | |
| v v |
| +------------------------------------------------+ |
| | Pipeline di Trasformazione | |
| | - Ingestione (CDC / Event Streaming) | |
| | - Pulizia e Validazione | |
| | - Aggregazione e Arricchimento | |
| +------------------------+-----------------------+ |
| | |
| v |
| +------------------------------------------------+ |
| | DATA PRODUCTS (Output) | |
| | | |
| | [1] ordini.fatto_ordini | |
| | - Tabella Iceberg Gold | |
| | - SLA: freshness 1h, completeness 99.5% | |
| | | |
| | [2] ordini.ordini_stream | |
| | - Kafka topic (real-time) | |
| | - SLA: latency <5s, availability 99.9% | |
| | | |
| | [3] ordini.metriche_giornaliere | |
| | - API REST / GraphQL | |
| | - SLA: response time <200ms | |
| +------------------------------------------------+ |
| |
+------------------------------------------------------------------+Tři typy datových produktů na doménu
Každá doména může vystavit svá data ve třech doplňkových formách, z nichž každá je optimalizovaná pro jiný vzorec spotřeby:
- Analytické tabulky (dávka): Tabulky Iceberg/Delta o úložišti objektů pro analytické dotazy a sestavy. Aktualizováno každou hodinu nebo denně.
- Stream události (v reálném čase): Kafkovo téma pro spotřebitele, kteří potřebují data v reálném čase. Ideální pro downstream potrubí a oznámení.
- API (On-demand): Koncové body REST nebo GraphQL pro konkrétní dotazy, řídicí panely a integrace aplikací. Odezvy s nízkou latencí.
Zásada 2: Data jako produkt
Druhý princip a možná nejvíce transformativní: zacházet s datovými soubory ne jako s vedlejšími produkty aplikací, ale jak produkty ve všech ohledechs životním cyklem, vlastní uživatelé, SLA a metriky kvality. Pokud první princip definuje „kdo“ (týmy doména), druhý definuje „co“ (datový produkt) a „jak“ (standardy kvality).
Vlastnosti datového produktu
Kvalitní datový produkt musí splňovat osm základních, často zmiňovaných charakteristik se zkratkou DATSIS+:
Osm charakteristik datového produktu
- Zjistitelné: Zaznamenáno v centrálním katalogu, který lze snadno najít vyhledáváním
- Adresovatelný: Přístupné prostřednictvím stabilní, standardizované adresy (URI)
- Důvěryhodný: Doplněno ověřitelnými metrikami kvality a definovanými smlouvami SLA
- Sebepopisující: Schéma, dokumentace a počet řádků jsou k dispozici bez dotazu výrobce
- Interoperabilní: Vyhovuje firemním standardům pojmenování, psaní a formátu
- Zajistit: Řízený přístup prostřednictvím zásad, šifrování a auditní stopy
- Cenný: Vytváří měřitelnou hodnotu pro spotřebitele (ne data pro data)
- včas: Aktualizováno s frekvencí deklarovanou v SLA, s monitorováním čerstvosti
Smlouva o datech: Smlouva mezi výrobcem a spotřebitelem
Srdcem principu „Data jako produkt“ je datová smlouva: dohoda formální a strojově čitelné mezi těmi, kdo data produkují, a těmi, kdo je konzumují. Smlouva o datech definuje schéma, SLA, vlastnictví, pravidla kvality a vývojové politiky. A ekvivalent API kontrakty ve světě mikroslužeb.
# data-contract.yaml - Contratto per il Data Product "Ordini"
# Formato basato su Data Contract Specification v0.9.3
# https://datacontract.com
dataContractSpecification: 0.9.3
id: urn:datacontract:ordini:fatto-ordini
info:
title: Fatto Ordini
version: 2.1.0
description: |
Tabella dei fatti contenente tutti gli ordini completati.
Aggiornata ogni ora con CDC dal database operazionale.
owner: team-ordini
contact:
name: Marco Rossi
email: marco.rossi@azienda.it
slack: "#team-ordini-data"
servers:
production:
type: iceberg
catalog: lakehouse
database: ordini
table: fatto_ordini
location: s3://data-lakehouse/ordini/fatto_ordini/
schema:
type: table
fields:
- name: ordine_id
type: bigint
required: true
unique: true
description: Identificativo univoco dell'ordine
pii: false
- name: cliente_id
type: integer
required: true
description: FK al dominio Customer
references: urn:datacontract:customer:dim-clienti.cliente_id
- name: data_ordine
type: timestamp
required: true
description: Timestamp di creazione dell'ordine (UTC)
- name: importo_totale
type: decimal(12,2)
required: true
description: Importo totale dell'ordine in EUR
checks:
- type: range
min: 0.01
max: 999999.99
- name: stato
type: string
required: true
description: Stato corrente dell'ordine
enum: [completato, annullato, rimborsato, in_lavorazione]
- name: canale
type: string
required: true
description: Canale di vendita
enum: [web, mobile_app, marketplace, pos]
- name: regione_cliente
type: string
required: false
description: Regione di residenza del cliente
quality:
type: SodaCL
specification:
checks for fatto_ordini:
- row_count > 0
- freshness(data_ordine) < 2h
- missing_percent(ordine_id) = 0
- missing_percent(importo_totale) = 0
- invalid_percent(importo_totale) < 0.1%:
valid min: 0.01
- duplicate_percent(ordine_id) = 0
- schema:
name: fatto_ordini_schema
warn:
when schema changes: any
sla:
freshness: 1h # Dati aggiornati entro 1 ora
availability: 99.5% # Uptime della tabella
completeness: 99.9% # Percentuale record completi
latency_p95: 5s # Tempo query P95
terms:
usage: |
Dati disponibili per analytics, reporting e ML.
Non utilizzare per comunicazioni dirette al cliente
senza consenso esplicito del dominio Customer.
retention: 7 anni (obbligo fiscale)
classification: internal
pii_fields: [cliente_id]
history:
- version: 2.1.0
date: 2025-12-01
changes: Aggiunto campo canale
- version: 2.0.0
date: 2025-06-15
changes: Breaking change - rinominato amount in importo_totaleTato datová smlouva není jen dokumentací: je to spustitelný artefakt. Nástroje governance může automaticky ověřovat data vůči smlouvě, blokovat nasazení které zavádějí neohlášené změny a generují upozornění v případě porušení SLA.
Schéma evoluce a verzování
Kritickým aspektem datových produktů je evoluční schéma: jak spravovat změny systému, aniž by došlo ke ztrátě spotřebitelů. Data Mesh přijímá stejné Strategie verzování API:
Strategie vývoje schématu
| Typ převodovky | Příklad | Strategie | lámání? |
|---|---|---|---|
| Přidán sloupec | Nové pole „kanál“. | Zpětně kompatibilní, přímé přidání | No |
| Volitelný sloupec | Od povinného po hodnotu nullable | Zpětně kompatibilní | No |
| Odstranění sloupce | Smazat "legacy_code" | Ukončení podpory 90 dní, poté odstranění | Ano (hlavní verze) |
| Změnit typ | Od řetězce k celému číslu | Nová hlavní verze + migrace | Ano (hlavní verze) |
| Přejmenování | Z "částka" na "celková_částka" | Dočasný alias + ukončení podpory | Ano (hlavní verze) |
Princip 3: Samoobslužná platforma datové infrastruktury
Třetí princip řeší praktickou otázku: zda decentralizujeme vlastnictví dat doménovým týmům, jak zabráníme tomu, aby každý tým znovu objevil kolo? Odpověď je jedna vnitřní samoobslužná platforma která poskytuje nástroje, šablony a automatizaci snížit kognitivní a provozní náklady na produkci a spotřebu datových produktů.
Samoobslužná datová platforma není přestrojený datový sklad: je to a platforma jako a produkt což umožňuje doménovým týmům fungovat autonomně a poskytovat infrastrukturu, nástroje a zábradlí bez zavedení centralizovaného modelu.
Platformová architektura
+============================================================================+
| SELF-SERVE DATA PLATFORM |
+============================================================================+
| |
| +---------------------------+ +---------------------------+ |
| | Data Product Builder | | Data Product Discovery | |
| | - Template pipeline | | - Data Catalog | |
| | - Schema registry | | - Search & Browse | |
| | - Contract generator | | - Lineage viewer | |
| | - CI/CD per dati | | - Quality dashboard | |
| +---------------------------+ +---------------------------+ |
| |
| +---------------------------+ +---------------------------+ |
| | Infrastructure Layer | | Governance Layer | |
| | - Compute provisioning | | - Policy engine | |
| | - Storage management | | - Access control (RBAC) | |
| | - Networking | | - Audit logging | |
| | - Monitoring & Alerts | | - Compliance checks | |
| +---------------------------+ +---------------------------+ |
| |
| +---------------------------+ +---------------------------+ |
| | Mesh Connectivity | | Observability | |
| | - Event bus (Kafka) | | - Data quality metrics | |
| | - API gateway | | - SLA monitoring | |
| | - Query federation | | - Cost tracking | |
| | - Cross-domain joins | | - Usage analytics | |
| +---------------------------+ +---------------------------+ |
| |
+============================================================================+Automatické poskytování s infrastrukturou jako kód
Platforma musí umožnit doménovému týmu vytvořit nový datový produkt pomocí několika příkazů, bez otevírání lístků do infrastruktury. Podívejme se na příklad s Terraformem:
# terraform/modules/data-product/main.tf
# Modulo Terraform per il provisioning di un Data Product
variable "domain_name" {
type = string
description = "Nome del dominio (es: ordini, catalogo)"
}
variable "product_name" {
type = string
description = "Nome del data product"
}
variable "owner_team" {
type = string
description = "Team responsabile"
}
variable "sla_tier" {
type = string
default = "standard" # standard | premium | critical
}
# Storage: bucket S3 dedicato per il dominio
resource "aws_s3_bucket" "data_product" {
bucket = "data-mesh-${var.domain_name}-${var.product_name}"
tags = {
Domain = var.domain_name
Product = var.product_name
Owner = var.owner_team
ManagedBy = "data-platform"
SLATier = var.sla_tier
}
}
# Iceberg: tabella registrata nel catalogo
resource "aws_glue_catalog_table" "iceberg_table" {
database_name = var.domain_name
name = var.product_name
table_type = "EXTERNAL_TABLE"
parameters = {
"table_type" = "ICEBERG"
"metadata_location" = "s3://${aws_s3_bucket.data_product.id}/metadata/"
"data_contract_url" = "s3://data-contracts/${var.domain_name}/${var.product_name}.yaml"
}
}
# IAM: ruolo per il team di dominio
resource "aws_iam_role" "domain_role" {
name = "data-mesh-${var.domain_name}-${var.product_name}-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::role/${var.owner_team}"
}
}]
})
}
# Monitoring: dashboard CloudWatch automatica
resource "aws_cloudwatch_dashboard" "data_product" {
dashboard_name = "data-product-${var.domain_name}-${var.product_name}"
dashboard_body = templatefile("${path.module}/dashboard.json.tpl", {
domain = var.domain_name
product = var.product_name
sla = var.sla_tier
})
}
# Output: informazioni per il team
output "data_product_uri" {
value = "s3://${aws_s3_bucket.data_product.id}/"
}
output "catalog_table" {
value = "${var.domain_name}.${var.product_name}"
}Katalog dat: Discovery and Lineage
Nezbytnou součástí platformy je Katalog dat: registr centralizované, kde jsou všechny datové produkty publikovány, dokumentovány a prohledávatelné. Ty hlavní Open source nástroje v tomto prostoru jsou:
Porovnání katalogu otevřených zdrojových dat
| Nástroj | Vytvořil | Pevný bod | Vhodné pro |
|---|---|---|---|
| DataHub | Bohatá linie, GraphQL API, rozsáhlé integrace | Podnikové, heterogenní platformy | |
| OpenMetadata | Open source | Moderní uživatelské rozhraní, integrovaná kvalita dat, nativní datové smlouvy | SMB a střední, malé týmy |
| Atlas Apache | Apache/Hortonworks | Pokročilé řízení, klasifikace dat, audit | Hadoop ekosystém, soulad |
| Amundsen | Lyft | Jednoduché uživatelské prostředí, fulltextové vyhledávání | Zjišťování dat pro analytiky |
| Katalog jednoty | Databricks (open source) | Vícemotorové, jemně zrnité řízení přístupu | Databricks a multi-cloudová prostředí |
Zásada 4: Federované počítačové řízení
Čtvrtý princip je často nejvíce nepochopený a nejdůležitější pro úspěch datové sítě. Decentralizace vlastnictví dat bez správy a řízení vede k chaosu. Ale vládnutí tradiční, založené na výborech, manuálních procesech a dokumentech Wordu, se neškáluje. Data Mesh navrhuje jeden federované a výpočetní řízení: Centrálně definovaná pravidla ale použije se automaticky pomocí kódu.
Zásady jako kodex
Zásady řízení jsou zakódovány ve spustitelných souborech, které platforma aplikuje automaticky během životního cyklu datového produktu. Podívejme se na konkrétní příklad s Open Policy Agent (OPA):
# governance/policies/data_product_policy.rego
# Policy OPA per la validazione dei Data Product
package datamesh.governance
# Regola 1: Ogni data product DEVE avere un data contract valido
deny[msg] {
not input.data_contract
msg := "Data product deve avere un data contract definito"
}
# Regola 2: Ogni data product DEVE avere un owner
deny[msg] {
not input.data_contract.info.owner
msg := "Data contract deve specificare il team owner"
}
# Regola 3: I campi PII devono essere dichiarati
deny[msg] {
field := input.data_contract.schema.fields[_]
contains(lower(field.name), "email")
not field.pii
msg := sprintf("Campo '%s' potrebbe contenere PII ma non e contrassegnato", [field.name])
}
# Regola 4: SLA obbligatori per data product in produzione
deny[msg] {
input.environment == "production"
not input.data_contract.sla
msg := "SLA obbligatori per data product in produzione"
}
# Regola 5: Freshness SLA deve essere definito
deny[msg] {
input.environment == "production"
not input.data_contract.sla.freshness
msg := "SLA di freshness obbligatorio per data product in produzione"
}
# Regola 6: Naming convention per le tabelle
deny[msg] {
table_name := input.data_contract.servers.production.table
not re_match("^[a-z][a-z0-9_]*$", table_name)
msg := sprintf("Nome tabella '%s' non conforme: usa solo lowercase, numeri e underscore", [table_name])
}
# Regola 7: Data classification obbligatoria
deny[msg] {
not input.data_contract.terms.classification
msg := "Classification obbligatoria (public, internal, confidential, restricted)"
}
# Regola 8: Retention policy obbligatoria per compliance GDPR
deny[msg] {
not input.data_contract.terms.retention
msg := "Retention policy obbligatoria per compliance GDPR"
}Schéma registru a interoperabilita
Aby bylo zajištěno, že datové produkty z různých domén mohou vzájemně spolupracovat, je třeba zajistit řízení federata definuje globální standardy pro konvence pojmenování, datové typy a formáty odkaz. A Registr schémat centralizované (jako Confluent Schema Registry nebo AWS Glue Schema Registry) registruje a verzuje všechna schémata.
# governance/standards/global_types.yaml
# Standard globali per il Data Mesh aziendale
naming_conventions:
tables:
pattern: "^[a-z][a-z0-9_]{2,60}$"
prefixes:
fact: "fatto_" # Tabelle dei fatti (fact tables)
dimension: "dim_" # Dimensioni
staging: "stg_" # Staging temporaneo
aggregate: "agg_" # Aggregazioni pre-calcolate
columns:
pattern: "^[a-z][a-z0-9_]{1,60}$"
reserved_suffixes:
_id: "Identificativo (integer o bigint)"
_ts: "Timestamp (UTC)"
_dt: "Data senza orario"
_amt: "Importo monetario (decimal)"
_qty: "Quantità (integer)"
_pct: "Percentuale (decimal 0-100)"
_flag: "Booleano"
global_types:
currency:
type: decimal(12,2)
description: "Importi monetari in EUR"
identifier:
type: bigint
description: "Chiavi primarie e foreign key"
timestamp:
type: timestamp
timezone: UTC
description: "Tutti i timestamp in UTC"
country_code:
type: string
format: ISO-3166-1-alpha-2
description: "Codice paese ISO a 2 lettere"
interoperability:
shared_dimensions:
- name: dim_data
owner: platform-team
description: "Dimensione temporale condivisa (calendario)"
- name: dim_geografia
owner: platform-team
description: "Gerarchia geografica (nazione, regione, provincia, comune)"
- name: dim_valuta
owner: platform-team
description: "Conversioni valuta giornaliere"
compliance:
gdpr:
pii_fields_must_be_tagged: true
retention_policy_required: true
right_to_deletion_supported: true
data_classification:
levels: [public, internal, confidential, restricted]
default: internalFederované řízení v praxi
Federativní správa funguje na třech úrovních:
- Globální úroveň (tým platformy): Standardy, konvence pojmenování, sdílené typy, zásady OPA. Centrálně definované, automaticky aplikováno.
- Úroveň domény (tým domény): Specifické schéma, SLA, pravidla kvality domény. Definováno týmem, ověřeno platformou.
- Úroveň datového produktu (jeden): Konkrétní smlouva, metriky, přístup. Spravováno týmem vlastníků.
Kompletní technická architektura datové sítě
Po prozkoumání čtyř principů jednotlivě se podívejme, jak se spojují integrovaná technická architektura. Následující schéma ukazuje hlavní součásti a jejich interakce:
+============================================================================+
| FEDERATED GOVERNANCE LAYER |
| Policy Engine (OPA) | Schema Registry | Compliance Automation |
+============================================================================+
| | |
v v v
+--------------------+ +--------------------+ +--------------------+
| DOMAIN: ORDINI | | DOMAIN: CATALOGO | | DOMAIN: CUSTOMER |
| | | | | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | Data Products | | | | Data Products | | | | Data Products | |
| | - fatto_ordini | | | | - dim_prodotti | | | | - dim_clienti | |
| | - ordini_stream| | | | - prezzi_storico| | | | - segmentazione| |
| | - metriche_day | | | | - inventory | | | | - comportamento| |
| +----------------+ | | +----------------+ | | +----------------+ |
| | | | | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | Pipeline (dbt) | | | | Pipeline (dbt) | | | | Pipeline (dbt) | |
| | - bronze | | | | - bronze | | | | - bronze | |
| | - silver | | | | - silver | | | | - silver | |
| | - gold | | | | - gold | | | | - gold | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | | | | |
| [Team: 5+1 DE] | | [Team: 4+1 DE] | | [Team: 3+1 DE] |
+--------------------+ +--------------------+ +--------------------+
| | |
v v v
+============================================================================+
| SELF-SERVE DATA PLATFORM |
| |
| +-------------------+ +-------------------+ +-------------------+ |
| | Compute Layer | | Storage Layer | | Connectivity | |
| | - Spark / dbt | | - S3 / ADLS | | - Kafka | |
| | - Airflow | | - Iceberg tables | | - API Gateway | |
| | - Kubernetes | | - Schema Registry | | - Query Federation| |
| +-------------------+ +-------------------+ +-------------------+ |
| |
| +-------------------+ +-------------------+ +-------------------+ |
| | Data Catalog | | Observability | | Security | |
| | - OpenMetadata | | - Great Expect. | | - RBAC / ABAC | |
| | - Lineage | | - SLA Monitoring | | - Encryption | |
| | - Search | | - Cost Tracking | | - Audit Trail | |
| +-------------------+ +-------------------+ +-------------------+ |
+============================================================================+Praktická implementace: Od datového monolitu k datové síti
Migrace z monolitického datového skladu do Data Mesh neprobíhá ve velkém třesku. Je to přírůstková cesta, která je rozdělena do fází. Podívejme se na praktický přístup, krok za krokem, se skutečným kódem pro každou fázi.
Fáze 1: Identifikujte pilotní domény a datové produkty
Začneme identifikací 2-3 pilotních domén, vybraných na základě tří kritérií: vyspělý tým a motivovaná, dobře srozumitelná data, jasní spotřebitelé. Už nikdy nezačínáme z domény složité nebo kritické.
Fáze 2: Definujte datové smlouvy
Pro každý datový produkt pilotní domény je definován datový kontrakt (např zobrazeno výše). Smlouva je verzována v Git spolu s kódem domény.
Krok 3: Vytvořte potrubí pomocí dbt
dbt (nástroj pro vytváření dat) a ideální nástroj pro transformace v Data Mesh: Umožňuje doménovým týmům definovat verzované, testované a SQL modely zdokumentováno. Každá doména má svůj vlastní dbt projekt.
-- dbt/models/ordini/gold/fatto_ordini.sql
-- Modello dbt per il Data Product "fatto_ordini"
-- Dominio: Ordini | Layer: Gold | Owner: team-ordini
{{ config(
materialized='incremental',
unique_key='ordine_id',
partition_by={
'field': 'data_ordine',
'data_type': 'timestamp',
'granularity': 'day'
},
tags=['gold', 'ordini', 'data-product'],
meta={
'owner': 'team-ordini',
'sla_freshness': '1h',
'sla_availability': '99.5%',
'data_contract': 'urn:datacontract:ordini:fatto-ordini'
}
) }}
WITH ordini_silver AS (
SELECT * FROM {{ ref('stg_ordini_clean') }}
{% if is_incremental() %}
WHERE data_aggiornamento > (
SELECT MAX(data_aggiornamento) FROM {{ this }}
)
{% endif %}
),
clienti AS (
-- Cross-domain reference: consuma dal dominio Customer
SELECT * FROM {{ source('customer_domain', 'dim_clienti') }}
),
arricchiti AS (
SELECT
o.ordine_id,
o.cliente_id,
o.data_ordine,
o.importo_totale,
o.stato,
o.canale,
c.regione AS regione_cliente,
c.segmento AS segmento_cliente,
o.data_aggiornamento
FROM ordini_silver o
LEFT JOIN clienti c ON o.cliente_id = c.cliente_id
)
SELECT * FROM arricchiti# dbt/models/ordini/gold/schema.yml
# Test e documentazione per il data product fatto_ordini
version: 2
models:
- name: fatto_ordini
description: >
Tabella dei fatti degli ordini completati.
Data Product del dominio Ordini, aggiornato ogni ora.
meta:
owner: team-ordini
data_contract: urn:datacontract:ordini:fatto-ordini
columns:
- name: ordine_id
description: Identificativo univoco dell'ordine
tests:
- unique
- not_null
- name: cliente_id
description: FK al dominio Customer
tests:
- not_null
- relationships:
to: source('customer_domain', 'dim_clienti')
field: cliente_id
- name: importo_totale
description: Importo totale in EUR
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0.01
max_value: 999999.99
- name: stato
description: Stato dell'ordine
tests:
- accepted_values:
values: ['completato', 'annullato', 'rimborsato', 'in_lavorazione']
- name: data_ordine
description: Timestamp di creazione (UTC)
tests:
- not_null
- dbt_utils.recency:
datepart: hour
field: data_ordine
interval: 2Krok 4: Vystavte datové produkty prostřednictvím rozhraní API
Kromě analytických tabulek lze datové produkty zpřístupnit prostřednictvím API pro spotřebitelé, kteří potřebují přístup na vyžádání s nízkou latencí. Zde je příklad s FastAPI v Pythonu:
# api/ordini_data_product.py
# API per il Data Product "Ordini" - Dominio Ordini
from fastapi import FastAPI, Query, HTTPException
from pydantic import BaseModel
from typing import Optional
from datetime import date, datetime
import duckdb
app = FastAPI(
title="Ordini Data Product API",
version="2.1.0",
description="API per il consumo del data product Ordini"
)
class MetricheOrdini(BaseModel):
regione: str
data: date
num_ordini: int
fatturato: float
ordine_medio: float
clienti_unici: int
class HealthCheck(BaseModel):
status: str
freshness_minutes: int
record_count: int
last_update: datetime
# Connessione a DuckDB/Iceberg
con = duckdb.connect()
con.execute("""
INSTALL iceberg;
LOAD iceberg;
""")
@app.get("/health", response_model=HealthCheck)
async def health_check():
"""Verifica SLA del data product"""
result = con.execute("""
SELECT
COUNT(*) as record_count,
MAX(data_aggiornamento) as last_update,
DATEDIFF('minute', MAX(data_aggiornamento), NOW())
AS freshness_minutes
FROM iceberg_scan('s3://data-mesh/ordini/fatto_ordini/')
""").fetchone()
freshness = result[2]
status = "healthy" if freshness < 60 else "degraded"
return HealthCheck(
status=status,
freshness_minutes=freshness,
record_count=result[0],
last_update=result[1]
)
@app.get("/metriche", response_model=list[MetricheOrdini])
async def get_metriche(
data_inizio: date = Query(..., description="Data inizio (YYYY-MM-DD)"),
data_fine: date = Query(..., description="Data fine (YYYY-MM-DD)"),
regione: Optional[str] = Query(None, description="Filtro regione"),
limit: int = Query(100, ge=1, le=1000)
):
"""Metriche aggregate degli ordini per regione e giorno"""
query = """
SELECT
regione_cliente AS regione,
CAST(data_ordine AS DATE) AS data,
COUNT(*) AS num_ordini,
ROUND(SUM(importo_totale), 2) AS fatturato,
ROUND(AVG(importo_totale), 2) AS ordine_medio,
COUNT(DISTINCT cliente_id) AS clienti_unici
FROM iceberg_scan('s3://data-mesh/ordini/fatto_ordini/')
WHERE data_ordine BETWEEN ? AND ?
"""
params = [data_inizio, data_fine]
if regione:
query += " AND regione_cliente = ?"
params.append(regione)
query += """
GROUP BY regione_cliente, CAST(data_ordine AS DATE)
ORDER BY fatturato DESC
LIMIT ?
"""
params.append(limit)
rows = con.execute(query, params).fetchall()
if not rows:
raise HTTPException(status_code=404, detail="Nessun dato trovato")
return [
MetricheOrdini(
regione=r[0], data=r[1], num_ordini=r[2],
fatturato=r[3], ordine_medio=r[4], clienti_unici=r[5]
)
for r in rows
]Fáze 5: CI/CD potrubí pro datové produkty
Každý datový produkt musí mít kanál CI/CD, který ověřuje datovou smlouvu a provádí testy a ověřte zásady správy před nasazením. Zde je příklad s akcemi GitHub:
# .github/workflows/data-product-ci.yml
name: Data Product CI/CD - Ordini
on:
push:
paths:
- 'domains/ordini/**'
pull_request:
paths:
- 'domains/ordini/**'
jobs:
validate-contract:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate Data Contract Schema
run: |
pip install datacontract-cli
datacontract test domains/ordini/data-contract.yaml
- name: Check Breaking Changes
run: |
datacontract breaking \
domains/ordini/data-contract.yaml \
--with-previous-version
test-transformations:
runs-on: ubuntu-latest
needs: validate-contract
steps:
- uses: actions/checkout@v4
- name: Install dbt
run: pip install dbt-core dbt-duckdb
- name: Run dbt Tests
run: |
cd domains/ordini/dbt
dbt deps
dbt seed --target test
dbt run --target test
dbt test --target test
- name: Check Data Quality (Soda)
run: |
pip install soda-core-duckdb
soda scan -d ordini_test \
-c domains/ordini/soda/configuration.yml \
domains/ordini/soda/checks.yml
governance-check:
runs-on: ubuntu-latest
needs: validate-contract
steps:
- uses: actions/checkout@v4
- name: Policy Validation (OPA)
run: |
opa eval \
--data governance/policies/ \
--input domains/ordini/data-contract.yaml \
"data.datamesh.governance.deny"
- name: Schema Registry Compatibility
run: |
curl -X POST \
"$SCHEMA_REGISTRY_URL/compatibility/subjects/ordini-fatto_ordini/versions/latest" \
-H "Content-Type: application/json" \
-d "$(cat domains/ordini/schema.json)"
deploy:
runs-on: ubuntu-latest
needs: [test-transformations, governance-check]
if: github.ref == 'refs/heads/main'
steps:
- name: Deploy Data Product
run: |
dbt run --target production
datacontract publish domains/ordini/data-contract.yaml \
--catalog-url $CATALOG_URLData Mesh vs Data Fabric: Dva doplňkové přístupy
V debatě o moderní datové architektuře Data Mesh e Data Fabric přijdou často prezentovány jako alternativy. Ve skutečnosti řeší různé problémy a mohou koexistovat. Data Fabric je technologicky řízený architektonický přístup, který využívá aktivní metadata a AI k integraci a správě distribuovaných dat. Data Mesh je a organizační přístup, který decentralizuje odpovědnost za data na domény.
Data Mesh vs Data Fabric srovnání
| čekám | Data Mesh | Data Fabric |
|---|---|---|
| Filozofie | Organizační decentralizace | Inteligentní integrace technologií |
| Ovladače | Organizace (tým, vlastnictví) | Technologie (metadata, AI) |
| Vládnutí | Federace, politika jako kód | Centralizované, s pomocí AI |
| Architektura | Nezávislé domény se společnou platformou | Sjednocená vrstva nad heterogenními zdroji |
| Metadata | Spravováno doménovými týmy | Automaticky objevené a spravované AI |
| Integrace dat | Explicitní smlouvy mezi doménami | Virtualizace a znalostní graf |
| Organizační předpoklad | Vysoká (autonomní týmy, kultura DevOps) | Střední (může jej přijmout centrální datový tým) |
| Složitost adopce | Vysoká (organizační + technická změna) | Média (většinou technické) |
| Hlavní prodejci | Otevřený zdroj: dbt, Kafka, Iceberg, OPA | IBM, Informatica, Talend, Denodo |
| Ideální pro | Velké organizace s mnoha doménami | Organizace s heterogenními staršími systémy |
Kdy kombinovat Data Mesh a Data Fabric
V mnoha vyspělých organizacích Data Mesh a Data Fabric koexistují. Data Fabric může fungovat jako integrační vrstva v rámci samoobslužné datové platformy Data Mesh, poskytování virtualizace dat, znalostního grafu a automatického zjišťování metadat. Data Mesh poskytuje organizační model (vlastnictví, smlouvy, federované řízení), zatímco Data Fabric poskytuje technické možnosti (aktivní metadata, integrace inteligentní, federace dotazů).
Skutečné případové studie: Kdo přijímá datovou síť
Data Mesh není jen akademická teorie: přijalo ji několik velkých organizací s měřitelnými výsledky. Podívejme se na čtyři významné případové studie.
Zalando: Evropský průkopník
Zalando, evropský online módní gigant s více než 50 miliony zákazníků aktivní, byl mezi prvními, kteří přijali Data Mesh od roku 2020. S více než 200 týmy vývoje a stovek mikroslužeb se centralizovaný datový sklad stal a neudržitelné úzké hrdlo.
- Výsledek: Doba registrace nového datového produktu se zkrátila ze 4 týdnů na 2 dny
- Platforma: Samoobslužná platforma založená na Databricks, Kafka a interním katalogu
- Dopad: Více než 600 datových produktů publikovaných více než 80 doménovými týmy
- Naučená lekce: Největší výzvou bylo federativní řízení; bez globálních standardů přineslo prvních několik měsíců nekonzistentní datové produkty
Netflix: Data Mesh v DNA
Netflix nepřijali Data Mesh jako transformační projekt: decentralizovaný přístup byl vždy součástí její organizační DNA. S více než 230 miliony předplatitelů a petabajtů streamovaných dat, každý produktový tým a manažer vašich dat end-to-end.
- Výsledek: Více než 4 000 datových sad spravovaných nezávisle doménovými týmy
- Platforma: Apache Iceberg (vytvořený Netflixem), Apache Spark, vlastní interní platforma
- Dopad: U týmů pro obsah a doporučení šel čas na statistiky ze dnů na minuty
- Naučená lekce: Samoobslužná platforma a nejdůležitější investice; bez ní decentralizace vytváří pouze fragmentaci
JPMorgan Chase: Data Mesh v bankovnictví
JPMorgan Chase, největší americká banka podle aktiv, začala cesta k Data Mesh v roce 2021 ke správě dat více než 60 milionů zákazníků spotřebitelů a tisíců institucionálních zákazníků. Bankovní sektor představuje jedinečné výzvy: přísná regulace, multijurisdikční soulad a požadavky na audit.
- Výsledek: 40% zkrácení doby dodání datového kanálu pro rizikové týmy
- Platforma: Hybridní cloudová interní datová platforma s posílenou správou
- Dopad: Automatizovaný soulad s GDPR, SOX a bankovní regulací
- Naučená lekce: V bankovnictví musí být federované řízení přísnější; Zásady OPA se staly požadavkem blokování pro nasazení
Intuit: Data Mesh pro FinTech
Intuice, společnost za TurboTax, QuickBooks a Mint, přijala Data Mesh pro správu finančních dat více než 100 milionů zákazníků. Výzva hlavním z nich bylo soukromí a segmentace dat mezi různými produkty.
- Výsledek: Více než 15 aktivních domén datové sítě s více než 200 datovými produkty
- Platforma: AWS-nativní s Iceberg, dbt a interním katalogem
- Dopad: Doba vývoje nových statistik se zkrátila o 60 %
- Naučená lekce: Smlouvy o datech byly zásadní pro udržení kvality během rozsahu; bez nich by se závislosti mezi doménami zlomily
Výzvy, Anti-Patterns a Kdy NEPOUŽÍVAT Data Mesh
Data Mesh není univerzální řešení. Představuje značné problémy a není vhodný všem organizacím. Pochopení limitů je stejně důležité jako pochopení výhody.
Pět anti-vzorců datové sítě
- 1. Bezplatformová datová síť (divoká decentralizace): Decentralizace vlastnictví dat bez poskytování samoobslužné platformy je ekvivalentní požádat každý tým, aby vybudoval vlastní infrastrukturu od nuly. Výsledkem je fragmentace, duplikace a exponenciální náklady.
- 2. Data Mesh jako technologický projekt: Data Mesh je především organizační změna. Pokud k tomu budete přistupovat jako technologická migrace (nový katalog, nová platforma) bez změny vlastnictví, pobídky a týmová struktura, výsledkem bude nová platforma se stejným problémy centralizovaného modelu.
- 3. Příliš mnoho domén příliš brzy: Spusťte Data Mesh současně na 20 doménách bez ověření modelu o 2-3 řidičích a recept na neúspěch. Inkrementální a základní přístup.
- 4. Smlouvy o datech bez vymáhání: Definujte datové smlouvy, které nikdo nerespektuje, protože nejsou integrovány do CI/CD a v automatizovaném řízení. Smlouvy musí být vymahatelné, nikoli dekorativní.
- 5. Ignorování federovaného řízení: Decentralizace bez vládnutí vytváří chaos. Každá doména si vymýšlí své standardy, konvence pojmenování a formáty vytváří ekosystém nekompatibilních dat.
Kdy NEAdoptovat Data Mesh
Data Mesh není vhodná pro všechny organizace. Zde jsou příznaky, které tomu nasvědčují centralizovaný model může být stále nejlepší volbou:
Kontrolní seznam: Data Mesh NENÍ pro vás, pokud...
- Méně než 5 produktových týmů: S menším počtem týmů centralizace funguje dobře a má menší organizační režii
- Méně než 50 lidí v organizaci: Koordinace je již přirozená, nejsou potřeba žádné formální struktury
- Jedna obchodní doména: Pokud se vše točí kolem jediného produktu, decentralizace postrádá smysl
- Žádná kultura DevOps: Pokud týmy nejsou zvyklé na komplexní vlastnictví softwaru, přidání odpovědnosti za data bude pociťovat jako zátěž, nikoli příležitost
- Žádná datová platforma: Bez samoobslužné platformy bude muset každý tým znovu vynalézt kolo
- Omezený rozpočet pro tým platformy: Samoobslužná platforma vyžaduje značné počáteční investice (obvykle 3-5 specializovaných inženýrů po dobu 6-12 měsíců)
Italský kontext: MSP a decentralizace dat
Italskou podnikatelskou strukturu tvoří z 95 % mikropodniky a malé podniky s méně 50 zaměstnanců. Pro tyto skutečnosti je Data Mesh ve své kompletní podobě často přebytkem strojírenství. Principy, na nichž je založen, jsou však univerzálně platné a mohou přizpůsobí i menším organizacím.
Přizpůsobení datové sítě italským malým a středním podnikům
MSP s 50–200 zaměstnanci a 3–5 funkčními oblastmi může přijmout zjednodušenou verzi datové sítě, kterou budeme nazývat Data Mesh Light:
Data Mesh Light pro SMB
| Princip | Plná datová síť | Data Mesh Light (PMI) |
|---|---|---|
| Vlastnictví domény | Vestavěný datový inženýr podle domény | Správce dat podle funkční oblasti (role na částečný úvazek) |
| Data jako produkt | Formální datové smlouvy, API, Kafka | Dokumentované datové sady se schématem a vlastníkem ve sdíleném listu + dbt |
| Samoobslužná platforma | Vlastní interní platforma | DuckDB + dbt + nástroj BI (Metabase nebo Superset) |
| Federované vládnutí | OPA, registr schémat, politika jako kód | Sdílené konvence pojmenování + test dbt + čtvrtletní recenze |
Kulturní výzvy
Největší výzva pro italské MSP není technologická, ale kulturní. Firemní kultura Italština směřuje k centralizaci rozhodování, vertikální hierarchii a odpor ke změně. Data Mesh vyžaduje opak: týmovou autonomii, zodpovědnost distribuovaná a horizontální spolupráce. Tento kulturní posun vyžaduje vedení silné, průběžné školení a hmatatelné výsledky z pilotních projektů.
Příležitosti PNRR a digitální přechod
Navzdory vyčerpání prostředků na Transition 5.0 (uzavřeno 6. listopadu 2025 pro dvouleté období 2024-2025), nové možnosti financování se očekávají pro cyklus 2026-2028. Malé a střední podniky, které již zahájily cestu správy dat a architektury dat, budou v privilegovaném postavení pro přístup k těmto fondům, což prokazuje digitální vyspělost a konkrétní plán realizace.
Závěry: Kontrolní seznam připravenosti datové sítě
Data Mesh představuje změnu paradigmatu ve způsobu řízení organizací vaše data. Nejde o technologii, která má být instalována, ale o organizační model, který je třeba přijmout postupně. Čtyři principy (vlastnictví domény, data jako produkt, samoobslužná platforma, federované řízení) musí být implementovány společně, aby přinesly smysluplné výsledky.
Kontrolní seznam připravenosti: Je vaše organizace připravena?
- Organizace: Máte alespoň 5+ produktových týmů s odlišnými obchodními doménami?
- Kultura: Mají týmy rozhodovací autonomii a úplné vlastnictví svých služeb?
- Úzké místo: Centrální datový tým a úzké místo s týdenními frontami?
- Schody: Spravujete 50+ datových kanálů nebo 100+ datových sad?
- Rozpočet: Můžete investovat do specializovaného týmu platformy (3–5 lidí na 6–12 měsíců)?
- Sponzorství: Máte podporu vedení pro organizační změnu?
- dovednosti: Máte nebo můžete najmout datové inženýry z vložených doménových týmů?
- Infrastruktura: Máte již datovou platformu (cloud DWH, data lake, lakehouse)?
Pokud jste odpověděli „ano“ na 6+ z těchto otázek, Data Mesh je pravděpodobně další krok ve vyspělosti vaší datové architektury. Pokud jste odpověděli „ano“ na méně než 4, zaměřte se nejprve na pevné základy (moderní datový sklad, datový tým, kultura řízená daty) a přehodnotit za 12-18 měsíců.
Klíčové body k zapamatování
- Il Data Mesh nejde o technologii, ale o organizační paradigma: decentralizujte odpovědnost za data na doménové týmy
- I čtyři principy (vlastnictví domény, data jako produkt, samoobslužná platforma, federované řízení) musí být přijaty společně
- I datová smlouva jsou srdcem systému: definují schéma, SLA a kvalitu strojově čitelným a ověřitelným způsobem
- La Samoobslužná datová platforma a nejdůležitější technická investice: bez ní decentralizace vytváří fragmentaci
- La federované vládnutí rovnováha autonomie a konzistence: centrálně definované politiky, automaticky vynucované
- Data Mesh není to pro každého: Malé organizace nebo organizace s malou doménou mohou získat větší hodnotu z centralizovaného modelu
- Le italské malé a střední podniky mohou přijmout „Data Mesh Light“ s DuckDB, dbt a zjednodušenými organizačními principy
- Zalando, Netflix, JPMorgan prokazují, že model funguje ve velkém měřítku, ale vyžaduje investice do platformy a řízení
V dalším článku seriálu se budeme věnovat úzce souvisejícímu tématu: ETL vs ELT v cloudu. Prozkoumáme, jak vypadají moderní datové kanály se vyvinulo od tradičního dávkového ETL po cloudové nativní ELT s dbt a jak tyto kanály integrují se do architektury Data Mesh, aby poháněly datové produkty každé domény.
Doporučené praktické cvičení
Než přejdete k dalšímu článku, zkuste definovat své datové domény organizace. Vezměte si kus papíru a odpovězte na tyto otázky:
- Kolik produktových týmů máte a jaké obchodní domény pokrývají?
- Jaké jsou 2–3 nejdůležitější datové sady pro každou doménu?
- Kdo je dnes zodpovědný za jednotlivé datové sady? (Pokud je odpověď „nikdo“ nebo „IT tým“, našli jste problém)
- Které datové sady využívá více než jeden tým? (Toto jsou první kandidáti, kteří se stanou datovými produkty)