Pro mnoho firem je datový sklad (Data Warehouse, DWH) spojený s velkými investicemi, dlouhou dobou potřebnou k jeho vývoji, následnému nasazení a velmi často také s řadou neúspěchů a slepých uliček. Když už se konečně stane pevnou součástí firemní architektury, pak někteří k němu shlíží jako k nástroji, který není synonymem pružnosti, levný na implementaci změnových požadavků, krátký time-to-market ani pro jednoduchost a transparentnost, ale je spíše vnímán jako nějaká instituce z dob mocnářství. Proto jsou datové sklady většinou doménou velkých firem a korporací, které díky svému rozsahu nejenže datový sklad nutně potřebují, ale také si jej a všechno kolem něj mohou dovolit. Doba se však změnila.

Tradiční přístup k vývoji datových skladů ve světě už několik posledních roků začíná patřit minulosti. Pokud už dnes je možné nechat celé domy po částech tisknout na 3D tiskárně a pak stavět dohromady jako ze stavebnice, proč by se v přeneseném slova smyslu něco podobného nedalo dělat i s datovými sklady? Řešení se nazývá DWH automation (DWA). Tedy proces maximálně automatizovaného vývoje a provozu datového skladu.

Na architektuře datového skladu, která nejčastěji mívá tři vrstvy (stage, jádro a data marty) naštěstí není třeba nic měnit - tady se žádná revoluce nekoná. Soustředit se je však nutné na jádro datového skladu, které v sobě skrývá datový model, metadatový popis celého skladu a na nástroje, které umožní datový sklad „vytisknout“ podle určitého vzoru nebo šablony.

Modelování

Stejně jako stavba domu, je i příprava automatizovaného budování DWH spojená s jeho modelováním. Stavění různých modelů je pro mnoho z nás už od dětství spojeno se zábavou a ani datový sklad nemusí být od začátku jen nuda a tvrdá práce analytiků a vývojářů. Nakonec vhodná vizualizace každého modelu také může zabránit nedorozuměním a nenaplněným očekáváním (každý z nás má jinou míru představivosti a abstrakce). Bez modelování by automatizace nebyla možná.

Datové sklady mívají specifické modely v porovnání s transakčními systémy. Pionýr datových skladů Ralph Kimball zavedl dimenzionální datové modely obsahující fakta hvězdicově obklopená zpřesňujícími a popisnými dimenzemi. Datový sklad postavený čistě na jeho metodice obsahuje denormalizovaná data v množství star schémat. Proti tomu stojí modely ve třetí normální formě (3NF) podle metodiky Billa Inmona, kde uspořádání tabulek vzdáleně připomíná sněhovou vločku (a proto se nazývají snowflake schémata). Obě metodiky se hodně prostupují a reálně vedou k mnoha hybridním podobám modelů.

V poslední době se ruku v ruce s automatizací DWH, ale také v souvislosti s propojováním světů datových skladů a velkých dat dostává ke slovu metodika datového modelování nazývaná Data Vault, která kombinuje to nejlepší z 3NF a dimenzionálního modelování. Data Vault modely poskytují maximální míru detailu, umožňují sledovat skutečnost v různých historických časových liniích a jsou flexibilní směrem k dalšímu rozšiřování (zejména, co se týče přidávání dalších vzájemných vazeb mezi prvky modelu). Díky velké míře obecnosti se pak tyto modely dobře adaptují na změny a nové potřeby. Skloňování termínů dimenze a fakta pomalu ustupuje termínům jako hub (používá se pro hlavní entity modelu jako například klient, produkt, smlouva apod.), link (vazba mezi hlavními entitami) a satelit (popisné dimenze).

Konkrétní datový model by měl vycházet z obchodního modelu společnosti, pro kterou je sklad budován. Ať už se navrhuje pro výrobní společnost, banku, pojišťovnu, leasingovou firmu, mobilního operátora či softwarehouse (ano, i takové firmy si datový sklad zaslouží), jádro DWH bude vždy vypadat jinak. Z obchodního modelu vyplyne, jestli centrem pozornosti v DWH budou klientské smlouvy, vyráběné produkty nebo realizované projekty. Kolem těchto center (hubů) v modelu se definuje košatá síť vzájemných vazeb a popisných dimenzí. Po celou dobu vytváření modelu je zapotřebí mít na paměti fakta, která je nutné uchovávat a to zejména s ohledem na ukazatele (KPIs), které datový sklad bude poskytovat (a které opět vycházejí z logiky a potřeb obchodního modelu). Fakta v modelu se následně budou vázat s vybranými huby. Toto je v modelování velmi důležité – pokud je faktem například částka pohledávky, je důležité vědět, jestli je vázána na konkrétní fakturu, smlouvu nebo jestli bude možné v modelu sledovat pohledávku třeba pouze v detailu na jednotlivého klienta. Výhodou je, že dnes je k dispozici množství vzorových datových modelů pro jednotlivé obchodní modely.

