Reporting (a metadata) II.část

Zkusím bez obalu, tentokrát trochu techničtěji uvést návrh řešení, který má podle me zajímavou budoucnost….a velký potenciál…dodat businessu co si žádá...

Jak pracují reportingové platformy (z technického pohledu)

1. Musí být připravena (a udržována) metavrstva, která mapuje data do fyzického DB modelu (star schéma, snowflake schéma) - dimenze, fakta, ukazatele, hiearchie - a pojmenovává je z pohledu business významu. 
2. Tato metavrstva je v nějaké formě publikována (univerza v BO, prezentační oblast v Oracle OBI atd)
3. Uživatel se přihlásí do reportingové platformy a otevírá existující report, nebo zakládá nový -  nakliká, jaké informace potřebuje  a v jaké podobě, nastaví filtrační omezení
4. Při požadavku na zobrazení výsledku reportu je do datového úložiště generován dotaz (nyní nejčastěji SQL), který v rámci vytvoření dotazu :
• Načte požadované položky (sloupčky s SQL funkcionalitou)
• Generuje joiny mezi tabulkami do dotazu
• Aplikuje filtry (které jsou vstupními filtry reportů)
• Provádí agregaci dat, kde je možné agregovat už v DB  (group by, ti lepší umí i analytické funkce nebo přes klauzuli with)
5. Výstup (dataset) je načten do aplikačního serveru reportingové platformy
6. V případě tenkého klienta (zpracování využívá serverové CPU):
• Zde jsou provedeny další agregace a výpočtové operace (computed sloupce)
• Výstup je naformátován (tabulka, graf atd) a odeslán do prohlížeče 
7. V případě tlustého klienta: (probíhá na klientském CPU)
• Dataset odeslán na klientský počítač 
• Zde jsou provedeny další agregace a výpočtové operace (computed sloupce
• Výstup je naformátován (tabulka, graf atd) a klient vidí výstup (aby si jej mohl vyexportovat do Excelu :o) )
8. Při změně podmínek (změna zobrazení, změna filtrů, atd) je generován nový dotaz (často s využitím cache), který přepočte data, nebo seřadí, agreguje atd…
9. Při přechodech mezi reporty resp. drill down se spouští jiné reporty, které dostávají do vstupních parametrů hodnoty filtrů pro drilované data

a to je v kostce vše….že to není žádná raketová věda ?

Samozřejmě  i pár technických vychytávek a perliček existujících platforem:

• Předpočítané reporty - datasety pro vybrané reporty jsou vytvořeny a uloženy v dočasném úložišti nebo i paměti aplikačního serveru - pro zrychlení přístupu - de facto další stupeň datové agregace
• Aplikační servery si drží svoji “cache”, kde mají nejčastěji požadované data, různé materializace a agregace dat (ať žijí flash disky)

Aby to vše mohlo fungovat, tak jsou klíčové dvě věci:

1. Metadata - metavrstva musí být správně připravena a obsahovat, a mělo by to být i popsáno v business kontextu. Protože požadavky rostou, tak typicky pak jsou metavrtvy dost rozsáhlé (atomové elektrárny)
2. Aby ten, kdo tvoří report věděl, co vlastně tvoří, a z čeho report tvoří, musí vědět, s jakými daty pracuje, jaké jsou mezi nimi logické i technické vazby atd, a jak vlastně a odkud vznikají (zdroje) 

Metadata jsou mé oblíbené téma…z vlastní zkušenosti vím, že není snadné udržet aktuální informace a do ktrátkého komentáře v toolech popsat, jak je dané KPI počítáno, pokud to zrovna není jednoduchá SUM, MAX operace

Tyto informace musí být prostřednictvím reportingu podány business uživateli tak, aby pochopil, s čím pracuje (za mě nejtěžší fáze celého řešení). S tím se odvíjí i potřeba lineage analýzy (narazil jsme na pěkné www.sqldep.com), ale je třeba dodat další obsah a kontext (logické vazby a závislosti mezi objekty) popsané tak, aby byli pochopitelné pro business lidi.

Takže jak to vyřešit ?

Dávám Vám k úvaze, zda by to nemohlo fungovat třeba takto:

• Mít na jednom místě všechna potřebná metadata - aktuální, propojená, “čistá” - svatý grál...
• Mít Excel, odvahu a chuť dotáhnout…resp. zajímavá příležitost pro dodavatele řešení 

