Datové sklady v kontextu CPM

Na to, že se oblast problematiky datových skladů a Corporate Performace Management (CPM) řešení dostává čím dál tím více ze sféry specializovaných IT oddělení, a stává se tak doménou jednotlivých byznys oddělení, je již asi zbytečné upozorňovat. Tento trend je tady již několik let a má své příznivce i odpůrce. Z našich osobních zkušeností u jednotlivých společností v České republice je možné vidět obě zmíněné skupiny.

Na straně IT jednak existuje celá řada pracovníků, která se může díky přesunu klíčových dovedností na pracovníky byznysu cítit méněcennými a může mít obavy o své pracovní místo. Existují i taková IT oddělení, která přijímají tento trend s nadšením, protože přesun celé řady prací na byznys oddělení zbavuje IT oddělení zodpovědnosti za věci, kterým pracovníci IT zcela nerozuměli a které vykonávali jen proto, že se týkaly datové vrstvy, a ta je do dnešní doby pro většinu byznysových pracovníků tabu.

Na straně byznysu je tento trend přijímán veskrze pozitivně. Zatím. Byznys oddělení jsou ta, která definují své potřeby týkající se řešení pro oblast CPM a logicky i požadují, aby tato řešení k nim měla co nejblíže a mohli si je spravovat sami uživatelé z řad byznysu. Na co ale obchodní uživatelé často nejsou připraveni, je jejich téměř úplná zodpovědnost za dané řešení. Každá mince má dvě strany a tady to platí dvojnásob. V okamžiku, kdy se IT oddělení vzdá zodpovědnosti za značnou část vlastní implementace řešení, nechce se zabývat problémy, které si vyrobí lidé v byznysu.

S CPM vám pomohou různé nástroje.

I zde se ukazuje, že naprosto zásadním aspektem úspěchu absorbování tohoto trendu je komunikace. Je tím míněna komunikace mezi IT a obchodem. Oba tyto světy jsou často od sebe na hony vzdálené a každá z nich doslova mluví jiným jazykem. Dokonce by se dalo říci, že jsou od sebe tak daleko, že některá klíčová slova jedné skupiny jsou zaklínadlem pro skupinu druhou. Je velmi zajímavé sledovat, jak se pozornost byznys auditoria jakéhokoliv workshopu rapidně zhorší po vyslovení pojmů jako procesor, ETL apod. Stejným zaklínacím efektem působí na obecenstvo z řad IT např. pojem zisk před zdaněním, auditem a opravnými položkami.

Metadata – klíč ke společné řeči byznysu a IT

Metadata představují prostředek, který dokáže případné třecí plochy mezi byznysem a IT do značné míry eliminovat.

To, co si představit pod pojmem metadata, je přinejmenším v IT světě poměrně dobře známé. Většinou jsou jako metadata označována data o datech. Pracovníci IT si jako metadata představují např. popisy datových struktur, ETL procesů, apod. Málo známý je ale tento pojem mezi pracovníky obchodního oddělení. Přitom metadata mají zásadní význam i tam. Jedná se o tzv. byznys metadata, která nepředstavují nic jiného než jednoznačné definice jednotlivých používaných pojmů a definice závislostí mezi nimi.

Největší přínos pro fungování organizace ale metadata přinášejí v okamžiku, kdy se byznys metadata a technická IT metadata propojí dohromady. V ten okamžik začne být jednoznačně definováno, že ten a ten obchodní pojem zmiňovaný ve všech BI reportech připravovaných pro jednání představenstva společnosti má datovou oporu v konkrétním sloupci, tabulce, databázi a serveru a že se data do tohoto sloupce dostala prostřednictvím určitého ETL procesu, který se spouští každý den v šest ráno a byl naposledy spuštěn tehdy a tehdy a přenesl do příslušné tabulky ten a ten počet datových záznamů.

Zásadnost tohoto propojení světa byznysu a IT vychází z toho, že se vše neustále vyvíjí. A to platí i pro požadavky byznys uživatelů. S existencí příslušně propojené metadatové vrstvy může v případě nutnosti IT pracovník provést příslušný zásah do datové či datově integrační infrastruktury tak, aby vyhověl požadavku, který je definován jazykem obchodu. Bez existence této vrstvy velmi reálně hrozí, že IT pracovník bude mít velký problém s pochopením toho, co po něm vlastně obchod chce a má tak v zásadě dvě možnosti. Buď se zeptá a bude doufat, že se zeptal té správné osoby, která mu neznámý pojem použitý v zadání úkolu objasní tak, jak je ve společnosti vnímán, nebo se pokusí vysvětlit si neznámý pojem po svém a bude doufat, že se ve svém výkladu zadání trefil do představ zadavatele ze strany obchodu.

