DWH Temporalita Část 3: Výstup timeline

Ačkoli v mnoha případech není nutné vystupovat timeline v reportech, existují případy, kdy je výstup timeline důležitý. Příklady:

• Zobrazení historie zákazníka (1d)

• Zvýraznění následně upravených dat pro identifikaci podvodů a legitimních korekcí (2d)

• Flexibilní porovnání různých časových období pro pochopení relativních změn (3d)

Pokud jste ještě neslyšeli o 1d (byznysová platnost), 2d (Inscription Time) a 3d (Load Time), můžete zvážit přečtení první části této série.

Výstup timeline 1d: Příklad historie zákazníka

V reportech zobrazujících agregované hodnoty můžete chtít zanořit se do jednotlivého případu. Abychom porozuměli jednotlivému případu, můžeme chtít porozumět historii zákazníka: kdy bydlel v jakém regionu a kdy měnil jaké předplatné. Příklad: vidíme, že stávající zákazníci ruší své DSL internetové připojení, ale později si objednávají optické vlákno. Pro pochopení toho, co se stalo, by mohlo být užitečné vybrat několik vzorků a analyzovat je. Toto je 1d historie: byznysová platnost.

Jak jsme se dozvěděli ve druhé části, můžete to uložit do Temporal Instance Hubu přidáním Valid From Date k byznysovému klíči. Jelikož se nyní granulární úroveň hubu a dat k výstupu shoduje, nepotřebuji ve výstupu provádět žádné úpravy. Jediné, co musím vzít v úvahu, je, že posun časového řezu na ose 1d ve zdroji (změna valid from time) je DWH rozpoznán jako jeden smazaný a jeden nový časový řez, jelikož valid from time je součástí našeho klíče. To znamená, že musíme již neplatnou verzi časového řezu označit nebo filtrovat.

Toho dosahujeme tím, že si v tracking satelitu pamatujeme, zda je klíč ve zdroji stále přítomen, či nikoli. Důležité: toto funguje pouze s plnými načítáními. Je to nezávislé na nástroji Datavault Builder a dokonce nezávislé na Data Vaultu. Pokud nedostávám explicitní zprávu o smazání ze zdroje, jako příjemce mohu implicitně smazané řádky detekovat pouze plným načítáním. Toto plné načítání však musí obsahovat pouze všechny části byznysového klíče a ne všechny atributy. Je tedy možné načítat atributy delta a načítat jen klíč a valid from time plně pro rozpoznání takových „smazání".

Timeline 2d: Detekce podvodů

Před několika lety jsem byl požádán, abych prošel některé nesrovnalosti v provizích z prodejů u zákazníka. Existovala různá pravidla pro to, kdy měl prodejce nárok na prodejní provizi. Prvního dne každého měsíce se sledovalo, kolik nových smluv prodejce uzavřel. Někteří prodejci to využili k tomu, aby zaznamenávali smlouvy poslední den měsíce a den poté, co byla provize vypočítána, je zpětně rušili.

Případ 1: 2d time uloženo ve zdroji, ale bez historie

Jak s těmito daty nakládat? Pokud zdrojový systém zaznamenává Inscription Time, ale nevede historii každé změny, musím v DWH vytvořit znalost 2d historie pomocí 3d historie. Doporučujeme jednoduše uložit 2d časy jako satelitní atributy. To znamená, že v okamžiku, kdy data ukládáte, nemusíte rozumět všem byznysovým pravidlům, jak je vystupovat.

Rozdíl je v tom, že nemohu jen přistupovat k posledním datům na 3d historii (as-now), ale musím vyhodnocovat timeline na 3d ose pro rekonstrukci 2d timeline.

V následujícím výstupu jsme již implementovali první pravidlo, že hodnota se stává zápornou pro událost „Lost". Zde však již vidíme, že S. Shady byl chytrý. Změnil prodejního agenta tak, aby zrušení nebylo započítáno jemu.

Zavádíme tedy nové pravidlo, které bere prodejního agenta z poslední události „Completed":

A pak budou prodeje S. Shadyho v únoru sníženy o ztracenou smlouvu. To však zase funguje jen pro lineární prodejní provize. Jinak musíte odvodit období, na které se korekce vztahuje.

Požadavek jednoduše vystupovat data ve formátu SCD type 2, jak jsou uložena v satelitu na 3d ose, nikomu nepomáhá. Pouze interpretací událostí na různých časových osách vzniká užitečná znalost.

Případ 2: 2d time uloženo s historií ve zdroji, žádná 1d historie

Pokud již dostáváme 2d historii ze zdroje, jsou naše zdrojová data tedy předhistorizovanou tabulkou. Pokud zdroj nyní obsahuje 2d historii, ale žádnou 1d historii, lze předpokládat, že 2d historii lze ztotožnit s 1d historií, neboť je to pravděpodobně nejlepší aproximace.

Případ 3: 2d time uloženo s historií ve zdroji, kombinováno s 1d historií

Pokud již máme bi-temporální datový zdroj s 1d a 2d historií, jsme pravděpodobně u pojišťovny. Pro naše přátele ze sofistikovaného pojistného byznysu: existují dva způsoby, jak takto zdrojová data načíst do Data Vaultu.

• Kombinace byznysového klíče s 1d Valid From timestampem a navíc přidání 2d timestampu

• Převzít technický klíč ze zdroje a uložit ho jako Persistent Staging Load (PSA Load)

Výstup timeline 3d: Reprodukce a porovnání úrovní znalostí

Často citovaný případ pro výstup 3d osy je reprodukovatelnost reportů. Toto je velmi důležitý požadavek, např. pokud reporty vytvořené z právních důvodů musí být kdykoli reprodukovatelné. Ať už se jedná o Sarbanes-Oxley, Basel I, II nebo III nebo jakýkoli jiný reporting. Tento požadavek je naprosto reálný, ale lze ho někdy vyřešit v některých databázích domácími prostředky. Oracle nabízí Flashback Archive pro takové dotazy v určitý čas. Snowflake nabízí podobnou funkci s Time Travel.

Porovnání úrovní znalostí

Ale chci dát reportu možnost vyvolat stav znalostí každého dne a porovnat 2 nebo více stavů znalostí?

Pokud chápete požadavek byznysového uživatele a sdílíte jeho pohled, pak musíte vytvořit SCD type 2 výstup pro 3d timeline. Technickou implementaci popisuji ve čtvrté části této série.

Epilog

Můj osobní názor: V příštím článku se konečně budu zabývat tím, jak technicky vytvořit SCD Type 2 výstup pro 3d timeline. Co pro mě bylo důležité v celém kontextu až do tohoto bodu, je ukázat, že ve většině firem by to měla být spíše výjimka než pravidlo, pokud je vůbec potřeba. Pokud jako standard používáte SCD Type 2 pro 3d timeline, pravděpodobně to děláte proto, že můžete a protože nikdo řádně nesebral a/nebo neanalyzoval potřeby byznysových uživatelů.