Stavební systém pro BI

Úvod

Také Vás občas napadá při rutinní rozšiřování BI řešení o nové datové zdroje, že tuto víceméně rutinní práci by šlo dělat jednodušeji a rychleji, nejlépe z velké části zautomatizovat?

Také jste si už po několikáté vyrobili “proprietární” generátory, které jsou super, protože umí přesně to, co potřebujete, ale nechce se Vám je dlouhodobě udržovat a tím ztrácí na hodnotě, nemluvě o potřebě uchovat know-how v dalších hlavách nástupců?

Také dost často pátráte po poznámkách, protože do modelu se občas některé věci píší neobratně?

Nebaví Vás udržovat dokumentaci transformačního modelu, protože je to “pakárna” a vy potřebujete jen rychle opravit chybu a spustit load dál? 

Pak Vás možná bude zajímat další text….

Stavební systém

Při delším přemýšlení mi IT obor (nejen programování, BI, reporting) připadá jako jeden z mála, kde si každý na další stavbu vyrábí nové a jiné cihly, překlady, základy. Osobně by mě zajímalo, kde se toto historicky zrodilo.

Protože už delší dobu nosím v hlavě návrh na níže popsané, hledal jsem “end to end” aplikační Framework, který by mě nezatěžoval technologií, ale umožňoval by mi rychle tvořit přidanou hodnotu a ne se patlat s objekty, mapováním, ORMem a tisíci a jednou knihovnou, technologií a závislostí…

Zatím “vyhrává” Oracle APEX, i když je to trošku k nevíře :o), ale pořád mi i přes jeho “mírnou těžkopádnost” vychází, jako jeden z těch lepších End to End řešení….Občas trošku se slzou v oku vzpomínám na ve své době proklínané Oracle Forms…(kompilace do runtime a časový overhead pro odladění byl strašný, ale když se podívám na dnešní nabídku, tak je …prázdno…a to svědomitě hledám a zkouším…a pro rýpaly bych uvedl, že v této technologii fungují systémy pro stovky concurentů (např. jeden velký primár ve velké české pojišťovně)

Nehledám slepence, ale hotový produkt, který je rychle a komfortně použitelný, obhospodařuje kvalitně celý životní cyklus a má rozumný licenční model. Budu rád za tipy od Vás…více hlav a monitorů více vidí. Prostě hledám takovou stavebnici ala stavební systémy. V prográmku si nakreslíte, co potřebujete, udělá Vám to kusovník a vytvoří objednávku, doplní potřebný režijní materiál a nemusíte řešit, jestli delší cihly, takové či makové překlady atd….). 

Jenže zde asi narážíme na ego spousty programátorů, že jen ten jejich framework je ten správný, ostatní to mají blbě…a každý si chce hrát se spodními vrstvami, ale už neřeší, že je třeba mít k tomu i rozumný prostup až do GUI a nedej bože podporu migrace, update, upgrade a srozumitelnou dokumentaci.

Situace v BI

Protože se dlouhá léta pohybuji na tomto trhu, a prošel jsem kolem většiny velkých datových skladů v ČR, situace ala aplikační framework je hodně podobná…

Technologická různorodost a “specializace nástrojů” z Vás dělá jejich otroka a žrouta času. A když už je něco zajímavého, tak to koupí někdo velký a zapouzdří a uzavře do jeho ekosystému a s produktem to jde do …háje, a to bez ohledu na onoho velkého hráče. Jeden příklad za všechny….(kdo mě zná, ví, že se nejvíce pohybuji v Oracle světě, ale nejen tam  ). Akvizice se samozřejmě musí vyplatit, pokud nejde čistě o eliminaci konkurence v zárodku, takže následuje zdražení, pardon, změna obchodního modelu či licenční politiky a nastává interní “cross sell” - další verze předěláme do našich “produktů”, aby byl vendor lock pevnější…a zákazník si mimochodem musel koupit i další naše produkty….(u Oracle typické, ale není tím výjimečný, je to standard)

Jeden příklad za všechny - hurá do historie…

