Data Vault vs. Data Mesh?

Mám stále dělat Data Vault, když existuje Data Mesh? V posledních týdnech a měsících jsem dostal tyto velmi zajímavé otázky, které se opakovaně objevují. Pokusím se zde tedy vysvětlit své porozumění a své myšlenky. Pokud máte odlišný pohled, neváhejte mě kontaktovat na LinkedInu k diskuzi. Pokud jsem nějakou část konceptu data mesh pochopil špatně, dejte mi prosím vědět.

Může být užitečné rozumět mému zázemí a tomu, co utvořilo můj názor. S daty pracuji od roku 2000. Viděl jsem různé technologické vývoje, jako migrace klientů Sybase na Oracle a klientů Oracle na cloudové databáze typu Snowflake. Sledoval jsem, jak byly přístupy modelování Inmon 3NF někdy nahrazovány nebo doplňovány dimenzionálním modelováním a vzestupem modelování Data Vault.

Modelování Data Vault jsem vždy viděl jako evoluci modelování Inmon 3NF, používanou v mnoha případech ve spojení s dimenzionálním výstupem pro reportingové účely.

V posledních 22 letech jsme také znovu a znovu viděli byznysové uživatele doufající v rychlejší dodávání reportů — jednodušší srozumitelnost dat a mnoho dalšího. Výsledkem takových požadavků někdy byla jiná technologie nebo jiný modelovací přístup.

V jiných případech to spustilo diskuzi o tom, kolik by mělo být centralizováno (specializovaný tým) nebo decentralizováno. Toto napětí není nové.

Rozumím a je to můj osobní názor: Data Mesh je odpovědí na výzvu, že centrální datový tým se může v určitých firmách používajících centralizovaný přístup stát úzkým hrdlem. A této situaci dokonale rozumím.

Sdílím proto mnoho názorů vyjádřených v práci Zhamak Dehghani. Stále si však myslím, že tento přístup se nejlépe hodí pro některé velké podniky se zdroji na přidání datových specialistů do různých domén.

Můj argument je, že středně velké a dokonce i větší firmy by mohly více těžit z centralizovaných týmů použitím modelem řízené automatizace k odstranění úzkého hrdla v centralizovaných týmech jako alternativního řešení. Mohl bych být zaujatý, protože pracuji pro tým Datavault Builder — automatizace DWH je naše věc.

Data Vault vs. Data Mesh?

Pokud raději sledujete video než čtete, najdete záznam z konference Knowledge Gap zde.

Výrazně zkráceně a podle mé interpretace: Data Mesh popisuje, že Enterprise Data Models jsou mrtvé. Měli byste rozdělit své datové modelování a implementaci „datových toků" do domén a přiřadit je nezávislým týmům — doménám.

Znamená to, že Data Vault je z této rovnice odstraněn? Nemyslím si.

Vidíme různé poskytovatele data products mezi infrastrukturou a „Mesh Experience Plane". Data Mesh nepředepisuje doménovým týmům, jak je vytvářet. V mnoha případech bych zastával názor, že je to perfektní místo pro použití automatizovaného Data Vault přístupu.

Proč? Pokud jste v minulosti uvízli na ETL přístupech, jejich rozdělení do menších domén může vyřešit problém škálovatelnosti centrálního datového týmu a snížit část složitosti. Stále to však neodstraňuje mnoho dalších problémů, jako chybějící dokumentaci nebo množství manuální práce.

Modelem řízené přístupy začínají naopak pochopením toho, o čem data jsou. Měli jsme také špatné zkušenosti s Enterprise Data Models v minulosti — jejich vytvoření trvalo měsíce, k jejich pochopení byl potřeba doktorát a datový tým je ignoroval, protože byly příliš abstraktní.

Přesto je potřebujeme, protože poskytují velkou hodnotu a řeší mnoho problémů — ale potřebujeme k nim správný přístup.

Data Vault vyřešil problémy 3NF enterprise data modelu použitím volného propojení mezi entitami a umožnil vám začít malý, implementovat ho hned a později ho rozšiřovat.

Na druhé straně Data Vault vytváří hyper-normalizací mnoho technických objektů. Výsledkem je, že byste potřebovali mnoho datových inženýrů ve svých doménových týmech k manuální implementaci Data Vaultu.

A zde se mohu vrátit ke svému oblíbenému tématu: automatizaci. Automatizace vám pomůže v rámci domén snížit množství práce potřebné k implementaci vašich Data Products tím, že automaticky transformuje datový model do funkčního kódu.

