Sci-fi aneb Cesta k applience pro vyhodnocování událostí

Úvod:

Prosím berte s mírnou rezervou, čestně prohlašuji, že jsem před napsáním tohoto příspěvku nepožil žádný alkohol ani omamné látky, je to výsledek přemýšlení a k zamyšlení...

V jednom svém projektu na zlepšení logistiky na papíře resp. do šuplíku jsem řešil, sledování velkého množství vozidel v geografickém kontextu (silnice, oblast, zeme atd).

Jde o obecnou úlohu, objekt, jeho stav, jeho pohyb a vazba mezi objektem a geografickym kontextem (vsem vozidlum na dane silnici v useku x-y (oblast) posli zpravu).

Rád bych se s Vámi podělil, jak jsme dopadl, když jsme zkoušel na toto aplikovat hadoop…(na papíře a v pár malých testech).

O čem je Hadoop zde nebudu rozebírat, na to najdete odkazů dost.

Co zajílao mě, že data jsou v rámci zajištění dostupnosti bez HW redundance v systému celkem 3x (na 3 uzlech). Bohužel se jedná o identické kopie (což je ostatně důvodem). Jenže, když si vezmete, jak by ve výše uvedeném případu mohla vypadat vypadat vstupní datová věta:

<timestamp> <object> <action event> <GPS> <direction vector> <object instance info> <aditional structured info>

Když použiji geolokace, tak GPS mi dává k dispozici možnost přiřadit jeden nebo více GIS objektů (úsek silnice, silnice, město, region, země -zjednodušeně).

Vazba mezi objektem a GIS objektem je dynamická, resp. jak se objekt pohybuje, vznikají a zanikají vazby mezi sledovaným objektem a GIS objektem.

Zároveň je třeba zachovávat “instančnost objektu” kdyz daným místem projiždím dvěma jízdami, abych měl možnost data rozlišit.

Když budu toto ukládat do HDFS, tak super, mám tam uloženo, rozdistribuováno víceméně náhodně, resp. jaké jsou zde možné “partitioning” strategy ?

• Objekt - tento se přímo nabízí, ale objekt může jet přes půl Evropy, takže když budu dělat statistiky typu které objekty mi projeli danou oblastí v rozmezí dnů X-Y, tak prohledávám všechna data na přítomnost oblasti, k tomu je třeba určit instanční start a cíl (kontext jízdy).
• Oblast či jiný GIS objekt - podobně, jen když sleduji objekt, opět bych musel číst vše (čímž rozumíme číst na úrovni uzlů)

Když si představíte objem dat pro 100.000 vozidel, s 10ti vteřinovou periodou za 3 roky, tak máte velmi zajímavé číslo…x3 (redundance hadoop) - tak to je tak na 50ti uzlový cluster…(nemám nějak přesně vypočteno). Toto bych musel živit investičně a energeticky….

Protože potřebuji objekty sledovat near-real time, uvažoval jsme i o Sharku, resp. tupples v paměti….ale tam jsme narazil na problém sdílení tupples mezi úlohami…nějak nedomyšleno….

Jak z toho ven….potřebuji mít v paměti resp. rychle dostupné informace o aktivních objektech, statistické reporty ať jdou klidně na disk…

Připomnělo mi to boj s telco CDR záznamy a použitím MPP systémů….jedna dimenze distribuce dat je prostě málo…

Každý výrobce se s tím popral po svém (appliance systémy), které na řadu úloh představují opravdu 100 násobné zrychlení, ale v okamžiku konkurent objemných dotazů ( sada dotazů per sledovaný objekt a sada dotazů per GIS objekt by potřebovali opravdu silné trubky….). Trošku vyjímkou je Oraclovská Exadata, které to vyřešila šalamounsky tzv. inteligentní storage (Oracle Exadata Storage server), který umožňuje pushdown základních filtrů na tzv. chytrou storage (CPU, disky, a hoodně drahý Oracle software, který filtruje datové bloky, případně počítá parciální výsledky a až ty posílá ke konsolidaci do DB serveru (nepřipomíná Vám to něco ? :o)) )

