Data Mesh Crash Course dbt Unity Catalog
dbt
Unity CatalogA Data Mesh egy szociotechnikai paradigma, amelyet Zhamak Dehghani fogalmazott meg 2019-ben (ThoughtWorks). A központi kérdés: miért nem skáláznak a hagyományos centralizált adatplatformok (data lake, data warehouse) a modern, sok-domainű, gyorsan változó vállalatokban? A válasz nem több hardver és nem egy újabb eszköz — hanem a felelősségek és a tulajdonjog szervezeti újragondolása.
Gyakorlati lab: a kurzushoz tartozik egy notebook.ipynb, amely a WebShop Pro domainjeiből data product contract mintát épít. A teljes lokális stack a docker compose --profile mesh up -d paranccsal indítható.
A klasszikus centralizált data lake vagy enterprise data warehouse fájdalmai mára jól dokumentáltak: a központi adatcsapat szűk keresztmetszet lesz, az üzleti domainek várnak heteket-hónapokat egy mező hozzáadásáért, az adatminőség romlik (mert a központ nem érti a domain szemantikáját), és a lineage átláthatatlan. A Data Mesh ezt négy alapelvvel oldja meg.
A négy alapelv: (1) domain ownership — minden üzleti domain a saját adatainak tulajdonosa, (2) data as a product — az adatra termékként, nem melléktermékként tekintünk, (3) self-serve data platform — egy közös platform-réteg lehetővé teszi, hogy a domain-csapatok önállóan dolgozzanak, (4) federated computational governance — a globális szabályok automatizáltan, kód formában érvényesülnek, miközben a lokális döntéseket a domainek hozzák.
WebShop Pro kontextus: A WebShop Pro-ban négy üzleti domain működik — marketing (események, kampányok, attribúció), sales (rendelések, kosár, fizetés), support (ticketek, ügyfélszolgálati kommunikáció) és fulfillment (raktár, logisztika, szállítás). Egy klasszikus data lake-ben mind a négy domain adatát egyetlen 5-fős központi csapat dolgozza fel — ez nem skálázik. A Data Mesh-ben minden domain saját adattermékeit publikálja, a központi platform-csapat csak az infrastruktúrát biztosítja.
Zhamak Dehghani: How to Move Beyond a Monolithic Data Lake 📖 · Data Mesh in Practice 🎬
4 alapelv · Domain ownership · Data as a product · Self-serve platform · Federated governance · Architektúra-tér · Conway's law · Anti-pattern-ek · Data Contracts · Catalog · Computational policy · Observability · Migráció
WebShop Pro 4 domain-jének (marketing, sales, support, fulfillment) átszervezése Data Mesh architektúrára
Domain ownership dbt
A domain ownership alapelv az adatra adaptálja a domain-driven design (DDD) szervezeti modelljét. A klasszikus DDD-ben Eric Evans szerint a szoftvert bounded context-ekre osztjuk: minden context saját nyelvi modellel (ubiquitous language), saját üzleti szabályokkal és saját csapattal rendelkezik. A Data Mesh ugyanezt mondja az adatra: minden üzleti domain a saját analitikai adatainak is tulajdonosa, nemcsak az operatív rendszereknek.
A bounded context azt jelenti, hogy egy fogalom (pl. "rendelés") jelentése a kontextustól függ. A sales domain "rendelés" fogalma tartalmazza a kosártartalmat, kedvezményeket és fizetési módot. A fulfillment domain "rendelés" fogalma viszont a csomag tartalmát, a címkét és a futárszolgálat útvonalát jelenti. Ezek nem ugyanaz az entitás — két különböző modell, két különböző tulajdonossal.
WebShop Pro példa: A orders domain a sales csapathoz tartozik — ők értik a fizetési flow-t, a kuponokat és a refund logikát. Az events domain (kattintás, oldalmegtekintés, attribúciós tracking) a marketing csapathoz tartozik — ők értik a kampánymodelleket és a UTM paramétereket. Egy klasszikus, monolitikus data team-ben mindkettőt ugyanaz a 2-3 ember írná dbt-ben, és sokszor egyik domaint sem értené igazán mélyen.
Anti-pattern: a "monolitikus data team" — egy 5-15 fős központi adatcsapat, amely az összes üzleti domain ETL-jét és modellezését csinálja. A tünet: minden új mezőre 2-4 hét fejlesztési idő, mert először meg kell érteni a domain szemantikáját, majd egyeztetni az üzlettel, majd implementálni. Domain ownership-pel ez 1-2 nap, mert a domain saját szakértője rakja hozzá.
# WebShop Pro: domain-tulajdonú repo-struktúra
# Minden domain saját Git repó-val, saját CI/CD pipeline-nal,
# saját dbt projektje van. A "monolith data repo" megszűnik.
webshop-mesh/
├── platform/ # platform-team (1-2 fő)
│ ├── catalog/ # DataHub / Unity Catalog config
│ ├── ci-templates/ # közös GitHub Actions workflow-k
│ └── policies/ # OPA Rego globális szabályok
│
├── domain-marketing/ # marketing domain (saját repo)
│ ├── dbt_project.yml
│ ├── models/
│ │ ├── staging/ # raw → staging
│ │ └── marts/
│ │ ├── events__attribution.sql
│ │ └── campaigns__roi.sql
│ ├── dataproducts/
│ │ └── events-attribution.yaml # DATSIS spec
│ └── soda/ # SLA monitoring
│
├── domain-sales/ # sales domain
│ ├── dbt_project.yml
│ ├── models/marts/
│ │ ├── orders__paid.sql
│ │ └── customers__ltv.sql
│ └── dataproducts/
│ └── orders-paid.yaml
│
├── domain-support/ # support domain
│ └── ...
│
└── domain-fulfillment/ # fulfillment domain
└── ...
# Felelősség: minden domain owner a saját repo-jának PR-jeit reviewolja.
# A platform team csak az infrastruktúrát supportálja.
print("4 domain repo + 1 platform repo = 5 független CI/CD pipeline")4 domain repo + 1 platform repo = 5 független CI/CD pipeline [ok] Conway's law alkalmazva: 4 domain-csapat → 4 domain-repó [ok] PR review felelősség lokalizálva (nincs központi bottleneck) [ok] Platform team self-serve toolingot szállít, nem ETL-t
Data as a product (DATSIS) dbt
A data as a product alapelv azt jelenti, hogy az adat nem egy ETL pipeline mellékterméke ("ami kifolyik a végén"), hanem egy önálló, kezelt termék, saját SLA-val, dokumentációval, verziókezeléssel és felelős tulajdonossal. Ez gyökeresen más mentalitás, mint a hagyományos "table dump" megközelítés.
Zhamak Dehghani definiálta a DATSIS attribútumokat — egy data product akkor minőségi, ha mind a hét kritériumnak megfelel: Discoverable (egy katalógusban kereshető), Addressable (van egyedi URI/cím), Trustworthy (publikált SLA, freshness, completeness mérőszámokkal), Self-describing (a séma és a szemantika magából a termékből kiderül), Interoperable (szabványos formátumok, közös azonosítók), Secure (auth és access control), és Valuable on its own (önállóan is hasznos, nemcsak más termékek nyersanyagaként).
WebShop Pro példa: A marts.orders__paid data product a sales domain felelőssége. A contract az ügyféllel (pl. a finance domain): minden fizetett rendelés 15 percen belül megjelenik, a séma backward compatible marad legalább 90 napig, és a order_id globálisan egyedi azonosító, ami az events domain felé is használható join-key.
A code-cell egy minimális dataProduct.yaml sablont mutat — ez egy konkrét kontraktus a sales domain és a downstream fogyasztók között.
# dataProduct.yaml — WebShop Pro: orders__paid data product
apiVersion: dataproduct.io/v1
kind: DataProduct
metadata:
name: orders-paid
domain: sales
owner:
team: sales-data-team
contact: sales-data@webshoppro.hu
spec:
description: |
Fizetett rendelések napi szinten konszolidálva.
Egy sor = egy sikeres fizetési tranzakció.
outputPort:
type: delta-table
location: s3://webshop-mesh/sales/orders__paid/
schema:
- name: order_id
type: STRING
description: Globalisan egyedi rendelesi azonosito (UUID v4)
required: true
- name: paid_at
type: TIMESTAMP
required: true
- name: amount_huf
type: DECIMAL(18,2)
required: true
sla:
freshness: 15m
availability: 99.5
schemaCompatibility: backward
classification: internal[OK] Data product spec validated: orders-paid (domain=sales)
SLA: freshness=15m, availability=99.5%
Output port: delta-table @ s3://webshop-mesh/sales/orders__paid/
Schema: 3 fields, 0 breaking changes vs v1.2.0
Data product specifikáció dbt
A data product specifikáció egy géppel olvasható szerződés, ami a fogyasztói és a tulajdonosi oldal között definiálja a szolgáltatás paramétereit. Iparági szabvány még nem alakult ki teljesen, de két komoly kezdeményezés van: az Open Data Product Specification (ODPS) a Bitol Labs gondozásában és a Data Contract Specification a datacontract.com-tól.
Egy érett spec a következő részeket tartalmazza: identity (név, domain, verzió), output ports (hol és milyen formátumban érhető el — Delta tábla, REST API, Kafka topic), input ports (milyen forrás-szerződésekre támaszkodik), schema (mezők, típusok, kötelezőség, leírás), SLA (freshness, availability, completeness), retention (meddig őrizzük az adatot), lineage (upstream/downstream függőségek), classification (PII, internal, public), és contact (felelős csapat, eszkalációs lánc).
Verziókezelés: a spec semantic versioning szerint változik. Egy patch (1.2.0 → 1.2.1) leíró javítás. Egy minor (1.2.0 → 1.3.0) backward compatible bővítés (új opcionális mező). Egy major (1.2.0 → 2.0.0) breaking change — ezt deprecation időszakkal kell bevezetni, hogy a fogyasztók át tudjanak állni.
A code-cell egy bővebb spec-et mutat, ami az ODPS struktúrát követi és a WebShop Pro marketing.events__attribution termékét írja le.
# events__attribution.dataproduct.yaml
apiVersion: dataproduct.io/v1
kind: DataProduct
metadata:
name: events-attribution
version: 1.4.0
domain: marketing
owner:
team: marketing-analytics
contact: marketing-data@webshoppro.hu
slackChannel: "#marketing-data-product"
spec:
description: |
Attribuciós eseménytábla: minden konverzió mellé az utolsó-érintő
csatorna és kampány attribútumai.
outputPorts:
- name: delta
type: delta-table
location: s3://webshop-mesh/marketing/events__attribution/
- name: rest
type: rest-api
url: https://api.webshoppro.hu/marketing/v1/events
inputPorts:
- name: raw-events
type: kafka-topic
contract: clickstream-v3
- name: orders-paid
type: data-product
reference: sales/orders-paid@1.2
sla:
freshness: 1h
availability: 99.0
completeness: 0.995
retention:
hot: 90d
cold: 730d
classification: pii-restricted
lineage:
upstream: ["raw.clickstream", "sales.orders__paid"]
downstream: ["finance.cac_ltv", "exec.mkt_dashboard"][OK] Loaded events-attribution v1.4.0
- 2 output ports (delta, rest)
- 2 input ports (kafka, data-product)
- SLA: freshness=1h, availability=99.0%, completeness=0.995
- Retention: hot=90d, cold=730d
- Classification: pii-restricted (Sensitivity: HIGH)
Self-serve data platform Unity Catalog
A self-serve data platform alapelv azt mondja: ha minden domain saját adat-csapatot kap, a központi platform-csapat nem tűnik el — átalakul. Nem ETL-t ír többé, hanem belső termékeket (developer tooling, infra, runtime) szállít, amelyeket a domain-csapatok önkiszolgáló módon használhatnak. Ez a platform engineering filozófia adaptálása adatra.
Egy érett self-serve adatplatformnak hét képességet kell kínálnia: (1) storage — Delta/Iceberg tábla provisioning egy paranccsal, (2) compute — Spark/dbt cluster automata indítással, (3) catalog — séma- és lineage-tár (Unity Catalog, DataHub), (4) orchestration — Airflow/Dagster mint platform-szolgáltatás, (5) observability — log, metrika, freshness check központosítva, (6) access control — RBAC/ABAC policy engine, (7) CI/CD — kódot push-ra automatikusan deploy.
Klasszikus eszközstack: Databricks (compute + Delta), dbt (transzformáció), Unity Catalog vagy Atlan (catalog), Airflow vagy Dagster (orchestration), Monte Carlo vagy Soda (observability), Open Policy Agent (governance). A platform-csapat ezeket összerakja, dokumentálja és supportálja — a domain-csapat csak használja.
Platform engineering analógia: ahogy a Kubernetes-en futó belső developer platform (Backstage, ArgoCD, ingress-controller) lehetővé teszi, hogy a fejlesztők ne foglalkozzanak a yaml-mocsárral, ugyanúgy a self-serve adatplatform lehetővé teszi, hogy a domain-csapatok ne foglalkozzanak a Spark-config tuningolással. A Team Topologies könyv ezt "platform team"-nek hívja, aminek a fogyasztója a "stream-aligned team" (a domain-csapat).
Federated computational governance Unity Catalog
A federated computational governance a Data Mesh negyedik és sokak szerint legnehezebb pillére. A federated jelző a politikai szövetségi modellből származik: bizonyos szabályok globálisak (mint egy szövetségi alkotmány), mások lokálisak (mint a tagállami törvények). Az adatra fordítva: néhány policy az egész vállalatra érvényes, de a legtöbb döntést a domain hozza meg saját üzleti logikája alapján.
Globális szabályok — minden domainre kötelezőek: GDPR-megfelelés (PII tagging, retention, subject-access-request), naming convention (snake_case oszlopnevek, UTC timestamp), interoperabilitás (közös ID-formátumok, mint a customer_id UUID v4), security baseline (encryption at rest, audit log), és a data contract verziókezelés szabályai.
Lokális szabályok — domain-szintűek: a marketing domain eldöntheti, hogy a campaign_id mezőt kötelező-e minden eseményhez, a sales eldöntheti, hogy a discount_code milyen formátumú, a support eldöntheti, hogy a ticket SLA hogyan számolódik. A platformnak nincs joga ezekhez beleszólni, mert nem érti a domain-specifikus üzleti logikát.
Computational = a szabályok kódba vannak öntve, nem PDF-policykbe. Policy as code: minden globális szabály egy gépi-érvényesíthető teszt vagy lint-rule. Pl. egy CI pipeline lefuttat egy "minden PII oszlopnak class:pii címke kell"-tesztet minden data product spec-en. Ha hibás, blokkolja a deploy-t. A leggyakoribb eszközök: Open Policy Agent (OPA + Rego), Datafold, dbt + custom macros, vagy Unity Catalog row/column-level security.
Architektúra-tér: monolith vs hub-and-spoke vs mesh
A modern adatarchitektúra három fő topológiát ismer: monolithic (központi data lake/warehouse), hub-and-spoke (központi platform + domain data marts), és data mesh (decentralizált, domain-tulajdonú adattermékek). Ezek nem egymást kizáró opciók — sok vállalat hibrid modellt használ.
Monolithic data lake: egy raktár, egy csapat, egy ETL pipeline-stack. Egyszerű, jól ismert, kis/közepes méretben optimális. A 3-4 fős csapat és a 2-3 üzleti domain alatt szinte mindig ez a helyes választás. A baj akkor kezdődik, amikor 10+ domain és 50+ stakeholder van — a központ szűk keresztmetszet lesz.
Hub-and-spoke: a központi adattó megmarad mint hub, de a downstream felhasználók saját data mart-okat építhetnek belőle. Ez a 2010-es évek középvállalati standardja. Probléma: a hub még mindig központosított, az új domain-ek hozzáadása lassú, és a marttok között inkonzisztens üzleti logika halmozódik fel.
Data mesh: nincs központi hub, vagy ha van, az csak technikai infrastruktúra (storage + catalog), nem üzleti adat-feldolgozó. Minden domain saját pipeline-t futtat, saját termékeket publikál, és peer-to-peer fogyasztja a többi domain termékeit. A komplexitás lokálissá válik, de a globális konzisztencia computational governance-szel garantált.
Az alábbi diagram az architektúrákat ASCII-ban hasonlítja össze.
# Architektúra-topológiák összehasonlítása
# 1) MONOLITHIC DATA LAKE
#
# [marketing] [sales] [support] [fulfillment]
# \\ | / /
# \\ | / /
# ▼ ▼ ▼ ▼
# ┌─────────────────────────┐
# │ CENTRAL DATA TEAM │ ← szűk keresztmetszet
# │ (5 fő, 1 platform) │
# └────────────┬────────────┘
# ▼
# [BI / Analytics]
# 2) HUB-AND-SPOKE
#
# ┌─────────────────────────┐
# │ DATA LAKE HUB │
# └────────────┬────────────┘
# ┌──────────┼──────────┐
# ▼ ▼ ▼
# [mkt mart] [sls mart] [ops mart] ← lokális mart-ok,
# de hub még mindig központi
# 3) DATA MESH
#
# ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
# │ MARKETING│⇄ │ SALES │⇄ │ SUPPORT │⇄ │FULFILLMENT│
# │ data prod│ │ data prod│ │ data prod│ │ data prod │
# └────┬─────┘ └────┬─────┘ └────┬─────┘ └─────┬─────┘
# └─────────────┴─────────────┴──────────────┘
# │
# [SELF-SERVE PLATFORM]
# (storage, catalog, governance)
print("Mikor melyik?")
print(" Monolithic: < 5 domain, < 5 fős data team")
print(" Hub-and-spoke: 5-10 domain, érett közép-vállalat")
print(" Data Mesh: 10+ domain, 50+ stakeholder, gyors változás")Mikor melyik? Monolithic: < 5 domain, < 5 fős data team Hub-and-spoke: 5-10 domain, érett közép-vállalat Data Mesh: 10+ domain, 50+ stakeholder, gyors változás
Conway's law és szervezeti struktúra
Melvin Conway 1968-ban megfogalmazta: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Magyarul: a szoftver-architektúra elkerülhetetlenül tükrözi a szervezeti struktúrát. Ez a Data Mesh egyik legmélyebb tanulsága — nem lehet decentralizált architektúrát építeni centralizált csapattal.
A klasszikus tünet: egy vállalat 6 hónapot tölt egy "moduláris microservice architektúra" tervezésével, miközben a fejlesztőcsapat egyetlen 30-fős monolitikus team. Eredmény: 6 hónap után distributed monolith — minden service deploy egyszerre, mindenki minden ticketen dolgozik, semmi sem skálázik. Az architektúra a kommunikációs gráfot követte, nem a tervet.
Reverse Conway maneuver: ha decentralizált architektúrát akarsz, először decentralizáld a szervezetet. Bontsd a 30 fős csapatot 5x6 fős domain-csapatokra, és csak utána várd el, hogy 5 service legyen. A Data Mesh-re alkalmazva: ha 4 domain-tulajdonú adatterméket akarsz, először állj fel 4 domain-csapatot — különben az architektúra automatikusan visszacsúszik a központi data lake felé.
WebShop Pro esettanulmány: a jelenlegi struktúra egy 5-fős központi data team (3 data engineer, 1 analytics engineer, 1 BI). Cél: domain-tulajdonú mesh. A reverse Conway lépések: (1) a 4 üzleti domainhez (marketing, sales, support, fulfillment) embedded analytics engineer-t rendelni — minden domain-team kap 1 fő-t a központi teamből, (2) a megmaradó 1 fő platform-engineer-ré válik (Databricks, Airflow, Unity Catalog support), (3) a domain-vezetők ettől kezdve felelősek a saját adattermékükért, (4) KPI átállás: nem "lezárt ETL ticket", hanem "domain data product SLA betartás". A változás minimum 9-12 hónapot vesz igénybe — szervezeti, nem technikai munka.
Data Mesh anti-pattern-ek
A Data Mesh "hype" 2021-2023 között sok vállalatot rávett a bevezetésre, és ezek a projektek sok tanulságot adtak. Az alábbi anti-pattern-ek a leggyakoribb hibák — ezek mindegyike vagy a Data Mesh előnyeit nullázza ki, vagy egyenesen rosszabb állapotba juttatja a vállalatot, mint a kiindulási centralizált modell.
Anti-pattern 1: "Data Mesh in name only" — a vállalat kihirdeti, hogy "most már Data Mesh-t csinálunk", de ugyanaz a központi 5-fős team csinálja a 4 domain összes ETL-jét, csak más mappákban. Tünet: a domain-vezetőknek nincs felelősségvállalása, a központi csapat 4x annyi munkát végez, és a deploy lassabb lett, nem gyorsabb. Az alapelvek nélkül a paradigma üres szó.
Anti-pattern 2: "Hub-and-spoke disguised" — formálisan domain-tulajdonú termékek, de minden domain ugyanazt a központi platform-csapatot bottleneck-eli. Ha új tábla létrehozása 2 hetes Jira ticket a platform team-nél, akkor de facto nincs self-serve. A platform team-nek legalább 80%-os self-service ratio-t kell elérnie (a domain-csapatok feladataik 80%-át önállóan elvégzik).
Anti-pattern 3: prematuren komplex governance — a vállalat 50 oldalas governance dokumentumot ír 4 data product létezése előtt. A computational governance-nek a termékekkel együtt kell nőnie. 1-2 pilot domain után 5-10 globális szabály bőven elég kezdetben.
Mikor NEM kell Data Mesh: kis cég (<100 fő), kevés domain (<5), egyetlen data team kezelhető, gyors iteráció van. A Data Mesh komoly szervezeti többletet jelent — minden domain kap saját engineer-t, ami fejlesztői költség. Egy 5-domain alatti vállalatnál a klasszikus monolitikus data lake olcsóbb és gyorsabb. Zhamak Dehghani maga is hangsúlyozza: a Data Mesh "skálázási probléma" megoldása, nem univerzális bevált gyakorlat.
Data product technikai megvalósítása dbt
A data product nemcsak elméleti fogalom — konkrét technikai artifaktokra fordítható le. A leggyakoribb implementáció egy dbt projekt, amely egy domain-tulajdonú repó alatt él, saját CI/CD-vel, és output port-ként Delta/Iceberg táblákat publikál. Ezt egészítheti ki egy REST API gateway (FastAPI vagy Hasura), ha a fogyasztók nem Spark-on dolgoznak.
Output port-ok: a leggyakoribb választás a Delta vagy Iceberg tábla — könnyen olvasható Spark/Trino/DuckDB-ből, ACID tranzakciókkal és time travel-lel. Magasabb-szintű fogyasztóknak (BI tool, alkalmazás) érdemes REST endpoint-ot is kínálni, ami ugyanazon az adaton dolgozik.
Input port-ok: minden upstream forrás contract alapján érhető el, nem közvetlen tábla-hivatkozás alapján. A sales domain pl. nem azt mondja "olvasom a marketing.events tábla X oszlopát", hanem "fogyasztom a marketing/events-attribution@1.4 contract-ot". Így a marketing belül átszervezheti a táblákat, amíg a contract változatlan marad.
A code-cell egy minimális dbt model-t és schema.yml-t mutat, ami a sales domain orders__paid data product-jának része.
# models/marts/orders__paid.sql (dbt model — sales domain)
{{ config(
materialized='incremental',
incremental_strategy='merge',
unique_key='order_id',
file_format='delta',
location_root='s3://webshop-mesh/sales/'
) }}
select
o.order_id,
o.customer_id,
o.paid_at,
o.amount_huf,
o.currency,
o.payment_method
from {{ ref('stg_orders') }} as o
where o.payment_status = 'PAID'
{% if is_incremental() %}
and o.paid_at > (select max(paid_at) from {{ this }})
{% endif %}
# models/marts/schema.yml — data product contract
version: 2
models:
- name: orders__paid
description: "Sales domain output port: fizetett rendelések"
meta:
owner: sales-data-team
domain: sales
sla_freshness: 15m
classification: internal
columns:
- name: order_id
description: "Globális egyedi rendelés-azonosító"
tests:
- not_null
- unique
- name: customer_id
tests: [not_null]
- name: paid_at
tests: [not_null]
- name: amount_huf
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "> 0"[OK] dbt run --select marts.orders__paid
Found 1 model, 5 tests, 0 errors, 0 warnings
Materialized: incremental (merge on order_id)
Output: s3://webshop-mesh/sales/orders__paid (Delta)
Rows added: 12,418 | Rows updated: 0
Test result: PASS (5/5)
Data Contracts
A Data Contract egy producer és egy vagy több consumer közötti formális szerződés, ami géppel olvasható módon definiálja a séma, az SLA és a verziókezelés szabályait. A Data Mesh kontextusában ez a "data product spec" gyakorlati megvalósítása. A két fogalom átfed, de a Data Contract szűkebb: csak az interfészre fókuszál, nem az implementációra.
Mit definiál egy contract: a sémát (Avro, Protobuf vagy JSON Schema formátumban), a szemantikát (mezők leírása, üzleti jelentés), az SLA-t (freshness, completeness, availability), a verziókezelési politikát (semantic versioning + deprecation policy), és a kompatibilitási stratégiát (backward, forward, full).
Open source eszközök: a datacontract.com CLI (datacontract-cli) tudja validálni a contract-ot a tényleges schema ellen, és fail-eli a CI-t, ha eltérés van. A Soda Core data quality assertion-öket ad SodaCL nyelven. Az OpenLineage lineage-eseményekkel köti össze a producer és consumer oldali változásokat, catalog rétegben pedig DataHub vagy OpenMetadata tudja láthatóvá tenni a contractokat.
A code-cell egy datacontract.com-formátumú YAML-t mutat, ami a sales domain orders-paid termékét írja le, és integrálható a CI pipeline-ba (pl. GitHub Actions).
# orders-paid.datacontract.yaml
dataContractSpecification: 0.9.3
id: orders-paid
info:
title: Orders Paid
version: 1.2.0
owner: sales-data-team
contact:
name: Sales Data Team
email: sales-data@webshoppro.hu
servers:
production:
type: delta
location: s3://webshop-mesh/sales/orders__paid
format: delta
models:
orders_paid:
type: table
fields:
order_id:
type: string
required: true
unique: true
description: UUID v4
customer_id:
type: string
required: true
paid_at:
type: timestamp
required: true
amount_huf:
type: decimal
precision: 18
scale: 2
required: true
minimum: 0
servicelevels:
freshness:
description: "Új rendelés 15 percen belül látszik"
threshold: 15m
availability:
description: "Tábla 99.5% időben elérhető"
percentage: "99.5%"
quality:
type: SodaCL
specification:
checks for orders_paid:
- row_count > 0
- duplicate_count(order_id) = 0
- missing_count(customer_id) = 0$ datacontract test orders-paid.datacontract.yaml Schema validation: PASS Data quality (Soda): PASS (3/3 checks) SLA check: freshness=8m (within 15m threshold) Compatibility: BACKWARD vs v1.1.0 (no breaking changes) [OK] Contract is healthy. Safe to deploy.
Catalog és discovery Unity Catalog
A data catalog a Data Mesh idegrendszere — ez teszi a DATSIS első attribútumát (Discoverable) lehetővé. Egy katalógus nélkül a 30+ data product gyakorlatilag láthatatlan: senki sem tudja, milyen termékek léteznek, ki a tulajdonos, és melyik a megbízható forrás. Egy érett katalógus három képességet egyesít: schema repository, lineage tracker, és discovery UI.
Vezető eszközök: az DataHub (LinkedIn eredetű, open source, leginkább technikai felhasználóknak), az OpenMetadata (aktív open source catalog és quality funkciókkal), az Atlan (kereskedelmi, business-glossary erős), és a Databricks Unity Catalog (ha Databricks-ön vagy, ez az alapértelmezett governance réteg).
Discovery user-perspektívából: egy data analyst beír a katalógus search-be, hogy "customer churn", és kap egy listát a témához kapcsolódó termékekről, mindegyiken megjelenik a tulajdonos, az SLA, az utolsó frissítés, a downstream konzumensek listája és egy "trust score" (mennyire megbízható). Egy kattintással lát egy lineage-grafot, hogy honnan jön az adat, és hova megy.
A code-cell egy DataHub Python SDK hívást mutat, ami egy data product-ot regisztrál a katalógusban tulajdonossal és tag-ekkel.
# DataHub data product regisztráció (Python SDK)
from datahub.emitter.mce_builder import make_dataset_urn, make_user_urn
from datahub.emitter.rest_emitter import DatahubRestEmitter
from datahub.metadata.schema_classes import (
DatasetPropertiesClass,
OwnerClass,
OwnershipClass,
OwnershipTypeClass,
GlobalTagsClass,
TagAssociationClass,
)
emitter = DatahubRestEmitter(gms_server="http://datahub-gms:8080")
dataset_urn = make_dataset_urn(
platform="delta-lake",
name="webshop-mesh.sales.orders__paid",
env="PROD",
)
# Data product metadata
properties = DatasetPropertiesClass(
description="Sales domain output port: fizetett rendelések (15m freshness SLA)",
customProperties={
"domain": "sales",
"data_product": "orders-paid",
"version": "1.2.0",
"sla_freshness": "15m",
"classification": "internal",
},
)
# Tulajdonos (sales-data-team)
ownership = OwnershipClass(owners=[
OwnerClass(
owner=make_user_urn("sales-data-team"),
type=OwnershipTypeClass.DATAOWNER,
)
])
# Tag-ek a discovery-hez
tags = GlobalTagsClass(tags=[
TagAssociationClass(tag="urn:li:tag:domain:sales"),
TagAssociationClass(tag="urn:li:tag:tier:gold"),
])
emitter.emit_mcp(dataset_urn, "datasetProperties", properties)
emitter.emit_mcp(dataset_urn, "ownership", ownership)
emitter.emit_mcp(dataset_urn, "globalTags", tags)
print(f"[ok] Registered: {dataset_urn}")[ok] Registered: urn:li:dataset:(urn:li:dataPlatform:delta-lake,webshop-mesh.sales.orders__paid,PROD)
- properties: domain=sales, sla=15m
- owner: sales-data-team (DATAOWNER)
- tags: domain:sales, tier:gold
- lineage: 3 upstream, 7 downstream consumers
- search-indexed in DataHub UI
Computational policy (OPA + Rego)
A computational governance gyakorlatban policy-as-code. A vezető eszköz az Open Policy Agent (OPA) a CNCF-projekt, amely a Rego deklaratív nyelven írt policy-kat értékel ki. Egy OPA policy egy logikai szabály: "ha A feltétel teljesül, akkor B döntés szülessen". Az adatra alkalmazva: "ha egy oszlop PII-tagged, akkor csak data-engineers group olvashatja".
Tipikus használat a Data Mesh-ben: minden data product spec deploy előtt átfut egy OPA gate-en, ami ellenőrzi a globális szabályokat. Pl. minden PII-jelölt mezőhöz kötelező egy retention policy, minden tábla owner mezője nem lehet üres, minden data product version semver-formátumú legyen. Ha a spec megsérti a policy-t, a CI fail-eli a deploy-t.
Runtime policy: az OPA-t lehet runtime-ban is használni (pl. Trino vagy Databricks Unity Catalog access decision-höz). Minden olvasási kérés átmegy egy gate-en, amely a user csoportja és az oszlop classification-je alapján engedi vagy tiltja a műveletet.
A code-cell egy Rego policy-t mutat, amely megtagadja a PII-oszlopok olvasását, ha a kérő user nincs a data-engineers vagy privacy-officers csoportban.
# pii_access.rego — OPA policy PII oszlopokra
package webshop.dataproduct.access
# Alapértelmezett: tiltjuk a hozzáférést
default allow := false
# Engedélyezzük, ha az oszlop nem PII
allow if {
not input.column.classification == "pii"
}
# Engedélyezzük, ha a user data-engineers vagy privacy-officers csoportban van
allow if {
input.column.classification == "pii"
some group in input.user.groups
group in {"data-engineers", "privacy-officers"}
}
# Audit log minden tagadáskor
deny_reason := reason if {
not allow
reason := sprintf(
"Felhasználó %v nem férhet hozzá a PII oszlophoz: %v.%v",
[input.user.email, input.table, input.column.name],
)
}
# --- Példa input ---
# {
# "user": {"email": "anna@webshoppro.hu", "groups": ["analysts"]},
# "table": "sales.orders__paid",
# "column": {"name": "customer_email", "classification": "pii"}
# }
# Eredmény: allow = false, deny_reason = "anna nem férhet hozzá..."
# CI integráció: minden data product spec ellen lefut a policy
# opa eval -i dataproduct.json -d pii_access.rego "data.webshop.dataproduct.access.allow"$ opa eval -i request.json -d pii_access.rego "data.webshop.dataproduct.access"
{
"allow": false,
"deny_reason": "Felhasználó anna@webshoppro.hu nem férhet hozzá a PII oszlophoz: sales.orders__paid.customer_email"
}
[audit] DENIED user=anna@webshoppro.hu column=customer_email reason=pii-restricted
Observability és metrikák
A Data Mesh-ben minden data product egy mini-szolgáltatás — és minden szolgáltatáshoz monitoring kell. A data observability öt pillérre épül: freshness (mikor frissült utoljára), volume (hány sor van), schema (változott-e a séma), quality (üzleti szabályok teljesülnek-e), és lineage (honnan-hova megy az adat).
Tipikus SLO-k egy data product-ra: freshness < 1 óra (95%-ban), completeness > 99% (kötelező mezők ne legyenek null), schema-drift = 0 (törő séma-változás csak verzió-emeléssel), uniqueness violation = 0 (kulcs-oszlopok unique-ak).
Eszközök: a kereskedelmi oldalon Monte Carlo és Soda Cloud erős data observability megoldások (anomáliadetekció + dashboard). Az open source oldalon Great Expectations és Soda Core kombinálható Datadoggal vagy Grafanával. Databricks környezetben a Delta Live Tables expectations és Unity Catalog lineage adja az alapot.
A code-cell egy Soda Check YAML-t mutat, ami a sales orders-paid termékre tartja az SLA-t, és a Slack-be ír riasztást megsértés esetén.
# soda/orders_paid_checks.yml
checks for orders__paid:
# Freshness SLA: 15 perc
- freshness(paid_at) < 15m:
name: "Orders fizetése < 15 perccel friss"
attributes:
sla: freshness
domain: sales
# Volume: napi rendelés-szám sávban legyen
- row_count between 1000 and 100000:
name: "Napi sorok száma reális tartományban"
# Completeness: kötelező mezők nem null
- missing_count(order_id) = 0
- missing_count(customer_id) = 0
- missing_count(amount_huf) = 0
# Uniqueness: order_id egyedi
- duplicate_count(order_id) = 0:
name: "Order ID egyediség"
# Üzleti szabály: az összeg pozitív
- failed rows:
name: "Az amount_huf pozitív kell legyen"
fail condition: amount_huf <= 0
# Schema check: nem törhet a séma
- schema:
fail:
when forbidden column present: [credit_card_number, ssn]
when wrong column type:
order_id: string
amount_huf: decimal
# Notification: ha bármi fail, Slack-be írjuk
notifications:
slack:
channel: "#sales-data-alerts"
on: failure$ soda scan -d webshop_mesh -c soda-config.yml soda/orders_paid_checks.yml Soda Core 3.3.0 Scanning orders__paid (Delta @ s3://webshop-mesh/sales/) [OK] freshness(paid_at) < 15m → 8m (PASS) [OK] row_count between 1000 and 100000 → 12,418 (PASS) [OK] missing_count(order_id) = 0 → 0 (PASS) [OK] missing_count(customer_id) = 0 → 0 (PASS) [OK] duplicate_count(order_id) = 0 → 0 (PASS) [OK] schema check → no forbidden columns (PASS) Scan completed: 7/7 checks passed in 12.4s
Migráció Data Mesh felé
A Data Mesh nem big-bang migráció — egy 12-18 hónapos szervezeti és technológiai átalakulás, ami nagyvállalatnál akár 2-3 év is lehet. A leggyakoribb hibák egyike a túl gyors deklaráció: a vezetőség "kihirdeti" a Data Mesh-t, de a konkrét munka nem készül el. Egy realisztikus stratégia négy fázisban gondolkodik.
Fázis 1 (1-3. hónap): pilot domain-ek — válassz 1-2 üzleti domain-t, amelyek fájdalompont-ot képviselnek (pl. a központi data team-nek nincs kapacitása rájuk) és politikailag támogatottak (van executive sponsor). Tipikusan a marketing és a sales jó pilotok, mert mindkettő gyors üzleti igénnyel jön és van saját analytics igényük.
Fázis 2 (4-6. hónap): self-serve platform tools — ekkor építsd ki a közös infrastruktúrát: catalog (DataHub vagy Unity Catalog), CI/CD template-ek dbt-projekteknek, közös observability stack (Soda + Grafana), policy engine (OPA). Ennek 80%-os self-service ratio-t kell elérnie a fázis végére.
Fázis 3 (7-12. hónap): governance forum + 2-3 további domain — állítsd fel a federated governance-t: havi cross-domain meeting, ahol a data product owner-ek egyeztetnek a globális szabályokról. Bővítsd a mesh-t 2-3 új domainnel — ekkorra az első pilotok stabilak, és tudnak mentorálni.
Fázis 4 (12-18. hónap): gradual rollout — minden új domain-projekt automatikusan mesh-ben indul. A régi monolitikus pipeline-okat fokozatosan deprecate-eljük. Ne ess abba a hibába, hogy "minden régit egyszerre migrálunk" — sok régi pipeline soha nem éri meg az újraírást.
Esettanulmány: Zalando — a németországi divat e-kereskedelmi vállalat 2017-2020 között migrált. A céges blog részletesen dokumentálja: 200+ data product, 60+ team, federated governance forum havonta. A migráció 2.5 évig tartott, de a végén a "time-to-data" (új mező megjelenése) 6 hétről 2 napra csökkent.
Összefoglalás
Gratulálunk! Ebben a kurzusban végigjártuk a Data Mesh paradigma teljes ívét — az alapelvektől a technikai megvalósításon át a migrációs stratégiáig. A Data Mesh nem egy eszköz vagy keretrendszer, hanem egy szervezési és felelősség-megosztási modell, amelyet a centralizált adatplatformok skálázási problémái hívtak életre.
A négy alapelv: (1) domain ownership — minden üzleti domain a saját analitikai adatainak tulajdonosa, (2) data as a product — DATSIS attribútumok teljesülése (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure, Valuable), (3) self-serve data platform — a központi platform-csapat eszközöket szállít, nem ETL-t, (4) federated computational governance — globális szabályok kódban, lokális döntések domain-szinten.
Mikor használd: 10+ üzleti domain, 50+ stakeholder, gyorsan változó üzleti környezet, érett mérnöki kultúra (Git, CI/CD, IaC már megy), executive sponsor van. Mikor NE használd: kis cég (<100 fő), kevés domain (<5), monolitikus szervezet, "buzzword-driven" projekt, ahol nincs valódi szervezeti változás. A Data Mesh a "skálázási probléma" megoldása — nem univerzális best practice.
Gyakorlati artifaktok: data product spec (YAML), data contract (datacontract.com formátum), dbt project per domain, OPA Rego policy a globális szabályokhoz, Soda checks az SLA-monitorozáshoz, DataHub/Unity Catalog a discovery-hez. Conway's law és a reverse Conway maneuver a szervezeti tervezés alapja.
Következő kurzus: a Data Governance kurzus mélyebbre megy a federated governance mechanikájában — adat-katalógus implementáció, GDPR-megfelelés, retention policy, lineage és business glossary management.