Je datové modelování mrtvé?

Potřebujeme stále datové modely? Jaká je hodnota modelů? Proč datové modelování v minulosti selhávalo? Jak vytvářet datové modely? Jak vytvářet hodnotu skrze datové modelování? Na to vše se snažím odpovědět v následující prezentaci.

Je datové modelování mrtvé?

Zajímavá otázka zní: je datové modelování mrtvé? A není to hypotetická otázka. Začalo to před několika lety, když jsem byl na konferenci v USA a velmi známí datoví modeláři, kteří 30-40 let pracovali pro velké pojišťovny, se ptali: „Je datové modelování mrtvé?" Dělali svou práci, vytvářeli hodnotu, ale necítili se už oceňováni. Hodnota datového modelování už nebyla vnímána jako dříve.

Začněme pochopením, co datové modelování je a proč ho potřebujeme. Pro kontext: pracuji pro nástroj automatizace data warehousu zvaný Datavault Builder. Věříme v práci s byznysovými modely a jejich automatickou konverzi do funkčního kódu. Toto je můj osobní pohled.

Dovolte mi sdílet své profesní zkušenosti a zjednodušenou historii datového modelování. V oblasti data warehousingu pracuji od roku 2000. Nejprve jsem pracoval pro finanční instituci, kde jsme se zaměřovali na rekonciliaci dat. Později jsem přešel k práci s telekomunikačními proměnnými a vedl tým správy dat pro telekomunikačního operátora. Řešili jsme složitější úkoly.

V roce 2012 jsem narazil na výzvy s agilním data warehousingem a téměř real-time data warehousingem. Zkusil jsem použít data vault jako modelovací paradigma a fungovalo to dobře. Uvědomili jsme si však, že pro efektivitu je nutná automatizace. Toto poznání v roce 2012 položilo základy Datavault Builderu.

Dnes moje role zahrnuje pre-sales a post-sales aktivity, stejně jako prezentace pro školení lidí a sdílení nápadů v komunitě.

Co jsou datové modely?

Co pro mě modely znamenají? Dávají smysl složitým věcem tím, že je zjednodušují. Model je obvykle zjednodušená reprezentace něčeho složitějšího. Pokud si na Wikipedii vyhledáte „ontologie", najdete různé typy prvků: třídy nebo koncepty, vlastnosti, vztahy, axiomy a omezení. Tyto základní prvky datového modelování zůstaly v průběhu historie konzistentní. Znamená to, že pokud se naučíte datové modelování v určitém okamžiku, budete dobře připraveni i na mnoho dalších let.

Vezměme si příklad stromu. Skutečný strom se všemi svými listy a větvemi má tisíce různých aspektů. Zachytit skutečný strom v databázi by bylo obrovské a často zbytečné pro analytické účely. Můžeme vytvořit jednodušší model reprezentující klíčové charakteristiky. I s touto zjednodušenou reprezentací byste strom poznali. Počítání stromů by bylo přímočaré. Tato úroveň jednoduchosti stačí pro mnoho aplikací.

Existuje skvělý obrázek ilustrující vztah mezi skutečnou věcí a jejím modelem. Říká „Toto není dýmka"; je to obraz dýmky. Je to zjednodušená dvourozměrná reprezentace, ale stále poznáte, co to je. Je však důležité pamatovat, že to není ta skutečná věc.

Nyní zvažte les na tomto obrázku. Můžeme zjednodušit koncept: v lese je mnoho stromů. Lesník se stará o les nebo více lesů. Existují různé druhy stromů a vlastníci. Tímto jednoduchým obrázkem už chápete základní koncept.

To se stává prostředkem komunikace. Lidé z různých byznysových oblastí ve stejné firmě se mohou sejít a diskutovat se zajistěním stejného porozumění. Tato vrstva jim umožňuje najít společný základ mezi IT a byznysem.

Odkud to všechno přichází? Někteří tvrdí, že Edgar F. Codd je otcem relačních databází. V 70. letech napsal vlivnou knihu. Všechny následné přístupy k datovému modelování se opírají o stejné principy: datové modelování je o identifikaci a popisu věcí a o vytváření vztahů mezi nimi. Zahrnuje také práci s ACID a normalizaci.

Normalizace

Normalizace zahrnuje rozdělení dat do primárních klíčů pro identifikaci, cizích klíčů pro vytváření vztahů a atributů pro popis věcí. Hlavním cílem normalizace je odstranit duplicitu dat. Místo opakování celého popisu typu zákazníka pro každého zákazníka můžeme vytvořit samostatnou tabulku typů zákazníků a odkazovat na ni přes vztah.

Codd se zabýval OLTP systémy (online transaction processing). Později vznikly nové systémy zaměřené na lepší pohledy a reportingové schopnosti. Rychlost je klíčová, protože systémy data warehousingu pokrývají dlouhé období a chceme sledovat historické změny.

Ve světě data warehousingu preferujeme postupný přechod k používání byznysových klíčů pro identifikaci entit, čímž zajišťujeme stabilitu v čase, i když jsou IT systémy nahrazovány.

3NF Data Warehouse