Jenže jak udržet v paměti 100tisíce instancí objektů (vyřešit jejich persistenci) atd…to už by musela být pěkná farma…

Tak jsme přemýšlel, jak by se dalo vyřešit:

• Distribuce dat pro redundanci, ale současně využitelnou pro více partitioning strategy, tj. jednou záznam distribuovat v kontextu objektu, a podruhé /resp. vícekrát hiearchcky) v geo kontextu…abych neměl data 6x (3x přes objekt, 3x přes geo)
• Jak to uživit výkonově, jak umožnit distribuované výpočty, resp. udržení instancí objektů, on-event alerty pro komunikaci s objektem atd…
• Jak by to mohlo fungovat, aby to nepotřebovalo druhý Temelín…(to by se našim Rakouským sousedům nelíbilo…)

Vyšla mi z toho hypotetická architektura:

• Inteligentní distribouvaná storage s vlastní výpočetní kapacitou pro push down filtra (základní selektivita) - typická úloha, načti mi posledních 1000 událostí daného objektu, načti mi události objektů, které se v daném čase měli vazbu na daný GEO objekt….šlo by realizovat jednotlivými uzly distribuovaného výpočetního systmu na bázi PC, ale to mi připadá šíleně neefektivní…
• Využití grafických karet s rozšířenou pamětí - GPUček to má dost (s jejich běžnou rychlostí by dokázalo jedno GPU obsluhovat stovky či tisíce instancí objektů, pamět by musela být trošku větší), persistence (stav objektu v čase opět na iteligentní storage do třetí  kopie dat, organizovaná instančně)
• Alternativa ke grafickým kartám - ARM procesory ve velmi vysoké hustotě typu HP MoonLight…ale i tak by to bylo na několik racků…zase kvůli nižšímu výkonu procesorů

Technické řešení:

• Z pohledu inteligentni storage se mi jeví jako nejlepší jednoúčelové počítače (SSD disk cca 256GB, 4core CPU, RAM 16GB a centrální napájení, 10GbE, nebo PCI-e - zkrátka jednoúčelová krabička s velmi vysokou výpočetni a storage hustotou - CPU nemusí být high-tech, ale zase to nesmí být pomalá potvůrka, OS na bázi Linuxu…velmi velmi ořezaného…(ideálně ala blade šasi, kam se jen strkají další moduly….což je blízko IBM Netezee, i když ta teď integruje na jedné kartě jak storage (disk), tak výpočetní výkon (programovatelná hradla)). Volání API storage (inteligentní API - dej mi události a parametry, persistuj stav, vrať mi stav instance objektu v čase - po určitou dobu pro fail-over). SSD uvažuji kvůli trendu klesající ceny, velmi nízké spotřebě (ono už se zaplatí jen z pohledu dimenzování zdroje, úspory energie a chlazení), i když nic asi nebrání tiered storage (6TB disk jako archív pro data ageing) ušetří několik SSD, ale několikanásobně zpomalí odezvu při historických dotazech na tyto data
• Jeden výpočetní uzel obsahuje v sobě tolik storage modulů, kolik mu umožní sběrnice PCI-e, případně síťový protokol (privátní síť) a propustnost
• Stejně tak obsahuje výpočetní uzel jednu nebo více grafických karet, které umí adresovat resp. volat služby inteligentní storage - případně je zde možné uvažovat právě o specifikcýh řešeních pro distribuovaný computing…ale to už není úplně moje doména…
• A to celé může běžet na Linuxu jako black box…

Je to nejspíš hudba budoucnosti, ale narůstající exploze dat nás k něčemu takovému povede…zkrátka inteligentní applience stroj pro zpracování událostí (eventů, na instancích objektů s možností near real-time vyhodnocování). Vše s nízkou spotřebou, velkou hustotou osazení, a obrovskou datovou kapacitou…

Využití pro další úlohy:

• Pohyb lidí ve městě, optimalizace městské dopravy, dopravní proudy v rámci města, uživatelům nabízí plný komfort (ala navigace s aktuální dopravou - nasedni na tramvaj č.3, která dojede na zastávku xx za 3 minuty, poloha tramvaje,obsazenost, atd)
• Internet věcí - predikce spotřeby energií (elektrická i plyn)  v kontextu regionu GIS oblast - ulice, městská část,  ve vazbě na počasí v daném místě, a především vazba na připojenou rozvodnu - energetici omluví za zkratku)
• Logistika zboží - multimodal, sledování zásilky, od kamionových přeprav, přes kontejnerové, vagóny, až po kusové zásilky (e-shop)
• Válečná resp. vojenská logistika - kvalitní armádní logistika vyhrává války….informační podpora je jeden z nejdůležitějších faktorů - plynulé zásobování (tanky v pohybu, četa v pohybu, nahlášené požadavky na doplnění (spotřeba střeliva  a pohonných hmot od tanku), záchranné operace, po monitoring jednotek (v kontaktu, přesun na pozici, komunikace, kooperace, enemy detection s využitím UAV - pohybující se objekt, můj není, je to nepřítel :o)  atd) 