Nikdo mi nemůže vyčítat neobjektivnost, s Oracle OWB jsme zde v ČR začínali, to byla ještě verze 2.0. Následovala 3.x a další verze. S verzí 3x jsme u telco operátora plnili zákaznický web tak, že po ukončení hovoru musela být informace o warm ratingu v zákaznické zóně na webu. …Za nějaký rok a pak se u nás ve firmě (Adastra) objevili pánové ze společnosti Sunopsis a nám spadla čelist…., bylo to jako potkat zhmotněný sen…každý z architektů už jsme za sebou měli pár domácích frameworků, ale typicky to bylo per projekt, proprietární, nebo na pár projektech konkrétního architekta. A teď nástroj, který měl obrovský potenciál…ani ne tak v tom, co právě uměl (metadata driven, možnost psaní vlastních generátorů, ELT koncept), ale co umožňoval. Byl technologicky nezávislý, takže ho s velkým přínosem nasazovala NCR nad Teradatu. Nástroj jako takový umožňoval i přidávat technologie, z čehož čerpá doposud…Přišel Oracle, položil na stůl asi dost velký peníz a pánové prodali. A tak vznikl Oracle Data Integrator a odstartoval interní souboj, který nástroj bude hrát v Oracle prim…OWB nebo ODI. Nějakou dobu to vypadalo na vítězství konceptu ODI, bohužel ale verze ODI 12 dle mého odhadu znamená, že interně vyhrál tým OWB, který “pašuje” do ODI filosofii OWB resp. obecně ETL…kostičky na joiny, AGG a podobně. Samozřejmě s argumentací po big data a potřebu paralelního zpracování. A také dle mého začala silná degradace produktu….verze 11 a GUI přehodili na JDeveloper či jaký a tím vznikl vítěz v kategorii jak znechutit práci…při sebevětším rozlišení monitoru Vám zbývá na efektivní práci maličké místo a pořád jen posunujete myší jednotlivé části GUI….Samozřejmě postupem času i další nástroje typu Informacica přišli s konceptem pushdown transformace, protože by se zákazník nedoplatil za trasformační servery a vedle tiše vrkal nezatížený DB server (či rack v případě Teradaty).

Dosud nástroj ODI používám na projektech, kde to jde, protože produktivita proti klasickému ETL několikanásobná, a člověk nemusí být ETL guru…(knowhow schováno v knowledge modulech). Když s ODI pracuji, často se u něj vztekám a pořád si říkám, že sednu a napíšu něco “svého”, zveřejním to jako open source a bude…že to jde dělat jednodušeji.

Projekt v BI

Na toto téma byly popsány stovky screenů, tak jen vypíchnu to relevantní:

• CASE nástroj - dobré pro datové modelování, na velkých projektech noční můra datového architekta….po dlouhé době různých kompromisů jsem zakotvil u Oracle Data SQL Modellru….hlavní důvody….podpora verzování do SVN, díky tomu podpora concurrent práce, umožňuje nastavit všechny vychytávky Oraclu (lokální partitioned indexy atd), a hlavně podporuje export dat do tzv. reporting schématu…(DB schéma, kde je model překlopen do relačních tabulek…bohužel jen relační model, fyzický ne…PROČ!!!! :(). V neposlední řadě, pokud máte koupenou Oracle DB, tak je plně zdarma….(mimochodem, také akvizice Oracle :o)). Podpora scriptů nad modelem, to už je ale spíš perlička…
• ETL/ELT nástroj - zde je možností přehršel, ale připadá mi, že to je jednostranná bitva…spousta ETL a proti tomu jen pád ELT či automated řešení (WhereScape atd)… ETL z principu nemám rád…protože projekty jsou živé, a takové přidání 2 atributů a jejich protažení 5ti ETLky a jejich krabičkami je krásně vypatlaný čas…nemluvě o uzavřenosti meta modelu u některých produktů a nemožnosti přistupovat k těmto metadatům…jiné nástroje si za přístup k metadatům nechají rády zaplatit další options…ale pro hodně různorodé datové zdroje to má svoji krásu….na pár kliknutí a krabiček se Excel/JSON/XML přestěhuje do DB tabulky….
• Řízeni loadu/procesů - tady vnímám u většiny produktů velkou slabinu, třeba jen taková jednoduchá podpora, že když mám v procesu 10 transformací v řadě a spadne mi to u deváté, tak aby se při opravě spustil od toho devátého kroku ve většině produktů představuje operaci oka přes druhou stranu těla…včetně ODI mimochodem…další slabinou jsou migrace mezi prostředími (typicky dev-test-produkce…změny konfigurací připojení, datových zdrojů atd…i když v tomto ODI ještě relativně exceluje svým konceptem)
• Reporting - toto je kapitola sama o sobě. Vyzkoušel jsme na projektech všechny možné reportingy (OBI, SAP BO, Jasper atd…)….a vždy to skončí v Excelu :)…tedy alespoň ze strany businessu je první otázka, zda to umí export do Excelu….v dnešní době se dobře prodávají různé selfBI nástroje, kde prodejci vesele tvrdí, že jen vezmete data a reportujete…nějak zapomněli, že musíte těm datům rozumět a vědět, co znamenají, aby jste neházeli do jednoho reportu hrušky a švestky…a jsme u jádra pudla….jak dodat businessu rozumně informace, jak data vznikají, na čem jsou závislá, a co vůbec znamenají….drtivá většina reportingových nástrojů podporuje vytvoření tzv. logické vrstvy, kde názvy tabulek a sloupců pojmenujete “businessově” a doplníte hodnotné komentáře typu tabulka obchodních vztahů, sloupeček identifikace zákazníka….a protože by se v těch tisíci atributech ztratila i Godzilla, tak se to celé rozseká na menší oblasti, které se pak musí vesele dál udržovat….a opět skřípete zuby…..místo efektivní práce děláte Ctrl C a V, protože holt páni vývojáři nepodporují strojový import ani export dat (vendor lock - model - ETL - reporting).
• Samozřejmě, můžete si koupit nástroje, které jsou teď v kurzu (line age nástroje, enterprise metadata repository a různé další vyšší formy vědění), které Vám za nemalé peníze a ohromnou spoustu času umožní přes různé můstky dostat k sobě metadata a informace, které vy máte běžně v hlavě…který report čerpá z kterých tabulek, a jak jsou ty plněny….(zdroje, transformace). JE to teď strašně in, ale mají jednu velkou vadu…nekdo musí vyexportovat data z nástrojů, další je musí naimportovat do “enterprise repository” nástrojů…a to vše přes různé verze jednotlivých použitých nástrojů…nu což, za 3 měsíce máte “hotovo” pro aktuální verzi řešení, a druhý den Vám přijde mail o novém release a můžete začít nanovo. Fakt smysluplná práce.

