Co je satelit v Data Vaultu?

Huby říkají, co existuje. Linky říkají, jak k sobě věci patří. Žádný z nich neukládá jméno, zůstatek ani stav. To je úkol satelitu.

Řečeno jazykem klasického modelování: z atributů entity, tedy z jejího kontextu, se stane satelit. Tam, kde tabulka Customer obsahuje vedle customer_number také name, address a segment, uloží Data Vault číslo do hubu zákazníků a atributy do satelitu na tomto hubu.

Co je satelit

Satelit obsahuje popisné atributy hubu a každou jejich změnu v čase. Když se zákazník přestěhuje, satelit adresu nepřepíše: připojí nový řádek a ten starý zůstane. Každý řádek zaznamenává, kdy se dostal do vaultu a který systém ho dodal, takže každou verzi lze dohledat.

Pokud znáte dimenzionální modelování, satelit je Slowly Changing Dimension typu 2, aniž by se kdy spouštěl UPDATE. Historizaci lze na přání také vypnout, čímž vznikne nehistorizovaný satelit.

Anatomie satelitu

Primárním klíčem je hash klíč nadřazeného hubu plus Load Date.

Hash diff je volba, ne pravidlo

Podle učebnicového Data Vaultu se má pro detekci změn u každého řádku satelitu počítat hash diff. V praxi záleží na typu načítání:

• Inkrementální načítání: uložené řádky už svůj hash mají, takže hashovat jen příchozí řádky je levné. Hash diff vítězí.
• Plné načítání: hashovat při každém běhu miliony řádků stojí hodně výpočetního výkonu. Přímé porovnání sloupců (IS DISTINCT FROM) bývá na moderních enginech rychlejší.
• Široké tabulky: běžně se tvrdí, že z hashování nejvíce těží široké tabulky. Pravdě je blíž opak: širší řádky znamenají delší řetězce, které se musí spojit a zahashovat.

Datavault Builder podporuje hash diff jako možnost, ne jako povinnost. Hash diff dostane v této sérii vlastní článek.

Transakce mají vlastní satelit

Množství, ceny a částky řádku objednávky popisují samotnou transakci. Pokud má řádek objednávky svůj grain hub, jak popisuje článek o linku, patří tyto hodnoty do běžného satelitu na tomto grain hubu, kde se historizují jako jakýkoli jiný atribut.

Jak satelity rozdělit

• Podle zdrojového systému. Data z CRM a ERP nikdy nesdílejí jeden raw satelit. Každý zdroj si zachovává vlastní původ dat, beze změny.
• Podle rychlosti změn. Denní zůstatek a oficiální název v jednom satelitu znamenají, že se název každý den zkopíruje do nového řádku. Rychle a pomalu se měnící atributy patří do samostatných satelitů.
• Podle citlivosti. Osobní údaje, jako je jméno, e-mail a datum narození, patří do vlastního satelitu, odděleně od atributů, které nikoho neidentifikují. Pro reporting podle GDPR pak existuje jedno jasné místo, kam se podívat, a přístupová pravidla nebo žádost o výmaz se týkají jen tohoto satelitu.
• Nikdy nemazat. Když záznam ve zdroji zmizí, jeho historie zůstane. Record tracking satelit označí, že klíč už se nedodává. Výjimkou je zákonná povinnost informace odstranit, například žádost o výmaz podle GDPR, a právě tam se rozdělení podle citlivosti vyplatí.

Co se mění s Datavault Builderem

Zdrojové sloupce mapujete na satelit v modelu. Detekce změn, načítání, které pouze připojuje nové řádky, i auditní sloupce se vygenerují a běží nativně na Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle nebo PostgreSQL. Dvě situace, které klasické načítací vzory nezvládají, jsou pokryty hned od začátku:

• Bitemporální načítání. Finanční instituce se zpracováním na konci dne má dvě časové osy: kdy něco platilo pro byznys a kdy to datový sklad načetl. Datavault Builder zpracovává historii konce dne a historii načítání společně a vytváří bitemporální satelity. Jak to funguje, popisuje článek „Bi-temporální zpracování dat“; bitemporalita dostane v této sérii také vlastní článek.
• Více než jedna změna na jedno načtení. Data lake často dodá v jedné dávce několik verzí téhož záznamu. Klasické vzory načítají jednu změnu na klíč a běh, takže byste museli data procházet ve smyčce a každá verze by dostala datum okamžiku načtení. Datavault Builder načte všechny změny v jedné dávce a každý záznam umístí na časovou osu tam, kde ho data lake zaznamenal.