Zkrátka je hodně lidských i strojových činností, které když se překlopí na události (stavový diagram) a v kontextu Geo dávají velké využití.

Takže hurá do budoucnosti…

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. 

Tentokrát na téma reporting

Úvod

Předpokládám, že každý ze čtenářů přichází do styku s reportingem. Realizace reportingu:

1. MS Excel kolující po firmě mailem, či na sdíleném disku jako shared workbook

2. Reporting v rámci core systému

3. “Enterprise” reporting platformy

4. Přístup k datům s heslem, co si vyrobíš to máš

5. Nové generace reporting systémů typu Tableau (a desítky dalších)

Každé z těchto cest, kterými se může Váš reporting vydat má svá pro i proti. V tomto postu jsem se zaměřil na reporting nad BI/DWH řešeními, i když v hodně věcech lze chápat jako generalizované (operativní reporting má velmi shodné rysy).

Mám za sebou poměrně dost projektů, kde se tvořili BI/DWH řešení a vždy jedna z nejbolavějších věcí byla, jaký reporting nad řešením vytvořit, aby bylo:

1. User friendly
2. Nákladově efektivní
3. Dlouhodobě udržitelné
4. Pokrývalo potřeby businessu na formu výstupů, zajištění distribuce atd…
5. Aby se to líbilo IT či deccision makerům - ale o tomto dnes mluvit nebudeme…:o)

Bohužel najít reportingové řešení, které by splňovalo všechny 4 ukazatele je jako potkat Yetiho a naučit ho twítovat…

Kritéria

1. User friendly

Tato oblast opravdu není u klasických reportingových platforem příliš silná….především, pokud máte danou technologii naučit a motivovat k používání pracovníky, kteří “myslí v Excelu”.  Kdo má zkušenosti s těmito nástroji, měl by mi dát za pravdu…o tomto by se dali napsat tisíce blogů, ale stačí se podívat na google…

2. Nákladová efektivita

Enterprise reportingové platformy jsou investice v řádu vyšších stovek tisíc u minimálních konfigurací, u větších firem i jednotky a desítky milionů. Když zde zkusíte počítat selským rozumem business case (úspora času, dostupnost informací, zlepšení chodu firmy), tak aby Vám to vyšlo musíte být hodně kreativní, a když do nákladů započtete správně i ssuport a náklady na provoz, tak to prostě vyjít nemůže…
Zde můžete namátnout, že nové generace reportingů typu Tableau jsou přece self-service atd. Jenže jedna věc je používat v týmu 3-4 lidí, a druhá když to nasadíte o 50ti lidí (správa verzí, metadata zdrojů, connection do datových zdrojů atd). Vyzkoušel jsme si několik různých řešení této generace a výpočtem podle list price to zase tak levná řešení nejsou…počítáno na analytický tým 10ti lidí a k tomu 1-2 analytici jako provozní podpora.