Můj přístup

Protože je člověk z povahy tvor líný dělat věci, které jej nebaví, tak jsem si udělal takovou linku. Je to celkem pěkné, ale není to úplně ono…

1. Export modelu do reporting schématu
2. Rozložil jsem si ODI repository na prvočinitele a vytvořil si view, kterými si dokážu na metadata sáhnout tak, jak potřebuji (verze 11)  - modely, tabulky, sloupce, interfaces, mapování, packages)
3. Nainstaloval jsem xwiki a zprovoznil rest API
4. Napsal si v PL/SQL procedury, které mi do xwiki generují informace o modelu, procesech, transformacích a to vše vzájemně provázané pomocí linků…historii mi drží xwiki sama (hash a nová verze, zobrazení změn ve verzích atd)
5. V Xwiki je publikována aktuální verze dokumentace - datový model s popisy, transformační model, procesy, které se starají o load (proces, parametry, pořadí transformační, smyčky atd) 

Samozřejmě to není žádná formule, ale pro business je to super, hlavně díky tomu, že SQL Data Modeler umožňuje komentáře do DB, ale i další, kam se dá psát businessovou řečí….
Relativně to funguje, ale je to jen berlička….

Má to ale i slabiny…

• Jako reporting knowhow dobrý, ale podpora pro aktivní vývoj nulová….
• Když píši poznámky, kde se kombinují informace o více tabulkách, tak musím jen v xwiki, JIRA atd…pro popis modelu z nadhledu chybí podpora (schéma a linky umím, ale…je to humpolácké)
• Ruční maslostroj - vyexportovat model do reporting schématu, spustit procky, udržovat nadstavbové parametry packages v ODI atd…
• Namodeluji v modelu, ale implementace co DB (nové tabulky super, změny raději ručně), potom musím reverse do ODI modelu a až poté mohu použít v interfaces….ručně aktualizace reportingu (detekce změn, popsat, publikovat v potřebných “business areas”, a přidat do reportů….moc rutinní práce, náchylnost k chybám, nízká produktivita… 

Vize

A po spoustě slov se dostávám k jádru pudla….Nešlo by to udělat úplně jinak?

Mít:

• Jednu jednoduchou repository (ideál souborovou xml/git s aplikační nadstavbou) – i když DB má také svoje krásy, toto ještě není úplně domyšleno, jde to oběma způsob, ale…
• Rest API (s podporou verzování - zde výhoda gitu, ale musel by se naučit, jak zacházet se sémantikou, v některých případech základní delta nestačí)
• Importem/exportem -  přes různé agenty - možnost tvorby různých nadstaveb - model, ETL/ELT, runtime, migrátor do DB a agentů atd
• Kompilace do “předpřipravených dotazů” s podporou runtime parametrů a proměnných?
• Runtime agent …vezme předkompilovaný kód, zajistí connections, file operace, naplnění proměnných a exekuci transformace…včetně logování :)
• Podpora tvorby datových setů (v různém jazyce ala multi language v Oracle OBI. Měli jsme zavedenou businessštinu a techničtinu :) ) - taková open data, ale s možností parametrizace datových setů podle reálných hodnot…a následně export do různých datových formátů resp. prostě xlsx…a když by to umělo ještě vložit ty data do šablony a doplnit do sheetu i podmínky z filtru, tak můžete reportingové platformy zahodit
• A to vše jako open source, či co nejvíce otevřené. Zde se musím poklonit myšlence ODI….knowledge moduly a přístup k metadatům pomocí odiref je prostě super věc….dá se přízpůsobit víceméně každému přístupu při budování skladu….
• Platit by šlo za různé agenty (nahrávání Excelů, datových setů s podporou metadat, event reporting, on data reporting, data quality, report publishing atd.)
• Předpřípravené modely pro kus oblastí (např. parties, adresses, contacts…contract/service atd) - to by byla efektivita, díky společné metodice názvosloví snadno adaptovatelné. A také už mě nebaví po desáté modelovat parties, deal atd…). Nemluvě o repository těchto modelů dovnitř firmy díky verzování této repository…
• Připravené šablony do xwiki či podobného nástroje (s podporu fulltext vyhledávání a výběru požadované výstupní informace…)
• Trasovatelné přes JIRu či jiný ticketing…(linky na tasky v xwiki atd) 
• Když to zaměřím na aplikační vývoj, tak de facto vzniká end to end framework, protože i GUI se dá přes metadata generovat…když mrknete na Ataccama RDM, tak to má GUI generované přes pár metadat a spoustu xlst transformací a vypadá to skvěle, použitelné je to skvěle a generuje to kód pro GWT toolkit…takže třeba se k tomu vytvořeno v sobě samém dostaneme…

