O Linkách

Petr Beles, 2150 GmbH 2017-02-11 Linky reprezentující transakce v Data Vaultu

V tomto článku se zabývám pouze linky reprezentujícími transakce. Záměrně vylučuji linky reprezentující vztahy (tj. vztahy master data — dávající kontext objektu, jako je link mezi městem a obcí).

Řádek v konvenčním linku v Data Vaultu je definován unikátní kombinací vztahů (reprezentovanou hashem složených BK všech zúčastněných hubů) plus potenciálně zahrnujícím dependent child key. (Building a scalable DWH with DV 2.0 — Linstedt & Olschimke 4.4.5)

V reálném světě mají transakce často unikátní byznysové klíče (číslo, které je sděleno zákazníkovi — ne technický klíč). Vezměme si jako příklad objednávku: objednávka má číslo objednávky a každá řádka této objednávky má číslo řádky. I když je číslo řádky samo o sobě weak entity, je jednoznačně identifikovatelné kombinací id transakce s číslem řádky.

To znamená, že hash key závisí na identifikujících vztazích, jako je vztah k transakci (pokud je modelován explicitně), a na dependent child key, jako je číslo řádky objednávky. Problém je, že i neidentifikující části, jako je vztah k zákazníkovi nebo produktu, jsou použity k vytvoření hash key pro řádek v link tabulce. Jinými slovy, hash key reprezentující kombinaci všech byznysových klíčů plus dependent child je ve skutečnosti hashdiff key, ne identifikátor transakce.

Na tom není nic špatného. Hashdiff key může být velmi mocný nástroj pro určení, zda je třeba řádek vložit, či nikoli. Pokud se neidentifikující vztahy transakce nikdy nezmění poté, co byla transakce odeslána do Data Vaultu, je grain linku dokonce stejný jako grain transakcí.

Problém je: v mnoha odvětvích se neidentifikující vztahy transakce mohou změnit nebo přijít až poté, co byla odeslána do Vaultu. Oba platné byznysové procesy vedou ke druhému záznamu v konvenčním Data Vault linku.

Tak proč měnit něco, co funguje?

Upřímně proto, že jsem nikdy nepochopil grain link tabulky: transakce má původně jeden řádek, když přichází poprvé. Pokud se zákazník objednávky změní, jak je popsáno výše, přidá se nový řádek. Takže nyní máme v link tabulce dva řádky pro stejnou transakci. Pokud se objednávka vrátí k prvnímu zákazníkovi, má stále dva řádky.

A druhým, důležitějším problémem je logický: link-na-link linky musí být vynechány, protože nejen byste rozbili své agilní procesy kvůli závislostem, ale také byste propojovali verze své transakce mezi sebou místo transakce samotné.

Tak jaké změny by podle mého osobního názoru mohly situaci vylepšit?

• Vytvořit hub, který vždy reprezentuje nejjemnější grain vaší transakce. Ve výše uvedeném příkladu: sales order line s BK order id v kombinaci s číslem řádky

• Zahrnout link na tento hub do své transakce. Zbavit se dependent child key v linku, protože už není nutný

• Připojit všechny kontextové atributy své transakce k hubu jako normální satelit místo připojení k linku

• Připojit tracking satelity, které kontrolují chybějící klíče ve zdroji, k tomuto hubu místo k linku

• Rozhodnout, zda se vaše transakce může po odeslání do Data Vaultu měnit

  • Pokud ano: načítejte svůj link jako SCD Type 2 load založený na tomto driving hubu — můžete nad tímto linkem vytvořit virtuální nebo materializovaný SCD Type 1 pohled particionováním podle keyed-instance hub key

  • Pokud ne: načítejte svůj link jako SCD Type 0 load založený na tomto driving hubu

• Pokud je výkon problémem, můžete stále použít přístup hashdiff k načítání SCD type 2 link tabulky

• Pokud potřebujete propojit dvě transakce, jednoduše vytvořte link mezi dvěma keyed-instance huby založený na správném grainu těchto transakcí

Zajímavé je, že když se podíváte na to, co musíte udělat technicky, děláte přesně to samé jako při načítání satelitu: porovnáváte atributy (propojené hash klíče) na základě hash key hubu.

Navíc přidání neidentifikujících částí linku se stává absolutně agilním, protože se prostě připojují ke stejnému hubu a lze je s existujícím linkem sjednotit bezeztrátově.

A jako poslední bod můžete volitelné části linku umístit do samostatné tabulky, která je řídce naplněna. S hubem držícím správný grain transakce můžete sloučit povinné a volitelné části. Použijte stejný pattern jako při kombinování různých satelitů.

Odporuje to standardu Data Vaultu?

Upřímně, ve většině částí věřím, že ne:

• Nic by vám nemělo bránit vytvořit hub na nejnižším grainu transakce a nazvat ho „keyed-instance" hubem.

• Ukládat atributy závislé na hub key jako satelit místo link satelitu? Také v tom nevidím problém.

• Je možné implementovat linky, které jsou skutečně identifikovány všemi propojenými objekty: ano, je to možné kombinací všech klíčů v hubu.

• Lze vše, co bylo dodáno, reprodukovat z uložených dat: ano

• Je zaručena losslessness (Verbundtreue): ano

Existuje jedno ale: implementace linku jako SCD type 2 load založeného na keyed instance hubu mění počet řádků v link tabulce. V mém příkladu s objednávkou, která přechází ze zákazníka A na B a zpět, by byly v původním patternu pouze 2 řádky. V novém designu má nyní 3 řádky. PK není hashdiff key založený na všech částech, ale keyed instance hub hash key + load time.

Takže ano, je tu malá odchylka od standardu, která podle mého názoru dává smysl, protože dotazování tabulky činí mnohem jednodušším: pokud chcete získat poslední verzi transakce, jednoduše ji particionujte podle driving hub key a vezměte poslední load date.

Není potřeba spojovat žádné jiné tabulky, abyste našli poslední verzi, jak byste museli udělat v původním návrhu. Stejné platí pro vytvoření kompletní historie transakce: jednoduše particionujte podle driving hub key. A nejdůležitější — grain je opět definován: každá verze transakce v čase má svůj vlastní řádek.

Mám to tedy používat?

Záleží na vás. Ale jsem si jistý, že pattern funguje, jak je popsáno, a prokázali jsme to v reálných scénářích včetně zpracování v téměř reálném čase, a líbí se mi výhody, které s sebou nese. Používám tedy tento pattern pro všechny linky? Ne! Ale používám ho pro všechny linky reprezentující transakce. Linky mezi master daty reprezentující kontext jsou jiný příběh, který proberu samostatně.