IT by se mělo starat o to, jak běží byznys.

Přítomnost univerzální metadatové vrstvy propojující IT a byznys metadata je základem úspěchu jakéhokoliv CPM management řešení, protože právě v této vrstvě je možné provést odstínění byznys pracovníků od světa IT. Lidé z obchodního oddělení potřebují, aby ve svých reportech a analýzách viděli hodnoty, jejichž významu rozumí a jsou schopni jej popsat svým byznys jazykem tak, aniž by museli znát přesná jména databázových tabulek a sloupců, natož pak uměli psát SQL dotazy. Ideální pro ně je, když mají možnost si i sami vydefinovat podobu vlastních reportů a analýz a při této práci chtějí samozřejmě pracovat s pojmy, kterým rozumí. Vůbec je nemusí zajímat detaily datového modelu – od toho je právě dokáže odstínit kvalitní metadatový model.

Aby tato univerzální vrstva metadat mohla vzniknout, je samozřejmě zapotřebí, aby existoval někdo, kdo je na pomezí obchodu a IT a na úrovni metadat pomáhá definovat vazby mezi světem byznysu a IT. Protože je tento proces často velmi bolestivý a jeho součástí je i definice odpovědností za jednotlivé části metadatové vrstvy, naráží tato osoba často na velmi tuhý odpor některých jedinců v organizaci. Je naprosto nezbytné, aby tato osoba měla dostatek pravomocí k tomu, aby pasivitu odpůrců tohoto řešení zlomila.

Byznys uživatelé a jejich schopnost „uvařit“ datový sklad

V okamžiku, kdy je tématem přenesení velké části zodpovědností za podobu reportů a analýz na obchod a byznys uživatelé jsou také těmi, kdo provádí celou řadu ad hoc analýz a vytváří si vlastní adhoc reporty, hrozí poměrně výrazně, že svou aktivitou, bez potuchy o tom, co za hrůzné SQL konstrukce na pozadí jejich aktivit vznikají, datový sklad takříkajíc „uvaří“. To je přesně důvod, proč celá řada IT administrátorů vnímá zodpovědnost za CPM řešení v rukou obchodu za potenciálně velmi nebezpečný stav.

Velmi dobře si pamatuji na schůzky s některými našimi zákazníky týkající se dodaného CPM řešení, kde si obchodníci stěžovali na velmi špatnou výkonnost systému v případě, že si začnou definovat svoje vlastní ad hoc dotazy či provádět vlastní ad hoc analýzy. Tenkrát jsme jim s kolegy říkali, že to, co způsobuje onu „pomalost“ systému, není koncové CPM řešení, ale databázová vrstva pod ním. Snažili jsme se jim vysvětlit, že pokud nejsou dopředu schopni definovat, jak budou jejich ad hoc reporty a analýzy vypadat, jen těžko bude moci IT oddělení připravit příslušnou databázovou infrastrukturu tak, aby jejich dotazy byly vykonávány rychle. Naštěstí v poslední době začaly přicházet technologie, které tuto naši předchozí odpověď staví do jiného světla a které jistě potěší všechny koncové uživatele CPM řešení.

Tyto technologie přichází s poměrně logickým pozorováním. Využití relačních databází jako podkladové datové vrstvy pro analytické ad hoc dotazy sice přináší na jedné straně koncovým byznys uživatelům velkou flexibilitu, nicméně klasické relační databáze, které jsou optimalizované pro využití v rámci OLTP aplikací, nejsou na analyticky laděné dotazy stavěny. Analytické dotazy tak vedou k nechvalně proslulým full-skenům, jejichž důsledkem jsou neúnosné časy odezev databázového systému. Slabá výkonnost klasických relačních databází pak samozřejmě příslušným způsobem odrazuje analyticky laděné uživatele z řad obchodu (nejčastěji se v tomto případě rekrutují z řad oddělení marketingu, řízení rizik či finančního controllingu) od toho, aby řešení používaly.

Možná řešení pro relačně orientované datové sklady

Technologická řešení nejrůznějších dodavatelů nabízí celou řadu přístupů, jak se s analyticky laděnými ad hoc dotazy smysluplně popasovat. V zásadě je možné tyto přístupy principiálně rozdělit do tří kategorií:

• databázové akcelerátory udržující navíc kopii velké části dat (až jednotky TB) v paměti RAM
• sloupcové databáze ukládající relační data po sloupcích
• databázové technologie využívající masivního paralelismu a zpracování dotazů z velké části na úrovni HW.