Podle mého to zase není tak složité…samozřejmě až na detaily typu já vytvořím model tabulky a kolega už jej potřebuje změnit, resp. použít…takže nějaké DB či centrální části (typicky oblast modelu) se asi nevyhneme…

Realita:

• Jsem trvale vytížen projekty, času na podobné věci málo, i když bych rád…vždycky si vzpomenu na obrázek, jak jeden chytrý nabízí kolo, ale pánové táhnou káru s hranatými s omluvou na nedostatek času…to je přesně ono, ja jsem v jednu chvíli kolař, a hned další ten s tou károu…:). Pokaždé když se vztekám při práci si říkám, že už bych do toho měl fakt šlápnout…
• Musím se poklonit pánům, co tvořili model repository v ODI. Čistá práce pánové, i když univerzální občas až moc, ale když se do něj ponoříte, tak oceníte, že někdo v pár tabulkách dokázal uložit vše potřebné…
• Jsem ochoten sdílet vše výše uvedené, jediná podmínka je pak otevřenost řešení, nebo “neomezená licence” na všechny mé současné i budoucí projekty :o)
• Stále hledám framework, který by mi umožňil efektivní vývoj výše uvedenéhoj….de facto bych mohl vývoj dělat přímo v tomto nástroji (sám sobě frameworkem), ale zde je potřeba i GUI…a to já holt neumím, jsem datař tělem i duší….i když to GUI je poměrně jednoduché, ale pár desítek obrazovek to je…+ samozřejmě dost logiky v API….
• Nejraději bych to viděl na xml soubory (datový model, transformační model, migrace/upgrade, GUI konfigurace), ale dalo by se i v Oracle DB…i proto mě to trošku táhne do Apexu…verze 5.2 už konečně umí klasický datagrid…ale zase už je to hodně uzavřené v Apexu….
• Hledám partnery do této oblasti, preferuji otevřenost….možnost obchodního modelu viz free + platby za “knowledge moduly”, agenty, kusy připraveného datového modelu (včetně jazykové parametrizace pro skalní příznivce modelu v národním jazyce) atd…
• Na straně xwiki by bylo potřeba někoho šikovného (šablony - přizpůsobení korporátním barvičkám atd, aktivní makra pro přístup do logů a metadat v repository, persistence, generování resume pages, ochrana stránek před úpravou
• Reporting nad metadaty či integrace na jiné metadata nástroje (migrace na repository, export do stávající repository atd…) - jen jiné použití tvorby datových setů

Závěr:

Naznačil jsem jeden ze směrů, který je dle mého vynucován aktuálními trendy…nedostatek kvalifikovaných lidí (knowhow v knowledge modelu), ošetření publikace knowhow směrem k businessu (selfservice), a hlavně zvýšení produktivity rámcově o 100%….(namodeluji, vzápětí použiti v transofrmaci, a implementační knowledge modul mi umožní vygenerovat change script na míru)…Jejda, to by se pracovalo….

Cílem tohoto článku je rozpoutat diskuzi na téma otevřené metadata repository, nad kterou by byli vytvořeny další aplikace, které metadata využíjí i rozšíří. V neposlední řadě pak i hledám propojení na další lidičky, které jsou myšlenkově na stejné vlně a znají lidi, co by chtěli vyhrnout rukávy. Třeba více rukou a hlav = rychlejší pokrok…protože z toho hranatého kola už mě bolí hřbet…:)

PS: Napsáno česky, kdo by chtěl, může přeložit do jiných jazyků a volně publikovat, jen prosím o uvedení originálního zdroje.

 Autor Petr Šimbera, psimbera@gmail.com