3. Dlouhodobá udržitelnost

Kdo má zkušenosti s migracemi Oracle OBI 10 na 11, kdo zkoušel migrovat SAP BO z patchsetu na patchset, nebo nedejbože vyšší verzi, (před pár lety to i u dalších typu Cognos, Microstrategy atd bylo hodně podobné), ten mi dá za pravdu, že v danou chvíli by hodil na vývojové tými těchto nástrojů napalm (ať si užijí to samé peklo jako vy při migracích a upgradech).
Bohužel většina těchto enterprise nástrojů jsou slepence postupně nakoupených technologií, které firmy nakoupili postupně, původní týmy resp. autoři si užívají na Havaji (dobře prodali), a nové týmy se snaží dát dohromady kolečka a čtverečky, aby vytvořili jednu plnou plochu…čest jim za odvahu a odhodlání, ale to vám problém nevyřeší...ale když koupíte nástroj za několik milionů, tak se business vlastníkovi špatně vysvětluje, že musí dál používat MSIE 9, protože daná verze reportingu s vyššími verzemi blbne a nasadit novější verzi znamená nákladu v řádu desítek MDs.

Klasická provozní správa těchto platforem je také práce pro Sysifose, od uživatelských práv, přes publikace reportů, dokumentaci reportů, sdílení dat, omezení přístupu k datům atd…

Nové generace reporting toolů jsou na tom velmi podobně, i když zde spíše vlivem překotného vývoje, je otázkou, kterým směrem se budou dále vyvíjet.

Samozřejmě existují i cloud řešení, kde provoz řeší poskytovatel řešení, ale i tak potřebujete na své straně člověka, který jim bude umět vysvětlit, co vlastně chcete a stejně tak bude evangelizátorem zpátky do firmy.

4. Potřeby businessu

Veličina stálá asi jako kapka rtuti na špičce jehly...mění se ze dne na den, často se otočí kormidlem o 180 stupňů. Ale to je zkrátka business, protože musí umět reagovat nejen na změny na trhu, ale i na změny nejvyššího managementu :o). Controlling oddělení, finanční analytici, scoring oddělení, zákaznická péče jsou tímto téměř pověstní, ale beru to tak, že na nich většinou leží velká odpovědnost, tak chtějí adekvátní informační podporu.
Mezi nejčastější požadavky patří - přidejte mi tam ještě tuto dimenzi, přes kterou chci data vidět, chtěl bych si data měnit (what-if - požadavek na writeback), chci si nad nimi počítat…..zkrátka vše, co poskytuje nástroj, který se jmenuje excel…a na kterém tito lidé vyrostli a dost těžko jim budete vysvětlovat, že to co už mají ve firmě koupené je přeci jenom Excel, ale vy jim dodáte potvůrku za několik milionů a ona nebude zdaleka umět ani polovinu toho, co umí excel…takže ve finále jim uděláte tabulkové reporty, které si oni vyexportují do excelu a nad nimi tvoří své modely a kalkulačky…tímto výsledkem končí dle mé zkušenosti 4/5 projektů. Sice jsou dashboardy, s prokliky až na úplný detail, ale xls datasheet je prostě datasheet. A ať chcete nebo ne, reporting platformy jsou v ČR už 2 desetiletí, ale na tomto se pořád nic nezměnilo…a dle mého ani nezmění…

Výsledek nasazení 

Z počátku nadšení (pěkné barvičky, pekné grafy, a umí to i export do excelu...), přes mírnou rozpačitost...tohle musím udělat pokaždé, a toto to fakt neumí, vždyť v excelu je to trivka, vždyť já si chci jen uložit poznámku k tomuto řádku...až po mírný odpor, resp. hledání oklik a dalších cest.
Opět nelze všechny projekty poaušalizovat, ale dost často po několika letech sleduji, jak se řešení provozuje, ale kdysi slibovaný přínos pro business se nějak nekonal (ať již z důvodu změny priorit business, nebo se tam ještě nestihlo dodělat to a to a bude to za půl roku...)

