DWH Temporalita Část 2: Snižování složitosti

O „temporalitě" v Data Vaultu

Zbavme se temporální složitosti

Jako výrobce automatizačního softwaru Datavault Builder jsme často dotazováni, jak v našem nástroji a/nebo v Data Vaultu obecně mapovat změny v čase. Často ve formě: jak mohu reportovat věci ve formátu SCD Type 2? Není však vždy jasné, o které časové ose mluvíme. Zde je tedy pokus to vyjasnit. Toto je druhý článek ze série tří.

• První článek definoval výzvu, které čelíme s temporalitou v DWH

• Tento článek definuje možnosti, jak temporální složitost zjednodušit, je-li to možné

• Třetí článek probírá byznysové požadavky na výstup timeline

Existují různé přístupy k temporalitě v data vaultu. Doporučuji proto číst texty Dirka Lernera, Christiana Kaula a Larse Rönnbäcka. Zde představuji variantu, jak jednotlivé časové osy reprezentovat nebo zjednodušit tak, aby je bylo možné zvládnout. Jak je definováno v prvním článku, probírám pouze 3 časové osy a používám následující zkratky:

• 1d pro Valid Time

• 2d pro Inscription Time

• 3d pro Load Time

První dimenze (1d) je byznysová platnost. Tato timeline je zvláštní v tom smyslu, že nový časový řez na ose neznamená, že stará entita je neplatná: pokud žiju v Basileji místo v Curychu, informace, že jsem kdysi žil v Curychu, není nesprávná.

Osa 1d: Všechny informace jsou platné, ale aktuální je pouze jeden záznam.

Druhá dimenze (2d) je inscription time ve zdrojovém systému. To je relevantní, protože na ose 1d lze zadávat i nové záznamy do budoucna a opravy aktuálního a/nebo minulého časového řezu. V některých odvětvích a odděleních to lze využít k podvodům. A to je také důvod první simplifikace: navrhuji ukládat 2d timeline v satelitu jednoduše jako atribut v prvním kroku, aby se neztratily žádné informace.

1. simplifikace / strategie: ukládat 2d časy jako běžný satelitní atribut

To znamená, že z trojrozměrného prostoru uvažujeme pouze dvourozměrnou rovinu.

Třetí dimenze (3d) je doba, kdy byla informace načtena do data warehousu. Osa 3d je zvláštní v tom, že je pod kontrolou DWH týmu. A mnozí, kdo v této oblasti pracují dlouho, vědí, že žádnému zdrojovému systému nevěříme :)

Osa 3d: Jedna informace nahrazuje druhou implicitně (ano, Petr je správný pravopis mého jména)

O čem mluvíme / opravy vs. skutečná historie

Pokud nyní předpokládáme, že načtení do DWH je velmi blízko zachycení ve zdroji, ukládáme prostě 2d čas jako atribut v satelitu a v prvním kroku ho ignorujeme. Takže když mluvíme o SCD type 2: jde o 1d nebo 3d? Není to vždy jasné a částečně závisí na odvětví. V pojišťovnictví je například pro mnoho objektů ve zdroji povinné vést 1d historii.

V některých firmách je to tak běžné, že se mezi 1d a 3d nerozlišuje.

Skutečná historie vs. relevantní historie

Ale i když existuje skutečná historie: pokud pro můj byznysový model není relevantní, jaké jméno měla osoba v minulosti (pokud neprodávám hrnky se jmény): proč bych tuto informaci dával do reportu?

V mnoha případech má větší smysl poskytovat point-in-time pohled (podle byznysových potřeb) do reportů, protože to usnadňuje používání reportů a snižuje pravděpodobnost špatného vyhodnocení.

Jak modelovat 1d historii v DWH

Existují základní rozdíly: interpretuji čas předtím, než ho načtu do Data Vaultu, nebo nejprve načítám vše ze zdroje do Raw Vaultu, i když dostáváme překrývající se časové řezy? Zvolili jsme druhý přístup.

2. „simplifikace" / strategie: vytvořit temporal instance hub spojením byznysového klíče s business valid from time

To znamená, že dostáváme více platných záznamů pro byznysový klíč, jako je číslo smlouvy, i když nejsou aktuální. Řešením je buď použít Multi-Active Satellite, nebo změnit grain hubu. Tomu říkám temporal instance hub.

Příklad: V pojišťovnictví mám pojistku s definovaným pokrytím. Toto pokrytí lze však v čase upravovat. Důležité: obvykle to není oprava, ale zakládá novou instanci pojistky.

Pokud nyní dojde k opravě, protože v lednu 2019 někdo zjistí, že pokrytí bylo zadáno chybně, má temporal instance hub jasnou výhodu: pokud se mění jen jeden časový řez, bude správně aktualizován v 3d timeline standardním pattern načítání.

Z těchto důvodů ve svém nástroji podporujeme přístup temporal instance hub.

A co relevantní dimenzionální atributy: instanciace

Ačkoli jsem výše popsal, že některé změny atributů nejsou pro mnoho vyhodnocení relevantní, určitě existují takové změny, které jsou klíčové.

Jedním příkladem je jeden z našich zákazníků, který má možnost si určité produkty před prodejem zákazníkům buď sám vyrábět, nebo nakupovat. Pro účely zajištění kvality je významné, zda byl produkt prodán a dodán zákazníkem nebo externí firmou.

Takže máme případ, kdy se 3d časová osa používá jako aproximace 1d pohledu. V Data Vault modelování je velmi jednoduchý způsob, jak to udělat: tento atribut můžeme přenést z hubu produkt na hub položka prodejní objednávky. To se provádí nastavením Business Vault Loadu v okamžiku, kdy se transakce načítá do Raw Vaultu. Ten provádí lookup as-of-now na atribut produktu a poté jej ukládá do Business Vault satelitu na transakci. Tento postup nazývám instanciace atributu na jiný grain.

3. simplifikace / strategie: instanciovat atributy v určitém okamžiku k transakcím

Pokud nyní vystupujeme prodejní objednávku, můžeme také vystupovat Business Vault atribut na tomto grainu transakce. Každý uživatel chápe, že tento atribut je něco v okamžiku transakce.

Krátké shrnutí

S těmito třemi simplifikacemi / strategiemi,

• ukládání 2d pouze jako atribut v satelitu

• zahrnutí 1d času do klíče hubu

• instanciace atributů na transakci

tvrdím, že můžeme pokrýt většinu požadavků na historizovaný výstup ve většině odvětví. Ve třetím článku proberu případy, kdy toto nestačí, a jaká jsou technická řešení pro takové požadavky.