Z kraje léta spustila GoodData do ostrého provozu svůj nový analytický engine AQE (Algebraic Query Engine), který má oficiální produktové jméno GoodData XAE. XAE je ale určitě čínsky “podviživený kuře”, takže já zůstanu u AQE :-) Od prvního momentu je to pro mě věc s největší přidanou hodnotou - když mi to Miki ukazoval, zamiloval jsem se na první dobrou :-)
Úvod lehce ze široka
Každý systém, který má ambice vizualizovat data, potřebuje nějaký matematický aparát. Pokud jako vstup budu mít prodané položky a jména obchodníků a budu z toho chtít zjistit medián obratu obchodníka, musí nejprve někde na pozadí proběhnout sečtení všech prodaných položek v daném měsíci pro každého obchodníka a nad tímto výsledkem pak můžeme počítat medián. Levá tabulka je surový vstup, pravá je odvozená za pochodu a většinou si ani neuvědomujeme, že takové mezi výstupy vznikají. Nad tou pravou pak můžu počítat věci jako nejlepší obchodník měsíce, průměrný/“mediánový”, aj.:
Pokud nemám robustní analytický backend, nemůžu si dovolit dělat “co mě napadne”, ale musím uživatele svázat do nějakých předpřipravených “vertikálních” analýz (churn analýza zákazníků eshopu, RFM segmentace, kohorty předplatného, aj.). Vrtat se v datech je možné mnoha způsoby. Kromě GoodData, které tady chystám vyvrcholení :), máte na trhu BI nástroje jako Birst, Domo, Klipfolio, RJMetrics, Jaspersoft, Pentaho a mrtě dalších. Vypadají super! O některých z nich jsem se otřel dříve. Osamocený datový analytik pak ještě sáhne po Rku, SPSS, RapidMineru, Weku, aj. - ale to nejsou BI nástroje.
Většina ze zmíněných BI nástrojů nemá propracovaný matematický aparát, takže vám umožní čísla sečíst, spočítat četnost prvků, zjistit maximum, minimum a průměr. Tady je to krásně vidět na promo videu RJMetrics.
Systémy jako je Domo.com nebo KlipFolio.com pak řeší problém absence matematického aparátu trochu trikem. Lidem nabízejí spoustu matematických funkcní - jak v excelu - které jdou ale aplikovat na jednotlivé tabulky, ale ne na celý datový model. Někdo si řekne, že je to jedno, ale opak je pravdou - tohle je prubířský kámen všeho kolem datové analytiky. Zkusím vysvětlit proč.
Hranice našeho pískoviště stojí na aplikaci zákona o zachování "business energie”:
"pokud nedokážeme našemu zákazníkovi vydělat větší peníze než ho naše služby (a licence GoodData) stojí, nebude s náma spolupracovat"
Pokud vezmeme výpis faktur ze SAPu a nakreslíme graf “jak to roste”, poženou nás zákazníci jako sedláky u Chlumce. My potřebujeme trochu víc, potřebujeme dávat za pochodu jednotlivé datové dimenze do souvislostí (dimenze = tématický soubor dat, nejčastěji reprezentovaný jako tabulka dat - dimenze mezi sebou nemusí mít žádné jasně definované vazby; tabulku v analytickém projektu nazýváme datasetem).
V momentě, kdy dáme jednotlivým dimenzím souvislosti, vznikne logický datový model. Logický model popisuje “business” souvislosti a často není shodný s technickým modelem, ve kterém ukládá data nějaký systém. Pokud má například Mironet e-shop, je databáze za tímto eshopem optimalizovaná pro potřeby e-shopu, nikoliv finanční, obchodní a/nebo subscription analytiky. Čím složitější je prostředí, jehož data se analyzují, tím méně podobností mají technické a analytické datové modely. Nízká (strukturální) podobnost zdrojových dat a dat, které potřebujeme k analýze, vyřazuje většinu GoodData konkurence.
Dám příklad na našem interním projektu. Interní projekt jsem vybral proto, že obsahuje logický model, který potřebujeme používat sami pro sebe. Není to tedy uměle nafouklé “protože to zákazník zaplatí”.
Do GoodData nahráváme různé tabulky, které jsou spojené vazbama. Vazby definují logický model; logický model pak definuje “co jde s daty dělat". Náš interní projekt slouží k měření naší vlastní aktivity a spojuje data z českého účetnictví (Pohoda), kanadského účetnictví (QuickBooks), z vykazovací cloudové aplikace Paymo.biz a několik Google Drive dokumentů. V interním projektu máme 18 datasetů a 4 datumové dimenze.
Obecnější model vypadá takto a detailní model vypadá takto. Červeně jsem označil jméno klienta, černě jméno našeho analytika a modře odpracované hodiny. Chci tím ukázat, že jsou jednotlivé související informace v projektu bohatě rozprostřeny. Díky vazbám GoodData ví, co dohromady dává smysl.
Nad tímhle modelem stavíme dashboardy, ve kterých sledujeme, jak nám jde práce od ruky, srovnáváme mezi sebou měsíce, lidi, druhy práce, koukáme na náklady a výnosy, aj.
Cokoliv v tom našem dashboardu je přesně šité na míru naší potřebě. Nikdo nám nediktoval, jak se to bude chovat. Tahle volnost je pro nás kritická a jen díky ní dokážeme stavět nad GoodData cokoliv si zamaneme = je jen na naší schopnosti, jestli uspějeme a zákazník s náma bude spokojený.
Trochu pastička na zákazníka je v tom, že podobný dashboard je možné na první pohled sestavit v ledasčem. Mám tady příklady dashboardů z KlipFolio. Jsou super, ale mají jedno podstatné “ale” - všechny vizuální komponenty jsou objekty, které načítají informace z předem připravených dat, které někdo designoval přesně pro účely toho dashboardu. Není možné to překroutit a začít třeba 2 čísla ze dvou podkladových tabulek podělit a sledovat jejich podíl v čase. A month-to-date toho podílu už vůbec ne. O situaci, kdy máte data, ve kterých jsou vazby “many to many”, nemá smysl vůbec mluvit. Velká výhoda těhle BI produktů (řikají si BI, ale BI to není) je v tom, že jsou líbivé a podbízivé. Člověk na startu neodhadne, že si kupuje křáp, který vlastně neumí o moc víc než jeho Excel.
Proč je trh zaplavený produkty, které hrají na maličkém hřišti se stěnama vylepenýma cool vizualizacema? Nevím, ale lidi jedou na vlně “Cool, BigData analytika!” a jsou hladový po čemkoliv co má podobu reportu. Tématická analytika se udělá za pár dní - transformace transakcí a počítání "Customer lifetime value" je snadná, dokud mi každý neřiká jak to chce mít podle sebe.
"Nikdo na světě kromě GoodData nemá schopnost provozovat analytické projekty, které jsou 100% svobodné svojí podstatou (datovým modelem) a v těchto projektech nechat lidi dělat cokoliv chtějí, aniž by museli být low-level data analytici a/nebo programátoři. Bum!”
Jak to GoodData dělá?
V Excelu je každý zvyklý sečíst sloupeček “A” tím, že dá do libovolné buňky vzoreček “=SUM(A:A)”. V GoodData sečte sloupeček A tím, že napíše vzoreček “SELECT SUM(A)”. Jazyku kterým se v GoodData tyhle vzorečky píšou se říká MAQL - mnohodimenzionální analytický dotazovací jazyk (Multi-Dimension Analytical Query Language). Zní to děsivě, ale zatím to každéj dal, i Pavel Hacker má z Keboola Academy diplom na Report Mastera :-). Pokud se podíváte zpátky na ten můj datový model z našeho interního projektu, můžete si říct, že chcete průměrný počet hodin z jedné strany datového modelu, ale filtrovaný třeba typem úkonu, seskupený podle popisu projektů a jména klienta a to celé jen pro úkony, které proběhly o víkendu odpoledne. Všechny metriky budou vypadat jako “SELECT AVG(hours_entries) WHERE name(task) = úklid”. Multidimenzionalita toho jazyka je v tom, že neřešíte, v jaké dimenzi je jméno úkolu a v jakém je vztahu k počtu vykázaných hodin a nedejbože jménu klienta. GoodData, resp. vztahy v logickém modelu, který pro klienta navrhujeme my, za vás pořeší úplně všechno.
A teď jádro pudla: pokud vám připravím (denormalizovanou) tabulku do Excelu ve které to bude pěkně na zakázku sesypané dohromady, nebude to nikomu kdo tohle čte, dávat problém spočítat. Pokud vám dám data rozdělená podle dimenzí (a dimenze bude často jiný zdroj dat - jako jsou výstupy z našeho českého a kanadského účetnictví), bude to potřeba zpracovat mnohem složitějc (nejspíš začnete v SQL joinovat jako zuřivý). Jelikož se svět nedá popsat jednou tabulkou (teda asi dá - key value pair - ale nepůjde s ní moc pracovat), je pohled přes mnoho dimenzí tím podstatným. Bez něj je všechno jen takové to domácí počítáníčko :)
Kalibrace pozornosti: teď už byste pomalu mohli říct “wow”, protože pokud se vrtáte v datech, mohli byste mít vysokou míru afinity k popsané situaci :)
Jdeme do finále
Výroba dotazovacího jazyka je nejsložitější úkol, který v BI dneska můžete řešit. Není to o uložení velkých dat, není to o jejich zpracování, ani vykreslení grafů nebo příprava API, aby se dalo s váma perfektně spolupracovat. Dotazovací jazyk si nekoupíte ani za měsíc nenaprogramujete.
Pokud bude jazyk složitej, nebude ho umět zákazník používat. Pokud bude jazyk hloupej, nebude s ním schopný dělat co chce. GoodData má jednoduchý jazyk na vyjádření jakkoliv složitých otázek směřovaných do dat a zároveň má aparát, kterým tento jazyk napasuje na jakkoliv složitý BI projekt (logický datový model). V případě GoodData je to právě MAQL/AQE - z mého pohledu je to tou jedinou věcí, která je na GoodData neopakovatelná. Kluci z Brna a Prahy - Tomáš Janoušek, David Kubečka a Tomáš Jirotka - navíc rozšířili AQE sadou matematických důkazů (složitá algebra), díky kterým je možné rychle testovat, že nové funkce v AQE platí pro jakékoliv druhy logických modelů. GoodData tak má jistotu, že překlady mezi (MAQL) metrikama a nějakým SQL na spodních databázích jsou správně. AQE tak pro běžného člověka překlene propast, která ho dělí od low-level scriptování.
UPDATE 17.11.2013: MAQL je dotazovací jazyk, který je na základě logického modelu (LDM) překládaný pomocí MAQL interpretru (dříve QT - "Query Tree" engine) do stromu dotazů. Tyhle dotazy jsou vlastně definice "star joinů", ze kterých "Star Join Generator" (SJG) vyrábí podle fyzického datového modelu (PDM - leží pod LDM) vlastní SQL dotazy na DB backend. Celé to na začátku dal dohromady Michal Dovrtěl a Hynek Vychodil. Nová implementace AQE tohle všechno navíc položila na solidní matematický základ ROLAP algebry (podobá se relační algebře).
Po týdnech přemlouvání a úplatcích jsem vydyndal lehce cenzurované vzory dotazů, které AQE vyrábí z metrik, které jsem pro tenhle účel napsal. Tuším, že je to poprvé, kdy to někdo veřejně publikuje!
Pro srovnání jsem vzal datový model z Report Master kurzu v Keboola Academy a nad ním udělal report:
Graf mi na pravé Y ose ukazuje, kolik jsem udělal v Afgánistánu, Albánii, Alžíru a Americké Samoe kontraktů za posledních 13 měsíců. Na levé Y ose mi ukazuje modrou čárou, kolik mi přinesl průměrný obchodník a zelenou čárou mi ukazuje kolik byl medián obratu na obchodníka v daném měsíci (vstupy jsou de-facto shodné s ukázkovou tabulkou úplně na začátku).
Graf tedy obsahuje tři metriky (viz legenda pod grafem):
- "# IDs” = SELECT COUNT(ID (Orders)) - spočítá počet prvků
- “prumer na obchodnika” = SELECT AVG(obrat na obchodníka) - spočítá průměr z (pomocné) metriky počítající sumu obratu na obchodníka
- “median na obchodnika” = SELECT MEDIAN(obrat na obchodníka) - spočítá medián z (pomocné) metriky počítající sumu obratu na obchodníka
a pomocná metrika
- "obrat na obchodníka” = SELECT SUM(totalPrice (Orders)) BY employeeName (Employees) - spočítá hodnoty položek (nějaké prodeje) na úrovni obchodníka
Všechno je samovysvětlující, snad jedině “BY”, což mi definuje, že se mi peníze “totalPrice (Orders)” spočítají podle obchodníků a ne chaoticky mezi sebou. Troufám si tvrdit, že každý kdo je ochotný a bude se maličko snažit, se to naučí (ostatně to v Keboola Academy učíme jak na běžícím pásu).
A teď to hlavní. AQE to přeloží na následující SQL:
S trochou nadsázky lze říct, že sestavení mého reportu je vlastně poměrně dost složité, ale mě to díky AQE vůbec netrápí. Platí-li hypotéza, že:
- pokud mi GoodData nevydělá balík peněz, tak ji nebudu používat
- balík peněz vydělám jen přesným používáním BI projektu, šitým na tělo
- BI šité na tělo je komplexní záležitost, kterou je možné obsloužit jen díky AQE
… pak je AQE základem úspěchu GoodData.
UPDATE 17.11.2013: jak to léta používám, vůbec mi nedošlo to zásadní - kontextovost MAQL metrik - úplně se mi to vrylo pod kůži a jinak si to neumím představit. Perfektně to pospal Hynek Vychodil v komentáři dole (nejde tu konkrétní komentář linkovat, tak tady je pro jistotu screenshot)
Poznámka pod čarou: výše uvedené MAQL metriky jsou jednoduché příklady. Někdy je potřeba metriku postavit tak složitě, že je až nepředstavitelné, co se s daty musí na pozadí stát. Tady je příklad metriky z jednoho projektu, kde je analytika nad nestrukturovanými texty. Metrika počítá konverzační témata v aktuálním (zvoleném) období podle moderátorů:
Lukáš Křečan před časem blognul, že lidi jsou největší konkurenční výhoda GoodData.
Lidi jsou základ, bez nich to určitě nejde a jsou to oni, kdo tvoří neopakovatelnou atmosféru ve které vznikají unikátní věci. Jeden za druhým jsou ale nahraditelní. Největší konkurenční výhoda GoodData (a zároveň zásadní duševní vlastnictví) je AQE. Pokud by ho neměla, musel by uživatel reporty klikat v sevřeném UI, které mu vezme tolik potřebnou flexibilitu. Bez AQE bude GoodData někde v partě mezi Tableau, Bime, Birst, aj. Stane se v zásadě nezajímavou a bude zhusta soupeřit s firmama, co si nad “Redshiftama" budou stavět vlastní UI.
AQE je pro GoodData neopakovatelná příležitost jak utéct konkurenci, která bude už jen ztrácet. Nikdo jiný dneska nedokáže implementovat novou funkci do produktu, kde mohou být libovolná data v libovolně rozměrech (dimenzích) a přitom si analyticky dokázat a otestovat správnost implementace.
Hranice mezi falešnou představou že “ten cool dashboard je pro mě přínosný” a "opravdovým potenciálem vytěžitelným z dat", je velmi tenká... a jmenuje se customizace. Libovolný model pro libovolná data a nad ním libovolné výpočty. Může to kdokoliv nazvat jako extrém, ale bez schopnosti spočítat přes mnoho dimenzí přirozený logaritmus z podílu hodnot dvou období, do světa finanční analytiky díru neuděláte. AQE je gamechanger na poli BI a díky němu GoodData redefinuje pravidla hry. Dneska obecná odmocnina, zítra K-means... :)
Howg!