Metadata

Metadata jsou data o datech. Například tabulka v reportu obsahuje nějaká konkrétní data (třeba o měsíčních tržbách po produktech). Metadata k této tabulce strukturovaně sdělí, co znamenají řádky (měsíce) a sloupečky (produkty) této tabulky a co, je uvnitř tabulky (tržby v tisících korun). Na podobném jednoduchém principu je postaven celý komplexní metadatový model datového skladu. Popisuje nejen datový model jádra (a datových martů), ale také všechny potřebné datové zdroje na vstupu, jejich namapování do tabulek datového modelu, které se pak převádí na jednotlivé atomizované datové transformace a umožňuje popsat jejich závislosti. Například se nejprve do skladu načtou změny v produktovém katalogu a teprve potom fakta o produktech.

Zápis metadat lze provádět ve speciálních nástrojích pro design a automatizaci DWH, ale často se lze setkat s přístupem, kdy se při dodržení základních pravidel metadata zapisují do šablon v tabulkovém procesoru. Údaje z těchto šablon se potom načtou do zmíněného nástroje, kde se nejprve zkontrolují. Pokud jsou všechny kontroly (například na dodržení základních jmenných konvencí, platnost vzájemných odkazů mezi tabulkami apod.) v pořádku, je dobré metadata použít k vizualizaci budoucího řešení. Vizualizovaný model totiž pomůže odhalit mnoho nesrovnalostí. Opět se nabízí paralela se stavbou domu, kdy představa získaná pouze na základě nákresu na papíře a položkového výčtu výměr může být hodně odlišná od představy, kterou nabízí vizualizace domu v 3D modelu. Jistě proběhne několik iterací / cyklů / koleček změn, které povedou ke zpřesnění a vylepšení navrženého řešení, ale s automatizací DWH si lze dovolit ponechat v návrhu i některé chyby, na které se přijde později – nezapomeňme, že sklad nebudeme nákladně programovat, takže chybný prototyp lze odmítnout a vygenerovat nový.

Samotná existence metadatového modelu přináší spoustu dalších případů užití. Kromě generování datového skladu nebo změnových skriptů zmiňme především možnost provádění dopadových analýz, což může být velkým benefitem.

Mapování

Mapováním se nazývá sada poměrně detailních pravidel, která přesně určují, jaká data budou ukládány v jádru DWH. Přesněji řečeno, pro každý sloupec každé tabulky jádra je nutné určit, z jakého zdroje (například bankovního nebo účetního systému) budou data načítat. Pro tento účel se definují atomické datové transformace, kterých mohou být stovky a které mohou být od velice jednoduchých (hodnota ze sloupečku zdrojové tabulky se přepíše beze změny do cílové tabulky v DWH) až po velice složité (například výpočet opravné položky na základě mnoha vstupních údajů v různých systémech).

Jednoduché transformace je možné strojově generovat opět na základě metadat a složitější je nutné naprogramovat (typicky v SQL). Toto je jediný okamžik, kdy v automatizaci DWH vzniká ručně psaný kód. Důležité je, že tento kód se opět uloží společně s ostatními metadaty a při generování transformačních procedur jej lze kombinovat s tím, co je uloženo v šablonách.

Šablony

Vizualizace již ale hodně souvisí s výslednou podobou řešení. Tato podoba, ale není zapsaná pouze v metadatech. Hodně záleží také na podstatných detailech, které jsou uloženy ve vzorech, které obsahují informace například o konkrétních datových typech (v šabloně se například můžeme rozhodnout, že všechna finanční fakta budou mít přesnost na dvě desetinná místa napříč celým skladem), způsobech ukládání historických údajů v různých typech tabulek (vzory pro ukládání celých snímků dat nebo jen selektivní ukládání změněných záznamů), způsobech fyzického ukládání dat (například jak se budou vytvářet a používat database partitions) a mnoho dalších informací.

Šablony obsahují vzory pro všechny databázové objekty, ze kterých bude sklad postavený. Díky tomu jsou šablony specifické pro jednotlivé databázové platformy. Použitím šablon lze na základě stejného metadatového modelu vygenerovat stejný datový sklad nejprve pro MS SQL Server a následně jej přenést do prostředí Oracle nebo Teradata. Častější než změna celé databázové platformy ale bude třeba změna právě pravidel pro partitioning nebo historizaci dat.

Generování