1. Sdílená metadata - na jednom místě

Metadata lze sdílet skrze nástroje (od CASE, přes ETL/ELT až po reporting) což není  nic moc objevného, dokonce to nabízí spousta reportingových platforem, ale mezi námi, zkuste to reálně použít ne jen pro PoC, ale v běžném provozu….i můj oblíbený nástroj ODI v tomto dost kulhá. Nezřídka je tato featurka zpoplatněná naprosto nesmyslně za enormní částky jako add-on. A co teprve v případě, kdy máte CASE napr. Sybase PowerDesigner, ETL Informaticu, a reporting SAP BO….

Druhou možností jsou enterprise metadata nástroje, které medata z jednotlivých toolu nasávají a snaží se je propojit….ale mezi námi, tyto tooly stojí víc, než celé reportingové platformy a mají jednu filosofickou botu….nikdy nejsou up-to-date a velmi často pak máte odpověd, že není publikována aktuální verze….a zde je právě to jinak a ještě se to bude měnit v nové verzi.

Pokud budou metadata sdíleny genericky (metadata driven přístup), máte vždy jistotu, že jsou aktuální, protože se podle nich generují transformační kódy datových transformací, loady ze zdrojů, nápočty kostek, i prezentované výstupy…. snímky a exportované verze….než naimportujete do nástroje a propojíte, tak už se zase něco změní a můžete opakovat znovu…takže nejlepší cesta je on-line metadata.

Na půl cesty

Protože se touto oblastní už nějakou dobu zabývám, tak jsem v praxi potkal spoustu hodně zajímavých “utilit”, které tuto oblast řešili, ale většinou je vytvořil jeden člověk pro jednu oblast….

Kupodivu nejde ani o nijak složité struktury (pokud neberu v potaz problematiku verzování, generováni change scriptů a potřebných datových transformací při migraci změny do DB). 

U některých zákazníků jsem vytvořil následující architekturu, která zdaleka není dokonalá, má overheady, ale je funkční…

• CASE: Oracle Data Modeler - verzujeme pres subversion
• ETL: Oracle Data Integrator - verzuje uvnitř sama sebe
• reporting BO: verzuje také uvnitř, ale k metadatů s enedá nijak rozumne dostat (uzavřené řešení)
• publish metadat: xwiki (www.xwiki.org)  - pomocí stránek v xwiki je generována dokumentace logického datového modelu a transformací (ODI), navzájem propojené

Co mě k tomu vedlo ?

1. Potřeba dokumentovat celé řešení (datový model, transformační model) - s cílem selfservice BI - minimalizovat potřebu businessu komunikovat  s IT, resp. aby si report byli schopní vytvořit sami, aby znali data své firmy, a když už nevědí, tak aby jsme měli jedno místo, odkud čerpáme informace…
2. Potřeba vyhledávat - full text, procházet několik PDF v různých verzích se mi fakt nechce…stejně tak učit všechny lidi z businessu, aby si uměli itevřít data modeler, a vyčíst co potřebují, mít možnost prolinku - tato tabulka je plněna tímto interface v ODI (transformační model), ze zdrojových tabulek - prolink na tabulky
3. Mít možnost komunikace s businessem v kontextu informace - ke stránce mi dají komentář (ať už ke sloupečku či transformaci)
4. Vize byla napojit to i na BO - report - položka (vazba na tabulku), transformační pravidlo v BO, a link na tabulku,z které je čerpáno - zde jsme zjistili,ze by jsme museli složitě parsovat export univerza z BO (textový soubor), další cesty jsme postupně eliminovali…na projektu s OBI jsem to zatím ještě nenasadil, ale tam by to mělo jít
5. Mít možnost sledovat verze (dokumentace) i tabulek, alespon nějak rozumně - využíváme historizaci stránek v xwiki

Řešení celkem funguje, ale má svoje overheady, které jsem zmínil i výše:

1. Potřeba sehrát medata na jedno místo - obdobné problémy s enterprise metadata repository

• Technický postup, jak vyexportovat data z OracleData Modeleru do jeho reporting schématu (featurka ODM), zkrátka z xml to uloží do DB do sady tabulek (bohužel nyní bez fyzického modelu) - pomocí GUI Datamodeleru
• Vysnímkovat data z work repository ODI - procedura v OracleDB
• BO jsme zatím odpískali
• Sustit proceduru v PL/SQL, která pomocí REST API xwiki aktualizuje stránky (spouštíme vše, sama xwiki se rozhoduje, jestli došlo ke změně stránky, tak ji zaverzuje), celké přegenerování dokumentace trvá cca 10minut (5 minut ODM generuje obsah xml do reposting repository)

