Portál AbcLinuxu, 26. dubna 2024 04:29
Moderní a rychlé platformy pro business intelligence, ve formě SaaS neboli „Software as a Service“, společně s růstem objemu zákaznických dat a růstem komplexnosti analytických rozborů nutí vývojáře přicházet s netradičními postupy v oblasti uchovávání a zpracování dat. Jedním z těchto unikátních přístupů je i vytvoření NoSQL datového úložiště v prostředí Perl, které využívá společnost GoodData a její, převážně brněnský, ROLAP team. Pojďme si tento unikátní přístup k datům přiblížit.
Současné firmy, stejně tak jako ty dřívější, dokáží generovat velké objemy dat o svých aktivitách a více či méně je podrobují zkoumání. To vše proto, aby zachytily trendy nebo hrozby v tržních segmentech jejich zájmu. Co se však mění, je způsob, jakým chtějí svá data zkoumat. Stále více je zájem zaměřen na porovnání stavů v určitých okamžicích jejich historie, přičemž starší data jsou typicky zajímavá v delších intervalech, řádu měsíců, nová data jsou zajímavá v intervalech dnů.
ROLAP team společnosti GoodData proto začal hledat v současných datově orientovaných enginech způsob, jak uchovávat historická data a současně umožnit nahlížet na jejich stav v libovolném historickém okamžiku s ohledem na možnost tyto okamžiky porovnávat. Ačkoli se od začátku jevil ověřený přístup implementace pomalu se měnících dimenzí v konvenční relační databázi jako optimální, ukázalo se, že akceptovatelný výkon takovéhoto řešení je spojen s neakceptovatelnými náklady. Když bylo zřejmé, že žádná dostupná technologie nesplňuje požadavky v masovém měřítku, zaměřil se ROLAP team na hledání vlastního řešení.
Zákaznická data často představují tzv. "snapshot", tedy otisk stavu uživatelem sledovaných aktivit k určitému času. Jednotlivé snapshoty jsou svázané unikátní entitou, jež je platná přes vybrané snapshoty. Zákazník pak typicky potřebuje znát stav svého systému v určitém okamžiku, který porovnává s jiným. Zatímco data starší více než rok nejčastěji porovnává v kvartálním intervalu, data starší tří měsíců pak v měsíčním intervalu a data do tří měsíců po týdnech.
Velmi často poslední (neúplný) týden chce zákazník vidět po dnech. Použití konvenčního databázového serveru vede na tvorbu ohromného množství záznamů na úrovni jednotlivých dnů, které jsou často identické v po sobě následujících snapshotech. Namísto toho zaznamenání pouhých změn mezi jednotlivými snapshoty představuje malé množství dat. Z pohledu dat je vlastně zapotřebí jen přehrávat změny tak, jak se staly v čase, a v patřičný okamžik uživatelům data poskytnout. Tato jednoduchá věta pak popisuje myšlenku na jejímž konci je datové úložiště známé v GoodData jako EventStore.
Vše co se děje uvnitř EventStore se zcela vymyká klasickému světu SQL. Data na vstupu do EventStoru jsou rozbita na sloupce, ze sloupců jsou vybrány změněné hodnoty entity a jen ty jsou uložené společně s okamžikem jejich platnosti. Přečtení dat pak připomíná přehrávač, který do výstupní matice dat zapisuje změny. Na konci čtení je kompletní matice s hodnotami platnými v rozhodném časovém okamžiku. Přehrávač přitom na začátku přehrává rychle po kvartálech, na konci pomalu po dnech.
Zatímco princip NoSQL úložiště byl dostatečně zřejmý, programovací jazyk nikoliv. Implementace, ve které by toto unikátní řešení mohlo fungovat, potřebovalo neméně unikátní jazyk. Perl se v tomto ohledu ukázal jako velice mocný programovací jazyk. Zejména jeho práce s asociativními poli (hashes) zcela přesně vyhovovala potřebám úložiště. Identifikace změn v nově nahrávaných datech, stejně tak přehrávání změn a získávání požadovaných snapshotů, jsou v Perlu neuvěřitelně přímočaré.
Použití uzávěrů (closures) vede k rychlému a přitom stále dostatečně čitelnému kódu. Pro každou transformaci či agregaci dat, zadanou strukturovaným předpisem AST (Abstract syntax tree), je za běhu vygenerován kód, který “eval” zkompiluje do anonymní funkce (zde do “closure”). Přímo za běhu tak využíváme interpret jazyka Perl pro kompilaci dynamicky sestaveného kódu. S podobným řešením se ve statických jazycích potkáte jen výjimečně. Perl také umožnil velice efektivně implementovat podporu pro generování historických relací. Nyní je možné výstup EventStoru nahrát přímo do klasické relační databáze, včetně pomalu se měnících dimenzí a v ní provádět klasickou ROLAP analýzu.
Úspěch celého řešení byl završen nasazením EventStoru v cloudovém prostředí Amazonu. Bylo tak dotaženo k dokonalosti webové řešení pro analýzu dat, od sběru, přes uchování, přepočítání až po vizualizaci. “Webovost” řešení je umocněna skutečností, že většina dat od zákazníků pochází z jejich webových systémů. Dá se říci, že data jsou na webu uložena a zákazníci si je nakonec přes web i zobrazí a analyzují. Co dodat závěrem? Snad jen, že ROLAP team GoodData stále hledá inovátory, kteří se nebojí opustit klasická řešení.
Jiří Schmid pracuje v oblasti BI od roku 2003, postupně prošel pozicemi od analytika a implementátora BI projektů až k vývoji klíčových komponent BI software GoodData, kde v současnosti pracuje jako vedoucí ROLAP teamu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.