IT Systems 10/2018 ITSM (ITIL) - Řízení IT AI a Business Intelligence 29. 11. 2018 10:26

Data Vault 2.0

Alternativní datový model je budoucnost v realizaci datových skladů, tvrdí odborníci ze Sophia Solutions

V nadpisu uvedené slovo „alternativní“ zde možná evokuje význam „moderní“ nebo „nový“, nicméně o žádnou novinku se nejedná. Daniel Linstedt s tímto návrhem datového modelu přišel už v roce 1990 a později v roce 2000 vydal veřejnou publikaci. Ale až v současných časech zaznamenávám zvýšenou pozornost a poptávku zákazníků, abychom u tvorby nových datových skladů zvážili použití Data Vault jako náhradu za dimensionální model, který po zkušenostech v některých ohledech nevyhovoval. Je tedy čas zkoušet neokoukané a „alternativní“ způsoby, které (jak už to bývá) přinesou v mnohém pozitivní posun vpřed, ale i některé nové problémy a změny způsobu uvažování o dané problematice.

V následujícím článku si projdeme základy architektury datového skladu dle návrhu Data Vault 2.0 a ukážeme si klady a zápory tohoto řešení.

Proč a kdy uvažovat o nasazení Data Vault modelu

V první řadě je třeba říct, že každá sebedokonalejší věc se hodí pro určité scénáře a pro některé se nehodí vůbec. To platí i o Data Vault 2.0. Hlavní výhodou tohoto způsobu modelování oproti „klasickému” dimensionálnímu modelování ve dvou nebo třívrstvé architektuře, které uvedl na světlo světa Ralph Kimball, je jeho roztříštěnost entit a přizpůsobení k dnešnímu modernímu „agilnímu” přístupu tvorby datového skladu. Dnes již bývá pro zákazníka důležitější, že má možnost vidět a „sáhnout“ si na nějakou hotovou práci, co nejdříve. Že může realizaci datového skladu v čase ovlivňovat a přizpůsobit změnám požadavků. Toto je v dimensionálním modelu obtížné, protože každý zásah do modelu (přidání nové entity, změna vazby mezi entitami, přidání a ubírání atributů) má za následek pracnou úpravu databáze současných objektů, pracnou úpravu historie dle historizačního mechanismu a také je třeba upravit všechny navazující „datamarty“ v tzv. L2 vrstvě (Data Mart Layer, Information Mart Layer) a samozřejmě i reportovací nástroje, jejich metadata, atd. Dimensionální model tedy není vhodný pro časté iterace změn, agilní vývoj. S tímto problémem se snaží vypořádat model dle Data Vault.

Je třeba však dát na pravou míru to, že Data Vault 2.0 popisuje celou architekturu datového skladu, od Stage vrstvy L0 až po Data Mart vrstvu v L2, metodologii, jak takový datový sklad postavit. Ale hlavní zásah, hlavní změna spočívá v L1 (Core vrstva, DWH vrstva) modelu. I dimensionální modelování má v návrhu Data Vault své místo a to především ve vrstvách datového skladu určeného k přímému reportingu (L2, Data Mart, Information Mart), protože reportovací nástroje jsou výborně připraveny na čtení dat z dimensionálního modelu, či Star-schema, ale přímé napojení na L1 vrstvu v Data Vault modelu neumějí.

Abychom si shrnuli hlavní důvod, kdy uvažovat o Data Vault způsobu modelování, tak vypíchneme následující body:

• Plánovaný datový sklad bude časem velký a bude obsahovat mnoho datových zdrojů.
• Plánovaný datový sklad je třeba řešit iterativně pomocí agilní metody vývoje.
• Plánovaný datový sklad bude v dlouhém časovém horizontu často rozvíjen změnovými požadavky a jeho vývoj bude stále pokračující záležitostí.

Data Vault model se nehodí pro následující:

• Plánovaný datový sklad bude malý (řádově do 20 entit), bude se skládat z malého počtu zdrojových systémů.
• Plánovaný datový sklad pojme jen malou přesně vymezenou část business potřeb a není v plánu ho významně rozvíjet.
• Plánovaný datový sklad slouží jen jako PoC (Proof of concept) pro ukázku reportingových nástrojů.