Důvody:

1. Nastavení očekávání zákazníků spojených s implementací reporting platformy (obchodník slíbí standardně zázrak do dvou dnů)
2. Dodavatelé reportingových nástrojů - drží zažitý koncept uby nehty, protože vytvořit opravdu novou generaci, který by toto řešila a někdo ji koupil jsou investice v řádu desítek či spíše stovek milionů a oni utratili z anákup existujících i několikanásobně vyšší částky.
3. Implementátoři - snaha prosadit používání platformy na vše je ve výsledku kontraproduktivní. Na druhou stranu, řešení  pro 3 datové analytiky za někollik milionů se také špatně vysvětluje (i když v důsledku může firmě zefektivněním jejich činnosti ušetřit miliony)
4. Vývojový proces - zde je třeba rozdělit kategorie, které se především odlišují dobou dodání výstupu a kvalitou výstupu (od nejrychlejšího po nejpomalejší):

• Selfservice - aneb “urob si sám” - pro fázi discovery super, ale zkuste to pak rutinně udržovat pro desítky uživatelů, to se Vám pak na poradě sejdou reporty, které budou jako z jiné galaxie
• Vývoj na straně businessu  - toto funguje, ale znamená to mít člověka, který překlene technickou část reportingu (umí s ním dělat včetně kliček) a má business znalost (ví, co jsou hrušky a jablka a nemíchá je). Bohužel tito lidé se hledají velmi špatně, ale může to takto fungovat i dlouhodobě (zkušenost z mnoha projektů, kde se kolikrát genericky z businessu překlopil člověk, který si vzal řšení za své a udělal na něm kariéru)
• Vývoj reportů IT lidmi - bohužel se stále tento přístup v mnoha firmách drží, nepochopitelně, ale ono to v podstatě vyhovuje oběma stranám - business e může vymluvit, že to IT nepochopilo, a stejně tak IT má alespon trvalý přísun práce (a dobře se obhajuje budget)

Závěr této části:

Rozhodně neříkám, že je vše špatně, daří se i dobré projekty, zde paušalizuji, ale shrnuto a podtrženo:

1. Spousta práce na obou stranách dost často s diskutabilním přínosem (protože pod reportingem je potřeba typicky vytvořit i datový sklad)
2. Když už se řešení podaří vytvořit, business naučit používat, tak se neustále potýkáte s chováním, kdy daný postup v jednom reportu jde, ale v druhé z nějakého záhadného dlvodu ne…(a není to mezi monitorem a židlí)
3. A ve finále platforma slouží jako portál pro exporty do excelu....

A výsledek z pohledu investice ? (resp. business ownera) 

• Utratili jsme budget (často zvýšen v průběhu boje, neb se zapomnělo na pár desítek reportů),  řešení jakžtakž funguje, i když má pár masařek, pokrývá část potřeb (typicky ty nejjednodušší ). Ale zkuste si udělat usage statistiky (a vyčlenit z nich exporty do excelu). Dost možná se budete divit, tlouct hlavou do zdi…
• Náklady na provoz jsou z pohledu poměru srování k přínosu enormní (u větší firmy 2+ lidé fulltime, aby se to udrželo v provozu, a jako support lidem, co vyvíjejí reporty - ať již business jako self, nebo IT). Zkuste si to zjistit u Vás ve firmě ? (v menších firmách je to jeden člověk, ale představte si, že třeba odejde...)
• A klíčoví lidé z businessu (marketing, controlling, atd) dál hledá okliky, jak rychle dostat výstupy, které včera nikdo nechtěl a pozítří je má prezentovat představenstvu… (vyexportuj report do excelu, k tomu připojí další excel, lookup, pivot table, pár výpočtu a bulharských konstant a je  doma….za pár večerů, ale splní úkol pro představenstvo…)

Trošku smutné....

A je jiná cesta ? Je možné změnit myšlení na obou stranách a najít společnou cestu, která bude efektivní, udržitelná a user friendly ? (to si nechávám jako téma na příště)