NoSQL a Perl?

18. 4. 2012 | Reklama | Reklama | 3761×

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.

Data, data, data, …

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í.

NoSQL a Perl

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.

Web pro web

Ú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í.

O autorovi

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.

       

Komentáře

[Radek Miček]

S podobným řešením se ve statických jazycích potkáte jen výjimečně.

Pokud tomu dobře rozumím, tak tohle by neměl být problém v jazycích, jenž podporují tzv. quotations (například C#, F#, OCaml nebo Haskell)?

[Miloslav Ponkrác]

Je to reklama, tady nejde až tak o pravdu.

[Liskni_si]

Tak, tři z těch jmenovaných jsou výjimečné docela značně, ne?

[Miloslav Ponkrác]

Jinak řečeno, JIT-like kompilace abstraktního stromu (tedy v zásadě jakéhokoli jazyka) je něco výjimečného, co opravdu nikdo na světě nedělal. JIT je něco tak vzácného, že GoodData to objevily prakticky první v životě. Zítra si na to dávají patent.

Je to reklama, od začátku do konce. Ta přehání, nadsazuje, a o to víc, když je v émerickém stylu.

Nebořme jim tu reklamu už jen v rámci zachování abíčka.

[mj41]

V případě našeho EventStoru vám přijde předpis, který např. znamená vytáhni stream1, stream2 a stream8 a při vyčítání dělej sumu stream2 přes hodnoty v stream1 a ze stream8 vytáhni první hodnotu. Moc nerozumím jak bychom si v tomto případě pomohli s JIT. Každý zákazník má úplně jiné předpisy (např. custom fieldy v datovém modelu). Kód se tedy dynamicky vytvoří, eval jej v mžiku zkompiluje a spustí. Tím, že kompilátor Perlu je optimalizovaný na rychlou kompilaci a eval se používá docela běžně. Proto si troufám říci, že implementace jinak něž s evalem by trvala mnohem déle a výsledky by byly nejisté. Prostě supr poměr cena/výkon.

Máte něco proti GoodData? Ten příspěvek se dal napsat rozumněji.

[lmb]

Tady nejde o DSL ale o běh dynamicky vygenerovaného kódu, což např. sice v haskellu jde např. přes System.Eval, ale je to dost krkolomné (omezená typová kontrola, monomorfní typy) a skutečně se moc nepoužívá. Spíš je to takový proof-of-concept.

[Radek Miček]

Já bych v těch jazycích popisoval ty transformace, tj. měl bych EDSL pro popis transformací. V jazycích, kde to nejde kompilovat, to mohu interpretovat.

[mj41]

Jasně souhlasím. U nás je celý ROLAP napsán v Perlu. Takže tímhle jsme měli tenhle "prototyp" v produkci za pár sprintů a mohli jsme používat samotný, jak píše Jirka, "mocný" interpretr perl.

[Bluebear]

Software as a Service, proboha!

[Lol Phirae]

To neřeš, to je jen byznys-ynteligentní reglama.

[retroslava]

lolky vdolky

[100% Lenin]

Dobrý Bože. Jako že jsu ateista. Odpusť mi. Ale čtení takovýchto bludů, v mé duši vytváří koheretní představu indiferentní temnoty s absolutní NoSQL transparentností orientovanou na multiprimární klíče horizontálních sloupců tohoto skfjéleho řešení. Buď milostiv z teho oslnění emerickejma koulema, hamburgrem a jemně blazeovanými fikulíny.

Ve svém nadšení jsem si říkal. To je zajímavé, to chci číst. Omlouvám se, neměl. Zmatek zůstal. Děs.

Smiluj se, ó Ty dobrotivý.

[Miloslav Ponkrác]

Milý Synu, odříkej denně jako pokání 100 × motlitbu „Perl náš, jenž jsi na nebesích“, a bude Ti odpuštěno.

[100% Lenin]

Miloslave, prubnul jsem to. Nešlo to.

Tak z teho nakonec vzešlo:

Milostivý Lous Nouts jenž jsi světlem v temnotě eskjůelské.

Veď mne, nehodného Tvé jasnozřivosti a pevné víry.

Ochraň mne, tápajícího, od ďábelských svodů Satanových O(Q)tázek Lživých - které mne v pokušení přiváději.

Ochraň mne před multidimensionalním inkrementem a svodem dvourozměrnosti tabule ďábelské.

---------- Ale jo, proč ne - hlavně s nadhledem a veselostí.

Všem zdarec a pěkný víkend

[dad]

ok, mlady programator, ktery si mysli, z takovy styl vyjadrovani je 'in', se tim trochu ztrapnil. Navic jsem 100% presvedcen, ze vetsina lidi (vcetne mne) nepochopila zcela o co jde.

Ale tim, ze se mu tady budeme posmivat se nic nevyresi. Dnesni mladi programatori nastoupi do nejake spolecnosti, kdyz je jim 30 tak jsou tam skoro nejstarsi a mysli si, ze to co vidi v te praci je ten skutecny svet. Navic jim docela dobre plati a jestlize byli takovi mladi lide zblazneni jeste navic nejakou pravicovou propagandou o tom, jak ma byt clovek uspesny, tak pak si takovi lide ani nehledaji jine vzory, zadne ani nepotkavaji.

Bohuzel, vysledkem budou nesmyslne produkty a tim budeme potrefeni vsichni, cele hospodarstvi. Mladym lidem je treba podat pomocnou ruku. To myslim nejen na vas ale i na pana Ponkrace.

[Ladicek]

Navic jsem 100% presvedcen, ze vetsina lidi (vcetne mne) nepochopila zcela o co jde.

Není to tak složité. ROLAP (kde R znamená Relational) tým GoodData seznal, že relační databáze se na spoustu věcí nehodí, a tak vymyslel MOLAP (kde M znamená Multidimensional). A protože dneska je v módě všechno, co není SQL, označit za NoSQL, i když je to třeba postaveno nad SQL, tak tomu taky řekli NoSQL.

[Miloslav Ponkrác]

Plus po vzoru ameriky dali před všechno přívlastek „jedinečný“.

Navíc ukládají nikoli data, ale pouze inkrementální rozdíly dat proti předchozímu stavu. Takže při čtení a získání dat pro určitý okamžik je třeba projet celým souborem záznamů a nikoli jej jedním okamžikem.

Inkrementální ukládání dat je věc, která byla předtím použitá rovněž miliardkrát. Je to způsob jak šetřit místo při „sparse datech“ a je to možné klidně implementovat a také mnohokrát bývá implementováno na libovolné SQL databázi. Ale to se nehodí do reklmy takže „se to zcela vymyká klasickému světu SQL“ – což už je 100% a synteticky čistá lež.

Jakékoli získání dat, zce vznosně nazýváno „transformací data“ je popsáno nějakým zápisem (jazykem), následně zparsováno a převedeno do syntaktického stromu a pak nějakým způsobem implementováno/zkompilováno v Perlu a vznikne tak jedna closure v Perlu. Opět něco, co najdete na každém rohu s výjimkou toho Perlu, protože autoři jiných projektů se většinou mají rádi a tak používají rozumější jazyky.

[Petr Ježek]

Tak nejsem jediný, komu příjde použití Perlu k tvorbě na efektivitu použití zaměřených produktů, hmm, poněkud nevhodné... Trochu se divím, za co dostali medaili tvůrci IS, taktéž z Brna, pro vysoké školy...

[Bluebear]

IMO program napsaný v Perlu má šanci běžet stejně rychle, jako v každém jiném moderním interpretovaném jazyce. Vezmeme-li v úvahu, co všechno se dnes píše v Javascriptu...

[Miloslav Ponkrác]

Jen jiné jazyky jsou udržovatelnější a méně write only.

Navíc Perl jde do kytek díky Larrymu a jeho několikaltému strašení Perlem 6, kterým efektivně zarazil na léta rozvoj Perlu a de facto mu udělal hrobeček.

Bohužel do stejné žumpy stáhnul i Python, protože mu to Larry poradil jako skvělou věc.

[cezz]

[Citation needed]

[mj41]

Druhý odstavec je nesmysl, viz. Mýty o Perlu a názory většiny komunity. Perl 6 rozhodně pomáhá Perlu 5 a díky tomu je teď Perl 5 ve stádiu renesance, viz. třeba Modern Perl. Zajímavý je taky The Perls of 2011 report.

[okbob]

Souhlasím s tím, že inkrementální ukládání na SQL databázích bylo mnohokráte implementováno - jako variace EAV - ale jinak je použití SQL pro větší objemy dat absolutně nevhodné - pokud zrovna nepoužíváte sloupcovou databázi - a ty ještě úplně běžné nejsou.

[Miloslav Ponkrác]

To není pravda, je to jen otázkou vhodného návrhu struktury a dalších věcí databáze. Pokud je někdo levej, tak je nevhodné aby vůbec dělal cokoli s databázemi a šel kopat třeba lopatou.

[Pavel Stehule]

Rad si to necham predvest :). Testoval jsem materializaci dat ulozenych v EAV tabulce - puvodne cca 8 mil radku a 22 sloupcu - a musel jsem hodne skadlit Postgres abych z nej dostal data v rozumnem case - a to skadleni spocivalo ve vlastni implementaci MERGE joinu a ve vyuziti index only scanu z 9.2. Bez uprav - jen ciste SQL se PostgreSQL nechytal - dotaz spadl po nekolika hodinach na nedostatek pameti. S upravami jsem se dostal pod deset minut - a specializovane reseni to zvladne pod minutu.