Někteří dodavatelé technologií nabízejí i více než jeden z těchto přístupů a umí je i vhodně kombinovat. Všechny přístupy mají vedle diametrálních rozdílů i některé společné prvky. Mezi ty společné patří především snaha o minimalizaci čtení dat z disku, protože čtení z disku je stále řádově pomalejší než čtení dat z paměti RAM.

Propastný rozdíl mezi rychlostí čtení dat z pevného disku a pamětí RAM byl inspirací pro technologie paměťových databázových akcelerátorů, které se starají o to, aby co největší část dat datového skladu či datového tržiště, jež je použita při analytických dotazech, byla replikována do paměti RAM a náročné analytické dotazy mající full-skenový charakter mohly proběhnout na úrovni paměti RAM. Myšlenka je to velmi hezká a vedle výhod samozřejmě přináší i určité nevýhody.

První z nich je samozřejmě nutnost synchronizace mezi daty na disku a v paměti RAM, ale toto je v dodávaných řešeních poměrně obstojně řešeno. Druhou nevýhodou je nutnost mít pořízeno velké množství paměti RAM – nejčastěji stovky GB až jednotky TB. Aby byl problém s velikostí paměti RAM méně palčivý, jsou paměťově orientované technologie vybaveny i příslušnou efektivní kompresí dat a nezřídka využívají i principů sloupcově orientovaných databází.

Sloupcové databáze jsou takové databázové systémy, které interně data ukládají po sloupcích. Každý sloupec je navíc ukládán obvykle samostatně. Tento přístup má řadu benefitů, z nichž nejvýznamnější jsou:

• minimalizace objemu dat, který je nutné přečíst z disku, pouze na sloupce, jež jsou skutečně potřeba
• hodnoty uložené ve sloupcích jsou vlastně indexem, takže jednoduché indexy zde existují samy o sobě
• vysoká rychlost zpracování agregací
• možnost využití paralelního čtení/zápisu/agregací – každé vlákno může pracovat s jedním sloupcem
• data ve sloupcích v DWH se dají obvykle velmi dobře komprimovat.

Samozřejmě, že i sloupcové databáze mají své nevýhody. Těmi, které se asi nabízí na první pohled, jsou problémy vyplývající z toho, že sloupcová technologie musí chtě nechtě interagovat s klasickým relačním řádkově orientovaným světem. S problémy výkonnostního charakteru se tak můžeme setkat v okamžiku, kdy potřebujete provést konverzi řádkově orientovaného datového zdroje do sloupcové technologie. Problém je samozřejmě větší s větším objemem dat v řádu stovek GB až TB.

Poslední a v praxi velmi používaný přístup, je princip tzv. databázové appliance, který sází na využití principu hrubé síly. Vychází z teze, že v okamžiku, kdy analytik dopředu neví, na co se bude chtít zeptat, a dost možná bude potřeba projít na principu full-skenu obrovské množství dat, není nic lepšího, než problém vyřešit hrubou silou prostřednictvím metody rozděl a panuj s využitím skutečně masivního paralelismu a realizaci mnoha operací (dekomprimace, projekce, selekce, efektivní přístupová oprávnění) na úrovni specializovaného hardwaru, který tak zajistí, že se k jádrům paralelně běžících procesorů dostanou až ta data, která projdou poměrně velmi jemným hardwarovým sítem.

U těchto systémů se navíc využívá principu tzv. shared nothingarchitektury, který spočívá v tom, že každá podúloha, která vznikne rozdělením primární velké úlohy na menší části, má k dispozici kompletně vyhrazenou sadu prostředků zahrnující vlastní disk, cache paměť, jádro HW akcelerátoru provádějící výše zmíněné operace (dekomprimace, projekce, …) na HW úrovni a konečně samozřejmě konvenční jádro CPU. Nedochází zde tedy k žádným časově náročným a neefektivním komunikačním bojům, které se objevují v případě sdílení těchto prostředků.

V okamžiku, kdy se používá taktika hrubé síly, berou i v tomto případě za své standardní databázové prostředky jakými jsou např. indexy, table spaces či statistiky. S úspěchem jsou místo indexu použity tzv. zónové mapy, jejichž princip je založen na udržování informace o rozsahu hodnot jednotlivých atributů na příslušných discích tak, aby nebylo nutné číst z disku nepotřebná data. Neexistence zmíněných standardních databázových prostředků znamená u řešení prostřednictvím databázové appliance další výhodu, a tou jsou velmi nízké nároky na správu takového systému. Zákazník dostává v podstatě black-box, který se efektivním způsobem sám postará o naprostou většinu funkcí, jež od něj koncový byznys uživatel očekává.

Inteligentní byznys pomocí IT.