Vyřeší také mnoho požadavků definovaných Zhamak Dehghani, jako získání jasného data lineage a vyřešení historizace dat.

Například v Datavault Builderu získáte také automatizovanou infrastrukturu, rozhraní pro vkládání svých sidecarů a vizuální nástroje pro definování svých Data Products.

Model je verzován pomocí standardního softwarového přístupu s použitím GIT-flow, což řeší jakékoli problémy, které byste mohli očekávat při nasazování modelu a data products.

Skrze Docker deployment a poskytovaná API můžete jednoduchým způsobem nastavit svůj CI-CD workflow.

Jelikož automatizovaný Data Vault přístup je modelem řízený, umožní vám také generovat a dotazovat všechna metadata modelu a runtime bez jakéhokoli manuálního vývoje.

Myslím, že je to perfektní symbióza. Znamená to, že každá datová doména by měla používat automatizovanou Data Vault implementaci? Pravděpodobně ne.

Závěr: Data Mesh + Data Vault je odpověď. Přesněji: Data Mesh + Data Vault + Automatizace.

Centrální vs. decentrální datový model

Kniha „Data Mesh" zůstává vágní v konkrétních detailech implementace. A nepochopte mě špatně: to není kritika. Myslím, že tak musí být, protože otevírá vizi, kterou lze implementovat mnoha různými způsoby.

Rozumíme, že odpovědnost za modelování může být sdílena mezi týmy — v Data Mesh termínech mezi doménami. Děláme to roky, například v nadnárodních firmách s centrálním platformovým týmem a lokálními datovými týmy znajícími specifika dané země.

Centrální tým definuje centrální entity jako „customer" nebo „product". Nyní si první lidé snad začnou stěžovat, že znovu vytváříme zátarasy, které jsme chtěli odstranit přidáním centrálně navržených entit!

Vyslechněte mě: neobhajuji vytváření centrální implementace těchto objektů. Pouze konceptuální definici, že tyto objekty existují. Tato abstraktní definice by odpovídala nakreslení entity na vaše plátno v ER světě. V Data Vaultu by to byl hub.

Nyní, když jste stanovili, že tyto koncepty existují, můžete tyto „prototypy" distribuovat do různých domén. Každá doména by provozovala svou vlastní instanci Datavault Builderu. Doménové týmy rozhodnou, jak tyto koncepty naplnit daty.

Tento proces centrálního definování existence věcí a distribuce definic do datových domén lze v Datavault Builderu zcela automatizovat díky datovým modelům, které lze větvit a slučovat skrze GIT proces.

Výhodou je, že pokud tým revenue assurance vytvoří vztah s centrálně vytvořenou entitou „customer", definuje, jak můžete propojit data mezi doménami customer a revenue assurance zcela automaticky na Experience Plane.

Jak spojovat mezi datovými doménami

Nyní, když víte, jak spojovat různé data products z logické perspektivy, otázkou zůstává, jak toho technicky dosáhnout. V knize Data Mesh se navrhuje použít URI vztahy mezi objekty. Tento přístup může fungovat pro menší dotazy.

Jelikož je Datavault Builder pro většinu vrstev ELT nástrojem, ukládáme všechny výstupy na úrovni databáze s virtuálními rozhraními (pohledy). To znamená, že i když různé datové domény používající Datavault Builder mají zcela izolované instance na oddělených databázích, ale stejné databázové technologii, mohou provádět joiny pomocí cross-database queries.

Pokud různé instance nepoužívají stejnou databázovou technologii, můžete použít virtualizační produkty jako Denodo.

Datavault Builder

V této sekci se snažím zdůraznit, proč věříme, že Datavault Builder je správný nástroj pro implementaci Data Vaultu při tvorbě Data Mesh řešení.

• Cloud-Native — můžete ho provozovat na standardizované infrastruktuře.
• Automatizované nastavení infrastruktury — pomocí Docker deploymentu.
• CI/CD — všechny deployment akce lze spouštět přes API.
• Modelem řízená automatizace — v datových doménách je potřeba méně technických dovedností.
• Založeno na Git Flow — datové modely lze větvit a slučovat.
• Centrální a distribuované modely — vestavěná schopnost vytvářet jádrové prvky centrálně.
• Vizuální komponování Data Products.
• Automatizované data lineage.
• Automatizovaná dokumentace.
• Všechny metriky dostupné v reálném čase.
• Data Vault přístup vám umožňuje začít malý a doménový model v čase rozšiřovat.