V roce 1992 vstoupil na scénu Bill Inmon, často označovaný jako otec data warehousingu. Začal budovat data warehouse a definoval ho jako „subjektově orientovanou, nevolatilní, integrovanou, časově variabilní kolekci dat na podporu manažerských rozhodnutí". Tato definice stále platí pro mnoho případů.

Inmon používal databáze v třetí normální formě, které se v té době zlepšovaly. Zavedl surrogate keys pro ukládání různých verzí informací. Výzvou tohoto přístupu je udržovatelnost. Cizí klíče se používají, a v plně historizovaném data warehousu může jakákoli změna entity zákazníka ovlivnit celou historii souvisejících entit. Tento kaskádový efekt činí změny extrémně nákladnými.

Dimenzionální model

Jaký byl účel toho, čemu Kimball říkal conformed dimensions? Integroval všechna data z různých IT systémů do jediné dimenze zákazníka, denormalizoval data, protože úložiště se stalo mnohem levnějším. Denormalizace usnadňuje dotazování s méně joiny.

Další přístup, který Kimball zvolil, bylo budování štíhlých fact tabulek odkazujících na různé dimenze. Udržovatelnost zůstává problémem, zejména s historickými dimenzemi. Dopad je omezen na fact tabulku a dimenze, protože jsou denormalizované objekty.

Zde přichází Data Vault a navrhuje, abychom se vrátili k normalizovanému jádru a vylepšili ho místo nahrazování. Pro prezentaci dat zůstává dimenzionální model vhodný, ale měl by být vytvářen virtuálně nebo přepočítatelně z normalizovaného jádra.

Modelování Data Vault

Vracíme se ke konceptu definování a identifikace věcí, kde jediný objekt zvaný Hub uchovává pouze neměnný klíč. Atributy s historií jsou uloženy v samostatných databázových tabulkách (satelitech) a vztahy ve své vlastní tabulce vztahů (linkách). Oddělením funkcí dat do odlišných objektů Linstedt dosáhl výhod v udržovatelnosti.

I když nemusí být fyzicky tak efektivní jako star nebo snowflake, nabízí výhody v udržovatelnosti.

Vývoj od třetí normální formy k modelu Data Vault stále spoléhá na dimenzionální model pro dotazování, který může být virtuálním pohledem.

Další přístupy k modelování

Kromě těchto přístupů, pokud se chcete dozvědět více o Anchor Modeling, doporučuji starší články Larse Rönnbäcka. Řešil některé problémy, které nejsou dobře automatizované.

Existuje také přístup BEAM a ensemble logical modeling. Důraz je kladen nejprve na konceptuální model, pak identifikaci věcí a poté přidání vztahů a atributů.

Je datové modelování mrtvé?

Závěrečná otázka: je datové modelování mrtvé? Věřím, že vytvářet modely jen na papíře, bez napojení na automatizovanou implementaci v reálném světě, bez prokázání hodnoty přímo byznysovým uživatelům, není efektivní přístup. Pokud neautomatizujete kód, vývojáři budou jen těžko chápat hodnotu modelů.

Dalším problémem je čas potřebný k vytvoření datových modelů před zahájením implementace, což zpočátku nevytváří žádnou hodnotu. Místo toho musíme přijmout agilní datové modelování a propojit konceptuální, logické a fyzické implementace automatizovaným způsobem.

Konceptuální, logické a fyzické

Pro mě je konceptuální model výchozím bodem logického modelu a poté přidáváme vztahy a definice klíčů. Důležité je, aby mezi nimi byl přímý vztah, nejen z konceptuálního na logický, ale i k fyzickým implementacím. To by se mělo dít automaticky.

Je nutné obousměrné propojení. Pokud chceme znovuobjevit datové modely a učinit je efektivními, musíme přejít z konceptuálního na logický na fyzický v reálném čase.

CI/CD

Abychom toho dosáhli, musíme oddělit naše vývojová, testovací a produkční prostředí. Pokud usilujeme o skutečnou agilitu, můžeme pracovat s Gitem a GitFlow a přijmout přístup distribuovaného vývoje.

Ve světě data warehousingu nemáme přímý ekvivalent Java working folderu. Podle mého názoru je tím ekvivalentem sandbox.

Pipelines as Code

Alternativním řešením, které navrhují jiní, je použít pipelines as code. Když máme kód, můžeme použít přístup working folderu. Existuje však zásadní nevýhoda: chybí aspekt modelování, který dává procesu smysl. Místo zaměření na byznysové požadavky převažuje technologie a celý smysl se ztrácí.

Návrat modelů k životu

Prvním krokem je vytvořit agilní datový model, a zde přichází Data Vault. Souzní se základním konceptem bezproblémového začleňování nových prvků. Volné spojení prvků zaručuje nezávislost.

Druhým aspektem je automatizace transformace modelovacího artefaktu do fyzického artefaktu. Hub můžeme deterministicky transformovat na jeho fyzickou reprezentaci. Stejně tak můžeme vzít fyzickou tabulku a transformovat ji na logický objekt.

Nyní máme přístup podobný těm, kdo pracují s data pipelines as code, ale s přidanou vrstvou významu. To překlenuje propast a prospívá vývojářům i byznysovým profesionálům, čímž oživujeme naše datové modely.

Toto je podstata metodiky Data Vault a Datavault Builder umožňuje plně automatizovaný proces od modelování ke kódu.