[Ivan]

Hadam, ze cely jejich produkt hojne pouziva sleepycat dbm databazi ve spojeni s tie/untie. V perlu muzete velice snadno mapovat key-value databaze na (perzistentni) hash-mapy a naopak. Je to podporovano primo na urovni syntaxe. V kombinaci s eval-em to muze vest k tomu ze i celkem komplikovana transformace muze byt zapsana "strucne".

Pokud jde o ty closures, tak se musim priznat, ze jsem to videl jen zridka. Namatkou me napada snad jen StringTemplate4.

PS: naznam python, haskel ani zadny jiny trendy jazyk.

[pavlix]

V Haskellu bohužel neumím. Python disponuje kachním typováním a součástí standardního balíku jsou databáze se slovníkovým (dictionary, hashtable) rozhraním. Nebo jdou na pár řádků vytvořit, stačí nadefinovat všechny potřebné operace.

[mj41]

S tím vychvalováním máte pravdu. Pro inženýry je toho v článku asi příliš. Na druhou stranu "jedinečná" je každá implementace a měl byste vidět naše prodejce v Americe, co jsou schopni navykládat zákazníkům . Možná jsme to chytli od nich.

EventStore je vpodstatě součastí ETL procesu a některá data předpočítává. Za EvenStorem je klasická data warehouse databáze pro ROLAP. Většina zákazníků EventStore nepoužívá a nepotřebuje. Ti ostatní nám zaplatili vývoj tohoto řešení.