A vše je v xwiki….datový model, transformační model, prolinky mezi nimi

Produkt XX

Aby to fungovalo lépe a netrpělo mouchami neakuálnosti metadata, a současně aby řešení přineslo nejvyšší přidanou hodnotu, tak by bylo vhodné mít všechna metadata on-line propojená v jedné repository, do které může přistupovat více lidí najednou a nad kterou pracuje více separátních aplikací (přes API). 

Jak:

1. Jedno úložiště metadat (CASE nástroj - uživatelsky přítulný, který bude podporovat metadata driven i ETL nástroj resp. definici transformace cíl-zdroj), a k tomu tvorba metauniverz (ala OData), která bude sebepopisná, s linky na dokuemntaci publikovanou ve fulltext systému (xwiki se celkem osvědčilo)
2. Vyřešit verzování (paralelně pracující vývojáři, ale i roll out DEV-TEST-PROD) - zde se mi pere má databázová duše s xml soubory a Gitem (Git toto se souboru umí velmi dobře, řešení v DB je peklo na zemi). Osobně lavíruji s použitím souborového formátu xml, s tím, model si aplikace načte do paměti (linq či podobné) a parciální save ukládá přímo do xml souborů, ty posléze uživatel pushne do nadřízené repository
3. Pár relativně jednoduchých GUI - tvorba DB modelu (s podporou vzorů, šablon atd), možnost definovat popisy až do úrovně prezentační vrstvy, podpora synonym (Party -> Odběratel, jedna tabulka, kda kontexty, filtr na data, ale současně i třeba jen některé stavy záznamu pro odběratele atd). Toto by se dalo udělat i jako plugin do prohlížeče, či webová aplikace (s tlustým klientem)
4. Mapper pro transformace - těchto jsem viděl už dost, protože to řešíme všichni….zde ale napojitelný na tuto metadatovou bází, a definice transoformace v univerzálním jazyku (já jsem pro SQL, kolega dělá v DSL, atd…), s podporou virtuálních tabulek (mezitransformace, které je ve výsledku subselectem a nemá persistována data). Opět samostatná appka
5. Stejně tak reporting - tvorba virtuálních oblastí (přes různé zdroje dat, s možností připojení datamartu k stage tabulce pro agilitu), vše popsáno s vazbou na zdroje prostřednictvím výše tvořených metadat…
6. Utilita, která sleduje změny v git repository a pro commitované objekty přegeneruje stránky v xwiki., tj. vše up-to-date, plně provázané, prolinkované….ve firemním face…zkrátka knowledge base, jak má být….
7. No a k tomu "už jen" generátory kódu, které na základě metadat a patternů generují transformační kód
8. To spojit do workflow (procesy a jejich závislosti, pořadí transformací, logování, repair atd) a nad tím reporting opět do wiki (denní page pro load, co se událo, kam byla která data nahrána atd)

Reporting:

Myslíte si, že jsem zapomněl na téma článku a rozepisuji svoje vize ? Jen částečně...protože nový reporting nad dat spravovanými výše uvedeným způsobem otevírá nové možnosti pro existující nástroje....

Takže ona reportingová platforma nové generace ?

Tu ale všichni znáte, existuje 20 let a jmenuje se MS Excel …od verze 2010 s pluginy typu PowerPivot, PowerQuery….a navíc s podporou napojení na datový zdroj OData.

Nejsem rozhodně M$ člověk či obchodník, ale musím říct, že tyto pluginy se mi jeví jako potenciální killery reportingových platforem….dáte businessu řešení v technologii, kterou dobře zná, je rozšiřitelná, univerzální….netrpí neduhy reportingových platforem, a nyní i výkonné  a komfortní nástroje (na rozumném notebooku není problém hrát i s  daty o velikosti několika milionů záznamů)

A co jí chybí k dokonalosti ?