Jak je vidět, základních přístupů, jak zvládnout náročné analytické potřeby koncových byznys uživatelů, je několik a jednoduše není možné říci, který z nich je v daném případě nejvýhodnější. Nicméně platí, že pro opravdu velké objemy dat (nad 10 TB) není vhodné využití paměťových akcelerátorů. V takovém případě je vhodné sáhnout po sloupcové databázi či databázové appliance (tj. speciálním řešením, jež je postaveno na kombinaci HW a SW a využívajícím masivního paralelismu).

V případě databázové appliance není zásadním problémem zvládnout skutečně obrovské objemy dat v řádu PB. Mnohdy může být nejvýhodnějším řešením vyvážená kombinace různých diskutovaných přístupů. Jednotliví výrobci technologií samozřejmě vyzdvihují vlastnosti té své, která jde zatím vždy (až na jednu podstatnou výjimku) jedním z těchto tří diskutovaných směrů a mnohdy se neohlížejí na skutečné potřeby koncových zákazníků. Není však mnoho technologických společností, které dokážou nabídnout portfolio produktů zahrnující všechny tři zmiňované trendy, a poskytnout tak zákazníkovi to pravé řešení reflektující jeho potřeby.

Mezi velkými technologickými společnostmi ale existuje jedna, která zatím zmiňované trendy ve světě technologií pro oblast datových skladů zčásti ignoruje a snaží se zaujmout své potenciální zákazníky tvrzením, že je schopna jedinou databázovou platformou vyřešit jak potřeby standardních OLTP systémů (CRM, ERP atp.), tak i potřeby analytických aplikací, a sloužit tak jako platforma pro obrovské datové sklady. Vzhledem k tomu, že je tato platforma na světě příliš krátce, je jistě předčasné tento přístup kompletně odsuzovat k neúspěchu.

Jde to rychle

Oblast Corporate Performance Managementu je jednou z nejdynamičtěji se rozvíjejících oblastí na pomezí světa IT a byznysu. Trend jednoznačně směřuje ke stále větší zodpovědnosti obchodu, a to i na úrovni byznys správy řešení. Klíčovou roli v tomto netriviálním procesu hrají metadata, bez nichž si svět IT a byznys uživatelů nebude dokonale rozumět a bez nichž je velmi obtížné definovat zodpovědnosti za data a jejich kvalitu.

V okamžiku kdy je stav přenesení zodpovědnosti na byznys tak daleko, že jsou pracovníci jednotlivých byznys oddělení těmi, kdo definuje, jaká data se budou analyzovat a jakým způsobem, je potřeba efektivně řešit situace, kdy se pracovníci obchodního oddělení snaží prostřednictvím svých ad hoc dotazů a analýz dobrat ke kýženým výsledkům, ale na pozadí svým dopředu nepredikovatelným chováním (které je ale naprosto legitimní) extrémně zatěžují databáze datového skladu či datových tržišť. Naštěstí v dnešní době existují technologie, které se dokážou s tímto problémem efektivním způsobem vypořádat. Schovat hlavu do písku a neumožnit obchodnímu oddělení provádět své analýzy v rozumném čase jistě není řešením.

Volba té správné technologie pro oblast CPM a datových skladů je samozřejmě úkolem extrémně náročným. Z tohoto důvodu je také výsledné řešení u jednotlivých společností v naší zemi často složeno z několika HW a SW produktů a ne vždy si jednotlivé kousky výsledné skládačky spolu rozumí. Za svého mnohaletého působení na své stávající pozici jsem se setkal několikrát se situacemi, kdy se organizace pokoušela vybudovat fungující řešení postavené na špičkových technologiích řešících jednotlivé kostičky kýžené výsledné skládačky nejlepším možným způsobem, ale jednotlivé kostičky si spolu rozuměly poměrně velmi špatně, což mělo zásadní negativní dopad na úspěšnost projektů.

Je nepsaným pravidlem, že jednotlivé části řešení od stejného technologického dodavatele si spolu rozumí lépe než části řešení od dodavatelů různých. V některých aspektech výsledného řešení tato odlišnost nemusí hrát zásadní roli (sem patří typicky např. výběr databázové technologie pro datový sklad), ale existuje jedna oblast, kde je produktová kompatibilita velmi významná – a tou je výběr technologie pro oblast datové integrace (ETL, datová kvalita, problematika metadat, datový profiling a další) a BI technologie pro koncového uživatele. Nekompatibilita těchto dvou klíčových součástí řešení CPM může vést k zásadním problémům zejména na vrstvě metadat, která hraje zásadní roli při ustavení spolupráce IT a byznysu. Poměrně kvalitní kompatibilita těchto zmiňovaných částí řešení je obvykle zajištěna při výběru těchto technologií od stejného dodavatele.

Autor se zabývá oblastmi Information Management a Business Analytics & Process Optimization se společnosti IBM.