To, že eval a uzávěry v Perlu jsou normální i v jiných dynamických jazycích je jasné.

Perl je dost rozumný, ostatně jako Ruby a Python. Asi by se to zvrhnlo na flamewar, tak jen připojím link na snad ještě stále aktuální seznam odkazů Perl mýty.

[Miloslav Ponkrác]

„Perl je dost rozumný, ostatně jako Ruby a Python. Asi by se to zvrhnlo na flamewar, tak jen připojím link na snad ještě stále aktuální seznam odkazů Perl mýty“

Podle mých zkušeností jakýkoli článek, který má v názvu, že boří mýty má vyšší koeficient lživost, než průměr.

Někdy mě napadlo, že vůbec důkazy odkazem na článek použiji v balení žen. Jedna žena mi napíše, že mě nechce, já jí dám odkaz na článek na webu, kde bude psáno, že po mě touží. Ona mi řekne sorry, to jsem nevěděla, promiň miláčku, teď už to vím.

Jednoduše pravda je to, co někdo napíše na web. Proč to nevyužít v seznamování?

---

Se zbytkem souhlasím.

[Petr Ježek]

Tak přesně tohle mne intuitivně (detaily jsem nestudoval) napadlo. Ostatně, pokud je cílem poskytnout v principu hodně provázaně strukturované informace pro BI, pak se bez relační struktury jaksi obejít nelze. Škoda, že o novinkách nepíší výhradně lidé znalí věci...

[100% Lenin]

Chlapi, dneska je pátek a měl jsem za sebou v zátahu 14 dní bez so/ne. Prostě jsem na to koukl a trochu se zděsil. Jasně že pomůžeme když je třeba I já jse kdysi dělal koniny a dneska také.

Prostě mne to ne že naštvalo, ale rozveselilo Omlouvám se, jestli jsem to přehnal. I autorovi a nakonec všem vám.

Díky.

[VM]

Dvě věci:

1. Vážím si toho, že reklamní články přinášejí peníze na provoz ABC
2. Zadavatelé, dejte si na nich záležet. Místní čtenáři ocení dobré nápady a rádi se dozví, v čem konkrétně je popisovaný produkt dobrý; ať je to věcné a srozumitelné.