1. Strana klienta: Pokud si trošku pohrajete s PowerPivot resp. s Odaty, tak zjistíte, že to tak user friendly není. Je třeba měnit zdrojový dotaz pro volání Odata (doplnění filtrů atd), na což dle mého chybí pěkný plugin do Excelu, který by prezentoval rozhranní OData (jaké jsou dostupné, s odkazy na knowledge base, a hlavně s možnost efektivního zadávání vstupních parametrů) - když se podíváte na youtube, je dost příkladů, jak napojit excel na datový zdroj Odata (velkou výhodou je, že OData poskytují k datům i metadata, ve kterých můžete mít i linky do xwiki), ale není to business komfortní…(jako reportingové platformy). Tomuto pluginu udělat pěkné gui, aby si člověk vybratl oblast, měl možnost definice filtrů, s možností rozkliku reálných hodnot do filtru atd....to by se dobře prodávalo.
2. Aplikační server: zde je více možností, mě se nejvíce líbí node.js a podobné technologie s rozšířeními pro generování OData API. Tento aplikační server působí ale výhradně jako převolávač, takže pokud Vaše DB umí OData API, tak stačí jen připojit...
3. Databáze - příprava definic dotazů, které slouží jako podklad pro volání agregátů s možností execute parametrů (propagace filtrů z OData volání až do zdrojových dotazů pro usnadnění tvorby exekučního plánu a dosažení maximálního výkonu). Buď formou view, view atd pro oblasti, aby bylo možné využít agregační sílu databáze - tj. 

připravit sady reportů v excelu (resp. z existujících udělat s mírnými úpravami šablony, které se napojí na datové zdroje pomocí pluginu).
De facto se jedná o datové rozhranní, kde OData poskytuje metadata, možnost propagace filtrů atd. Agregace jsou buď součástí definice rozhranní (podkladový dotaz), nebo se pak dělají až z výsledků naimportovaných do excelu prostředky excelu.

Co to znamená?

1. Úspora stovek tisíc Kč za nákup reportingové platformy, úspora statisíců při tvorbě reportingových oblastí a tvorby desítek reportů, aby vypadali stejně jako nynější reporty v excelu
2. Potenciální úspora za ETL (v řádech milionů CZK) - (když už máte všechny metadata i transformace, tak pak jde jen o to napsat generátory, které z těchto informací generují transformační skripty - metadata pattern driven ala ODI (mapping dává logiku, knowledge modul řeší technickou realizaci pro daou technologii) - buď můžete vzít ETL typu Clover ETL (www.cloveretl.com,  nebo jiné, kde lze transformace generovat jako xml nebo přes nějaké API), nebo jen rozumné workflow a generovat sady SQL a shell skriptů (protože pak už by bylo ETL jen jako velmi drahý scheduller). K tomu logování a máte platformu, kteoru Vám může leckdo závidět…ono to stejně někdo snad udělá jako produkt 
3. Business bude mít dál svůj excel, jek mu ho upgradujete na flexibilní tool pro analýzy datových zdrojů (dashboardy, pivot table, kontingenční tabulky) - spustí plugin, vybere si zdroje, nastaví filtry, execute…a má data…v kontingenčce či výpisu

Samozřejmě jsou i argumenty proti….pracovníci pak mají u sebe na počítačích kritická data firmy (zákaznícké báze atd…). Mezi námi, oni je tam mají vždycky, protože co jim brání si tyto data vyreportovat v reportingové platformě a vyexportovat do Excelu ?

Řešit se dá i umístěním úložiště těchto excelů, podporou šifrování (má i excel), zamykáním souborů pod heslem atd…Jsem skálopevně přesvědčena mohu i dokázat….kdo má přístup k datovému skladu, dostane data na lokální disk, pokud chce….

Budoucnost ?

A teď si tento tool představte i pro Big data, kde je situace s metadaty ještě více tristní…a máte…jednu platformu (napojit se na HCatalog, další generátory pro generování kódů v mapreduce, či sparku, pigu atd…výstup je opět soubor (typicky např. csv, který se dá načíst do excelu (samořejmě předpokládám silné filtrace a agregace na úrovni Hadoopu, výstup by měl být už jen pro prezentaci výstupů….

Nebylo by to pěkné ?

Závěr 

Takže ohledně reportingu....nevěřte nám z IT, reporting je jen dělník, který odedře část práce, ale nejvíce je jí na Vás a pak na tvůrcích metadat pro reportingové platformy a zajištění jejich provozu.

Až si toto jednou přečte někdo, kdo se naštve, a bude chtít vytvořit co popisuji, budu rád spolupracovat, strašně rád bych poté takovýto tool dodával zákazníkům, s tímto by byla radost jít do tendrů na dodávky.