Když je hotový metadatový model a vybrané a odladěné šablony datového skladu, lze spustit tisk, nebo přesněji řečeno vygenerování celého řešení ve zvoleném databázovém prostředí. Mezivýsledkem budou strojově připravené databázové skripty, po jejichž nasazení a spuštění dostáváme skutečně kompletně celé řešení – databázové struktury (nyní ještě prázdné, bez dat) a procedury k jejich naplnění. Napoprvé bude nutné uskutečnit prvotní naplnění skladu (historickými) daty a potom už pravidelné spouštění procedur, pro načítání a aktualizaci nových dat.

Naplnění daty

Datový sklad se naplňuje daty buď jednorázově (počáteční naplnění) nebo pravidelně. U pravidelného plnění je důležité, aby jednotlivé transformace proběhly ve správném pořadí, některé mohou běžet paralelně, ale v řadě případů mohou návazné transformace proběhnout až po doběhnutí několika předchozích transformací. Tyto závislosti jsou opět popsány detailně v metadatech a jsou využívány komponentou, která má za úkol řídit běh načítání DWH.

Součástí plnění datového skladu daty je průběžná kontrola datové kvality. To znamená ověřování vstupních dat podle definovaných požadavků a jednotné, přesně definované chování k nalezeným chybám. Ověřování kvality dat může být na úrovni jednotlivých sloupců, může se jednat i o rekonciliační reporty odhalující nekonzistence mezi jednotlivými systémy. 

Změny

Skutečná síla automatizovaného přístupu k DWH se ale projeví ve chvíli, kdy je zapotřebí ve skladu provádět zásadnější změny. Vytvoření nového datamartu nebo doplnění skladu o nová zdrojová data jsou nejčastěji se vyskytující změny. Generátor může poskytnout skripty pro změny (přidávání, odebírání, slučování vazeb a dimenzí) a to jak DDL tak i DML (nemění se jen struktura skladu, ale také přizpůsobují existující data). Někdy se může stát, že data uložená v DWH, např. z poslední měsíční uzávěrky, je potřeba opravit. Generátor pomocí metadat a šablon může dodat skripty, pomocí kterých se odroluje několik posledních historizačních operací, provede oprava dat a postupně načtou data nová.

Nástroje

DWA nástroje se někdy dělí do dvou skupin. Postup výroby datového skladu, který byl dosud popisován, je podporován model-driven nástroji. Do této skupiny patří například Kalido od Magnitude Software nebo Attunity od stejnojmenné firmy. Dalším příkladem je nástroj Quipu, Tento nástroj navíc nabízí například reverzní inženýrství modelu stávajícího DWH. Na domácím trhu do této kategorie patří nástroj DATA_FRAME.

Do druhé skupiny patří nástroje jako WhereSacpe a TimeExtender (ten ale podporuje i model-driven přístup). Zastánci těchto nástrojů věří, že nemá smysl ztrácet čas abstraktním modelováním a vytvářejí datový sklad kolem existujících dat, aniž by jim dávali nějakou výrazně změněnou strukturu. To sice dává možnost datovým analytikům bezprostředně prototypovat svoje nápady, v důsledku ale může vést k nepříliš konzistentním výsledkům a nemusí být naplněn jeden z hlavních cílů budování datového skladu – sdílená verze pravdy napříč celou organizací.

Společným znakem DWA nástrojů je to, že eliminují potřebu ETL nástrojů. Datové transformace jsou navrženy v rámci DWA a odehrávají se prostřednictvím vygenerovaných SQL procedur.

Určitým omezením DWA je zaměření na svět relačních databází. Většina nástrojů podporuje většinové databázové platformy jako MS SQL Server, Oracle, Exadata, Teradata. Některé nástroje, jako třeba TimeExtender sází na jednu platformu, konkrétně SQL Server.

Závěrem

DWA není nutné aplikovat jen na celé datové sklady. Principy DWA lze použít třeba ve finančním nebo obchodním oddělení na chytrý návrh a údržbu vlastního data martu. Je nesporné, že automatizovaný a agilní přístup k tvorbě, provozu a rozvoji DWH přináší snadno měřitelné úspory peněz a času a to mimo jiné tím, že je tolerantní k chybám v designu. Pokud první, druhá nebo další verze DWH nebyla navržena optimálně, je možné vygenerovat a znovu naplnit datový a to i s již existujícími daty.

Petr Hájek Autor pracuje pro společnost Profinit jako Senior Advisor pro Informační Management. Podílí se na dodávkách business intelligence řešení a datových skladů pro zákazníky především ve finančním sektoru. V oblasti datawarehouse automation je zastáncem Model Driven přístupu a metodiky Data Vault.