Z výše uvedeného je patrné, že Data Vault se spíše hodí pro velká řešení v často se měnícím prostředí. Zde však využije svých výhod naplno.

Architektura škálovatelného datového skladu

Nyní si představíme jak správné rozložení jednotlivých vrstev a komponent datového skladu vnímá Data Vault metoda s popisem jednotlivých částí.

Obr. 1: Architektura datového skladu

L0 vrstva - Staging area layer

Tato vrstva datového skladu slouží jako dočasné úložiště dat z extrakce ze zdrojových systémů. Hlavní účel této vrstvy je sjednotit podobu zdrojových dat do jedné databázově srozumitelné formy v podobě tabulek a sloupců v jedné technologii. Zpravidla se zdrojová data netransformují. Pouze se přidají popisné údaje a technické sloupce. V Data Vault architektuře se zde ještě provádí „Základní transformační pravidla“ tzv. „Hard Business Rules“. Do tohoto můžeme zařadit základní čištění dat (lower, upper case, trim, to_char, to_number, lpad, rpad) a přidání technického atributu pro výpočet kontrolního součtu business klíče (Hash funkce MD5 či SHA1). Význam tohoto sloupce je popsán v kapitole HUB.

L1 vrstva - Data warehousing layer / Core layer

Vrstva určená pro konsolidaci, historizaci a významového popisu dat. Zpravidla se jedná o dimensionální model nebo nějaký vlastní hybridní. Data Vault modelování tuto vrstvu ještě štěpí na několik podvrstev:

• Data Vault – Stěžejní část celého datového skladu. Zde se nachází Data Vault model. Databázové entity jako Hub, Link, Satellite, SAL Link, atd. (viz kapitola Data Vault Model)
• Operational Vault – Prostor pro uložení metadatových informací o řízení datového skladu, protokoly o náčtech, o pravidelných operacích, nastavení historizace, práva přístupu, master data, ...
• Business Vault – Jedná se o mezivrstvu mezi L1 a L2. Objekty v této vrstvě ještě dodržují koncept Data Vault a jeho entit, ale v jednotlivých objektech nalezneme už nějakou formu agregace a přizpůsobení směrem k reportingu.
• Metrics vault – Vrstva sloužící pro logování nízkoúrovňových zpráv jako je vytížení procesoru, využitelnost paměti, kdo kdy kam měl přístup. Je to vhodné úložiště pro popisy akcí v rámci bezpečnosti v souladu s GDPR.

L2 vrstva - Data mart / Information mart layer

V této vrstvě se z dat stávají informace. Najdeme zde OLAP kostky, Star schémata v dimensionálním modelu, které slouží jako přímý zdroj pro reportingové nástroje.

Největší nevýhoda Data Vault modelování a zároveň nejpracnější fází je tvorba „pokročilých transformačních pravidel“ tzv. „Soft Business Rules“, které obstarají transformaci mezi L1 vrstvou v Data Vault modelu do L2 vrstvy v dimensionálním modelu do různých datamartů určených pro konkrétní business potřeby.

Data Vault Model

Základní typy entit v databázové struktuře L1 vrstvy jsou následující:

• Hub (Registr business klíčů dané entity)
• Satellite (Atributy dané entity)
• Link (Vazby mezi entitami)
• Reference (Číselníky)

Použití a vazby mezi jednotlivými typy entit je znázorněn na obrázku 2.

Obr. 2: Typy entit v Data Vault modelu.

HUB

Jedná se o klíčovou entitu, která obsahuje Business klíč pro daný objekt. Např. Pokud model reprezentuje Vlakovou dopravu, tak vlak bude jedna entita, lokomotiva (hnací vůz) bude druhá entita a vagón bude třetí entita. Pro entitu vlak bude existovat hub, který bude obsahovat identifikátor vlaku (Přirozený klíč, Business klíč). Ostatní atributy vlaku jako např. kód linky, odkud kam jede, v kolik vyráží apod. v entitě hub nebudou.

Hub má zpravidla obsahovat jen tyto položky:

• HashKey – Jedná se o výsledek některé hash funkce (MD5, SHA1) z celého business klíče (např. identifikátor vlaku viz výše). Pokud je business klíč kompozitní (je rozprostřen přes více položek), tak všechny položky business klíče musí být zahrnuty do výpočtu HashKey. Tento atribut nahrazuje tzv. Surrogate key, tedy sekvenčně generovaný klíč. Důvodem je odstranění závislostí při náčtu datového skladu. HashKey se zpravidla vypočítá už při extrakci dat do L0 a pak můžou být načteny závislé entity (Satellite a Link) v nezávislém pořadí, protože primární klíč je již dopředu znám a není třeba čekat na jeho vygenerování. Existuje spor mezi zastánci nové metody HashKey v Data Vault 2.0 a mezi zastánci klasických sekvenčně generovaných klíčů (Surrogate key). U počítaného HashKey existuje teoretická možnost, že pro 2 různé business klíče se spočítá stejný HashKey. S tímto problémem jsem se nikdy nesetkal a dle mého názoru pravděpodobnost, že dojde k překročení rozsahu sekvence u Surrogate key je daleko vyšší.
• Zdrojový systém – Identifikátor zdrojového systému nebo jeho oblasti.
• Identifikátor náčtu – Interní identifikátor procesu náčtu skladu pro zjištění kdy a jak se dané záznamy do hubu dostali. Pro zjednodušení se může jednat o „Load date”.
• Business klíč – Samotný přirozený identifikátor. Může se skládat z více atributů (kompozitní business klíč).

SATELLITE

Pokud se budeme držet výše uvedeného příkladu o vlakové dopravě, tak na Hub Vlak bude odkazovat nejméně jeden satelit s atributy o vlastnostech vlaku. Tyto atributy budou již historizované klasickou historizační procedurou „Slowly changing dimension“. Výhodou tohoto uspořádání je, že satelitů pro jeden hub může být více a tím můžeme oddělit atributy z jiných zdrojových systémů nebo atributy s jinou pravidelnou frekvencí změny nebo atributy přidané později do datového modelu (Agilní přístup implementace). Pro Data Vault model je typické, že jakýkoliv změnový požadavek, úprava či přidání nových atributů by mělo mít zpravidla za následek přidání nových objektů do datového modelu, nikoliv změnu objektů stávajících. Tedy pokud dojde k tomu, že se začnou sbírat nová data ohledně vlaku (např. teplota vzduchu v době jízdy), tak vždy vytvoříme pro nové atributy nový satelit, navážeme na již existující hub, můžeme dohrát i historii, to vše bez zásahu do již existujících struktur, ze kterých se vybírají data pro reporting.

Satelit obsahuje položky:

• Business HashKey - Reference do Hub nebo Link objektu
• 1 až n atributů
• Technické sloupce pro Slowly Changing dimension (Valid from - to, Current flag, …)

LINK

Jak název napovídá, jedná se o vazební objekt. Vazba vždy propojuje Hub objekty. Tedy jedná se o vazbu mezi business klíči daných entit. Každý link může mít 1 nebo více satelitů.

Pokud použiji opět příklad z vlakové dopravy, tak mezi vlakem, vagónem a lokomotivou existuje vazba, protože každý vlak obsahuje 1 nebo více lokomotiv a také 1 nebo více vagónů. Pokud tedy vytvořím Link pro vazbu mezi vlakem a lokomotivou, můžu k této vazbě přidat i doplňující atributy v satelitech (např. kdo řídil, jakou roli měla lokomotiva ve vlaku - Hlavní, postrk, …).

Link obsahuje položky:

• Vlastní Hash Key - vypočtený hash odkazovaných business klíčů (např. pokud Link objekt drží referenci mezi 4 huby, pak je tento hash spočítaný jako variace všech odkazovaných business klíčů.
• 1 až n referencovaných Hash Key - jednotlivé Hash klíče odkazovaných záznamů v Hub objektech.
• Identifikátor náčtu.
• Zdrojový systém.

V praktickém světě se často setkáme s různými typy Link objektů, které mají specifickou vlastnost a tím pádem i trochu odlišnou strukturu. Některé pokročilé typy Link objektů jsou popsané níže:

• SAL Link (Sam-as link): Jedná se o vazbu v rámci jednoho Hubu,resp. jeden záznam v Hubu odkazuje na jiný záznam ve stejném Hubu. Důvod může být deduplikace Business klíčů.
• Hierarchical Link: Parent-child hierarchie.
• Non-historized link: Link, který obsahuje pouze satelity, které nejsou historizované. Např. účetní transakce je defakto vazba mezi časem, účtem odchozím, účtem příchozím s atributy jako částka, čas podání, kdo podal. To vše bez možnosti historických změn.
• Non-descriptive link: Link, který nemá žádný satelit. Víme tedy jen jaké Huby jsou svázány.
• Compute aggregate link: Pokud z výše uvedeného příkladu vlakové dopravy potřebuji znát jen vazbu mezi vlakem a lokomotivou a nezajímá mě jaké konkrétní vagóny vlak měl. Můžu si vytvořit agregovaný link se satelitem, kde budou údaje o vagónech agregovány (počet vagónů, celková hmotnost, celkový počet pasažérů, …).
• Exploration link: Jedná se o Link objekty, které jen usnadňují spojení mezi 2 huby. Snižují počet připojených databázových objektů.

REFERENCE

Tento typ objektu je prostý „číselník”. Například kódy zemí a jejich názvů nebo kódy měn a jejich popisů. Jedná se o velmi statický obsah. Není třeba mít v každém satelitu, kde se používá měna, kód měny a její název. Obzvlášť, když z kódu měny je zřejmé, o jakou měnu se jedná. K těmto účelům právě slouží číselníková tabulka typu „reference“.

„Query assistant“ tabulky

Jak se říká: „Každá mince má dvě strany“. To platí i u Data Vault datového modelu. Výhody tohoto uspořádání jsme si popsali výše. Nicméně daň za lepší historizaci je „horší“ výběr dat z jednotlivých satelitů tak, aby byl výběr časově konzistentní. Představme si Hub, který má například 15 satelitů. Každý byl přidán v různých fázích projektu. Každý má jinou granularitu historie. A mě zajímá stav celé entity v jeden konkrétní časový okamžik. Query dotaz bude hodně složitý (jak pro napsání, tak pro databázový stroj, který ho bude muset vykonat). Doporučuje se tedy v Business Vault prostoru vytvořit tzv. „Query assistant“ tabulky, které slouží právě pro dotazy časového okna nebo vazebního okna.

PIT tabulka

Jedná o seznam datumů a odpovídajících záznamů v jednotlivých satelitech. Jedna PIT tabulka se vytváří pro jeden Hub. Má zpravidla význam u Hubu, který obsahuje větší množství satelitů. Struktura této tabulky může být různorodá, dle konkrétního způsobu použití. Například: Pro každý den náčtu datového skladu zde může být 1 záznam pro každý záznam v Hubu, který obsahuje den náčtu a primární klíče jednotlivých satelitů (včetně časové značky jako je VALID FROM)

BRIDGE tabulka

Pokud PIT tabulka usnadňuje přístup k časovému oknu, tak Bridge tabulka usnadňuje přístup k provázání Hubů. Jedná se o velmi podobný přístup jako u „Exploration link“. Jednoduše tím snížíme počet „joinů potřebných pro připojení Hubů, které je třeba v dotazu mít.

Závěr

Pokud stojíte před projektem na nový datový sklad, je určitě na místě se zamyslet i nad tím, jaký typ modelu použijeme. Zejména pokud víme, že zákazník chce vidět výsledky práce co nejdříve, chce jít agilní metodou vývoje (nejdříve jednu oblast dostat do reportingu, až poté další), do nového datového skladu bude potenciálně vstupovat velké množství zdrojových systémů, a že je důležité zdrojová data sbírat co nejdříve. Protože ty hlavní transformační pravidla, jejichž vývoj trvá nejvíce času, se v Data Vault přesouvají o vrstvu výše a tím se naskýtá možnost provést náčet a historizaci dat v krátkém časovém horizontu.

Použitá literatura:

LINSTEDT, Daniel; OLSCHIMKE, Michael. Building a scalable data warehouse with data vault 2.0. Elsevier inc. 2016. ISBN 978-0-12-802510-9