MySQL vs HP Vertica vs AWS Redshift vs Google BigQuery

Mám jednu transformaci, ktera v MySQL trvá strašně dlouho (klidně proto, že jsem lopata :). Velmi zjednodušený popis:

Tabulka (106489 řádek, <4MB):


Sloupec "id" určuje nějakou událost, "partner" je dodavatel události (třeba nájemce záboru chodníku) a "start" říká, kdy nastala daná událost. Do tabulky doplňuju sloupec, který říká, kdy měl daný partner předchozí událost (pak se ty 2 datumy od sebe odečtou a zjistím, kolik dní uplnyulo od minulé události - partneři se v datech vyskytují opakovaně). 

Tohle zpracování dělám v MySQL tímhle scriptem s "nested selectem":


Na AWS server cr1.8xlarge (88ECU, 244GB RAM, SSD) to trvá kolem 3000 vteřin (verze s JOINem (viz níže) přes 2 hodiny). Indexy mám správně :) 

Zkusil jsem to samé pustit na HP Vertica, Google BigQuery a AWS Redshift. Na ničem kromě MySQL jsem neladil žádné parametry. Verticu a Redshift jsem do dneška nikdy neviděl, Google BigQuery používám delší dobu.

Vertica:

Nejde mi tam provést nested SELECT, tak jsem to upravil na "verzi s joinem


Data jsem tam nahrál takhle:

COPY products FROM '/tmp/products.csv' DELIMITER ',' null AS 'null' EXCEPTIONS '/tmp/products.err';

Bez jakéhokoliv ladění to tam trvá 105 vteřin. To je 3.5% času na MySQL. Cool! Vertica (community edition) mi běží na m1.large serveru, což je největší popelnice, která v tomhle "testu" figuruje. Výsledek super!

Google BigQuery:

V BQ jsem vyrobil projekt R&D a nahrál do něj data přímo z CSV:

bq load --noallow_quoted_newlines --max_bad_records 500 --skip_leading_rows=1 rad.products /tmp/products.csv id,partner,start

Spuštění téhle query zabralo 1695 vteřin (!!) a zprocesovalo 2.63MB. Trochu zklamání, něco musím dělat blbě, nechce se mi tomu věřit. Verzi s nested selectem jsem nezkoušel.

AWS Redshift:

Nikdy jsem si s tím pořádně nehrál, četl jsem pár blogů (airbnb, hapyrus, botify) a dost jsem se na tuhle část těšil. Nahodit to je o stisknutí tlačítka, zvolil jsem režim "socky" a spustil single-node instanci dw.hs1.xlarge. 

Data se tam nahrávají nejlépe z S3...

COPY products (id, partner, start) FROM 's3://padak-share/products.csv' CREDENTIALS 'aws_access_key_id=xyz;aws_secret_access_key=abc' delimiter ',' REMOVEQUOTES DATEFORMAT AS 'YYYY-MM-DD';

Zkusil jsem query s joinem:

CREATE TABLE out AS SELECT p1.start, p1.partner, p1.id, MAX(p2.start) FROM products p1 LEFT JOIN products p2 ON p1.partner = p2.partner WHERE p1.start > p2.start GROUP BY p1.start, p1.partner, p1.id;

i nested selectem:

SELECT start, partner, id, (SELECT MAX(start) FROM products WHERE start < p1.start AND p1.partner = partner) AS prev FROM products p1;

Varianta přes JOIN trvá 167 vteřin a varianta s nested selectem trvá 17,4 vteřiny (!!).

Potřeboval bych to ještě stejně spustit ve Vertice, kde mi nested select vrací "ERROR 4160:  Non-equality correlated subquery expression is not supported", ale nevymyslel jsem kudy na to a víc času jsem tomu nechtěl věnovat. Dokud to nevymyslím, je Redshift největší powa, kterou jsem na tohle našel.


UPDATE 10.8.:

Dostal jsem tip od Kolese, že Vertica umí "INTERPOLATE JOIN". Podle semantiky popsané v dokumentaci to ale myslím nebude fungovat, protože to joinuje předchozí hodnoty pouze v situaci, kdy je z prava výsledek NULL. Já to potřebuju vždycky. Tuším ale, že to tam někde bude :-)

Týdenní digest novinek v Keboola Connection #4

Po 2 měsícíčním odstupu nakopávám "changelog" Keboola Connection na staré koleje. Pojmu to trochu jinak než doposud - raději víc v bodech vypíchnu funkce a novinky, než popisovat moc souvislosti (třeba dostanu míň odpovědí "TL;DR" :-).

Pokud vás něco zaujme, pište dotazy. Pokud budou relevantní i pro ostatní, udělám nějaký broadcast.


Transformation UI

Tři módy Sandboxu

Sandbox je možné vyrobit ve třech módech:

  1. "Load input tables" pouze udělá databázi se všema input tabulkama ze všech transformací (pouštím-li transformaci "ABC", která závisí na transformaci "XYZ", nahraje to INPUT data od "XYZ" a "ABC" součastně).
  2. "Prepare transformation" mód naloaduje input tabulky ze všech (závislých) transformací a aplikuje SQL příkazy ze všech transformací kromě té, která je spuštěná. Sandbox DB tak obsahuje prostředí připravené na copy&paste SQL příkazů. 
  3. "Execute transformation" pak natáhne všechno a vykoná všechno, pouze to nevrací zpět do Storage API


Sandbox Credentials

Pokud vám při vytváření sandboxu spadne browser nebo omylem kliknete bokem pop-up okna, bylo složité zjistit aktuální jméno a heslo do sandbox databáze. Nově je na to v UI vlastní menu:

které komunikuje s Provisioning API. Každý token v Keboola Connection má právo dostat od Provisioning API jednu databázi pro Sandbox a jednu pro Transformaci. 


Transformation API

Tady jen v bodech:

  1. ~2.5x jsme zrychlili exporty SAPI > TAPI; v SAPI je nově pro export parametr format "rfc", "escaped", "raw"
  2. není povolené udělat závislost dvou transformací mezi různýma fázema
  3. sandbox je možné pouštět i na disablované transformace
  4. run mod má nový mód "single" pro rychlé puštění jedné transformace
  5. přidali jsme remote transformaci "Long Text Splitter", která umí rozlámat text a očíslovat řádky
  6. přidali jsme remote transformaci "Hierarchy Reconstruction", která umí sestavit nesourodý řetězec rodič<>potomek" do stromové struktury
  7. přidali jsme json parser
  8. PROPOSAL - za chodu plugovatelné filtery


Storage API

  1. Alias tabulky mohou filtrovat sloupečky ze zdrojové tabulky. Tímhle se velmi rychle dají anonymizovat data, kdy třeba vyhodíte email zákazníka a naaliasujete to do bucketu, který poskytnete třetí straně k analýze. 
  2. V Storage API konzoli je možné filtrovat eventy podle jména komponenty (API konzole našeptává) a/nebo podle unikátního RunID 
  3. V Storage API konzoli při kliknutí na "i" u bucketu je vidět počet řádek a objem všech tabulek, které v něm jsou. Pokud tam jsou aliasované tabulky, počítají se do objemu také. 


Keboola Academy

Kurzy v Keboola Academy úspěšně běží! Do začátku příštího týdne přidáme další pokračování "Report Master" kurzu, kde se trénují MAQL metriky na komplexnějším modelu (shifted count, BY, metrika v metrice, aj.). Vedle toho máme ještě hotový kurz "Dashboard Master", který je zaměřený na stavbu Dashboardů.


GoodData Writer 4.0

GoodData Writer je od základů přepsaný. Má rozšířené API a umožňuje následující věci:

API

  1. umí spravovat uživatele v projektu
  2. umí klonovat projekt (a pak zrcadlit automaticky všechny změny provedené na "master" projektu do všech klonů)
  3. umí nastavovat Mandatory User Filters (MUF)
  4. podporuje Single-Sign-On (SSO)
  5. má mód ve kterém běží fronta vůči GoodData API synchronně (pro správné započítání času v orchestrátoru a notifikace chyb z GD API přes orchestrátor)

UI

  1. je přepsané do Angular JS - postupně odstraňujeme chyby, které tam byly
  2. nová fronta jobů, která vypisuje časy a objemy jednotlivých loadů a konsoliduje logy všech operací pod jedno tlačítko
  3. fronta jobů umožňuje "killnout" neproběhlé joby
  4. vizuální rozkreslení vazeb LDM modelu (BETA)

Idea nového writeru je, že každý obchodník, který prodává vaše produkty, má ve vašich datech nějaké ID a email. Transformacema je možné každého nového obchodníka připravit writeru pro založení do GoodData projektu a nastavit mu MUF, které při každém novém loadu dat writer aktualizuje. Ve spojení s SSO je správa lidí a jejich přístupů k dashboardům naprosto bezešvá a automatická. Nad novám writerem pak sedí náš "SSO kontejner" - viz další část novinek - který to celé zapouzdřuje.


Co se jinam nevešlo

  1. SSO Kontejner (interní jméno "sardinka") - Umožňuje distribuovat uživatelům vybrané dashboardy a nebo dashboard taby, které je možné shlukovat a prezentovat napříč mnoha GoodData projektama. Je to zároveň kanál, jak monetizovat vaše data. 
  2. Pingdom extraktor - Extraktor na data z API služby pingdom.com
  3. DB extraktor - drobné vylepšení a oprava chyb
  4. Podpora VPN - pokud chcete používat DB extraktor, který vysává data přímo z vaší SQL, podporujeme HW VPN v rámci Amazon VPC a nebo SSL VPN OpenVPN
  5. Cloud Search Writer
  6. Widget Magic button - umožňuje umístit na dashboard tlačítko, které spustí Orchestraci - je možné aktualizovat projekt "on-demand"
  7. Tabular widget 
  8. SAPI klient v Angular JS
  9. SAPI cli pro scriptování na serveru
  10. 99,95% byl uptime API za minulý měsíc (aktuální statistiky API zde)


Konec 

-Petr

Máš BigData? Uka!

Pojem "BigData" jede na Twitteru celkem dlouho. V ČR o BigData už mluvil Patrik Zandl (zde) i Petr Koubský (zde), což je neklamné znamení, že to brzo dorazí k mojí mámě do práce. Asi poslední seriózní médium, kde se o "BigData" ještě nepsalo je Kunratický zpravodaj (fakt!). 

Nejčastější přístup, který lidi při prezentaci "BigData" tématu volí, jsou infografiky o tom, jak moc dat lidstvo produkuje. Infografiky jsou pěkný, ale objem dat není BigData. Pojďme si to říct úplně bez obalu: 

Vaše firemní databáze, registr vozidel ČR ani data o všech bankovních transakcích nejsou BigData!

Pokud jste někoho slyšeli o BigData mluvit a nabízet na to nějaké řešení, je vysoce pravděpodobný, že nikdy žádný velký data neviděl. 

Kde jsou ty BigData?

Opravdový BigData problémy řeší třeba v CERNu, kde HW z experimentu CMS, ALICE, ATLAS a LHC sbírá data z 600 milionů kolizí za vteřinu. Na zakázku navržená a ultra rychlá elektronika v takto vyprodukovaných datech vybere 0.01% dat a zbytek zahodí. Takto šíleně redukovaná data tečou pořád neskutečnou rychlostí 100GB/s do farmy serverů s 15.000 procesory, které z toho dál vyberou 1% dat, které se posílají do Tier 0 datacentra, kde dalších 73.000 procesorů dělá datové agregace a předzpracování. Data se teprve poté dál distribuují k vědecké analýze do Tier 1 a Tier 2 datacenter, kterých je celkem 151 po celém světě. 

Až vám někdo bude zasvědceně vyprávět příběhy o BigData, vzpomeňte si na CERN. 

Je totiž velmi pravděpodobné, že jediné co potřebujete vyřešit je zpracování, uložení a analýzu "normálních" dat. Normální data mohou být složitá, fragmentovaná, částečně uložená v různých volatilních systémech a mohou se v čase různě měnit, pořád ale platí, že to pro vás nejlíp na světě odbaví GoodData, která jako jediný non-mastodont (vedle MS a Oracle) vendor disponuje řešením na celý životní cyklus dat (ETL framework, data warehouse, logická business vrstva, analytický backend a prezenční vrstva (to jsou ty grafy, které jediné vidí uživatel)).

Kde se Hadoop vzal?

Zpracovat, uložit a analyzovat objemná data nebylo vždycky snadné. Vzpomínáte si na dobu kdy nejlepší disk byl 160GB SCSI 15k otáček za vteřinu, o kolmém zápisu na plotny se začínalo mluvit, 4GB RAM byl luxus a 1GBit/s síťová karta byla používaná jen v serverech FBI? Procesory neměly více jader a virtualizace si pomalu nacházela cestu z pokojíčků Geeků do datacenter? Tak to byla doba, kdy Google vydal white paper o MapReduce technologii, která umožňovala jednoduché zpracování dat na velkých počtech počítačů.

Chytrým to pomalu dochází - co by se stalo, kdyby tehdy byly lacině k dispozici stovky GB RAM, SSD disky, desítky jader procesorů s mnoha GHz výkonu, naprosto normálně síťe s kapacitou mnoha GB/s? A co sloupcové a in-memory databáze s variabilní kompresí?

(bottom line: transformace dat v Keboola Connection spouštíme v serverech s 244GB RAM, 83GHz, 240GB SSD a stojí nás to $0.34/hodinu)

Myslím, že by tehdá místo MapReduce řešili jiný koncept. Hadoop je dneska totiž něco jako Wankel engine - postavte si ho vedle elektromotoru z Tesla Model S a pochopíte, jak zoufale se dneska Hadoop musí cítit vedle moderních databází.

Přesto to ale frčí! Proč?

Protože je to dobrej business! Firmy obecně chtějí slyšet, že mají BigData a že řeší BigData problém. Dělá jim to dobře. Kdo nemá "BigData" je out! Tohle je zacyklený kolečko ze kterýho není cesta ven. Někdo si musí nejdřív rozbít pusu... Jelikož se za investice do BigData nevyhazuje, bude to muset přijít odjinud. 

Mám následující hypotézu:

  1. Firmy chtějí zpracovávat velká data, protože si myslí, že díky tomu budou schopny predikovat a na tom vydělají obrovské množství peněz. 
  2. Náklady na takovou predikci jsou ale v praxi zásadně vyšší než uskutečnitelný zisk.
  3. Protože na rozdíl od fyziky nemáme chování zákazníků popsané pár diferenciálníma rovnicema, musí většina predikcí stát na nekonečném numerickém iterování bordelu v datech.
  4. Tohle iterování je pomalé, špatně se mu mění vstupní parametry a hraniční podmínky - díky tomu to má zatím spíš sporné výsledky.
  5. Nakonec stejně zvítězí chytrost a rychlost nad přesností. Pokud ModGen na šíleném železe udělá za 3 dny o 6% lepší výsledek než Mikiho jednoduchý binární strom na notebooku za 17 vteřin, je singularita ještě daleko :)

Resume:

  • nemáte BigData!
  • nepotkali jste nikoho, kdo by BigData problémy opravdu řešil
  • je sexy o BigData vyprávět - proto klidně říkejte, že vás to trápí
  • potřebujete se ale hlavně zbavit Excelu a ne stavět Hadoop cluster
  • používejte hlavu!
  • díky zpracování dat máte VYDĚLÁVAT peníze, né si honit triko na konferencích!

Tohle je úplně čerstvá věc. Velká gratulace! GoodData získala ocenění, které de-facto říká, že GoodData je nejlepší řešení na to, jak vydělat peníze na trhu s daty. Tuněním Hadoopu a psaním MapReduce scriptů totiž naše existující zákazníky nepředhodníte! Dobrá zpráva je, že máme ještě v Cloudu pár volných míst. Autobus odjíždí každé ráno v 9:00 z Florence, tak koukejte nastoupit :)


Při psaní jsem poslouchal Brukev od Martina Halamíčka.

Čím je GoodData výjimečná?

Dnešní doba je přesycená daty. Vyprávět o datech začíná být tak sexy, že si na tom každý druhý staví kariéru. Dokonce i v ČR pár semi-expertů převlíklo kabáty a začalo mluvit o BigData (v horším případě na tohle téma dokonce pořádají konference). Já si tohle téma schovám na pozdější  blogpost, ve kterém to "hadoop nadšení" trochu posadím nohama na zem.

Data...

Lidi chtějí znát víc informací o prostředí ve kterém se pohybují. Pomáhá jim to lépe se rozhodovat, což většinou vede ke konkurenční výhodě. Obecně platí, že k dobrému rozhodování potřebujeme kombinaci tří věci: správné vstupní parametry (informace/data), selský rozum / zkušenost a špetku štěstí. Blbec bude dál blbej, "štěstí" se v ČR dá občas koupit, ale hrozí že vás zavřou za uplácení. A tak nejvíce ovlivnitelná složka úspěchu zůstávají informace. Na "hřišti" kde se pohybuju si pod správnou informací představte odpovědi na ty nejzvídavější otázky, co vás napadnou.

Předpokládám, že každý z vás ví, kolik má na svém osobním účtě v bance k dispozici peněz. Většina taky bude vědět, kolik asi peněz měsíčně utratí. Méně z vás bude přesně vědět, za co ty peníze utrácí. Ještě menší skupina lidí bude znát strukturu všech kafíček, zmrzlin, vín, obědů, atd. (říkáme tomu "long tail"). Skoro bych se vsadil, že nikdo neví, jaký je jeho osobní meziroční trend ve skladbě nákladů takovéhoto longtailu. Asi namítnete, že vás to nezajímá. Pokud jste ale firma, která chce uspět, neobejdete se bez podobných informací. Co se osobního života týče, je podle mě největší magor Stephen Wolfram, který si od roku 1990 měří téměř všechno. Jen o žmolcích z pupku zatím nepíše téměř nic (na rozdíl od Grahama Barkera :)

Protože po zprávách v TV večer nedávají "executive summary" z vašeho účetnictví, crm, google analytics a social sítí, jste nakonec nuceni si budovat různé varianty reportů a dashboardů sami.

Zkusím tu sesumírovat nástroje o kterých vím, že jsou k dispozici, ale nakonec vám řeknu, že je to všechno jen taková plynová pistolka a kdo chce pořádnej data gun, musí sáhnout po GoodData. Abych byl fér, budu se snažit i trochu argumentovat :)

Excel

Excel je dnes na každém rohu. Je dobrý pomocník, ale dost lidí má podivnou tendenci dělat ze sebe Excel Inženýry, což je nejvíc nebezpečná odbornost, na jakou můžete narazit. Takový Excel Inženýr často končí u kontingenční tabulky a vzorečku SUMIF(). Přitom má na sebe navázané "zpracování firemních dat" a snad nevědomky se stává brzdou pokroku. Největší rizika reportingu v Excelu podle mě jsou následující:

  1. v excelech se drží primární data, ze kterých se reporty dělají, tyto data do excelů někdo někdy naimportoval - špatně/draze se to aktualizuje
  2. excely mají tendenci putovat "korporátníma outlookama", díky čemuž vznikají různé verze; často se hodí YDT % o kousek změnit, případně se snadno stane, že vedlejší oddělení má stejný excel, ale s jinými čísly - sráží to důvěru v reporty a umožňuje to snadno zkreslit realitu
  3. složitější věci je nutné chtít po reportovacím oddělení (jen oni umějí aktualizovat data - viz bod 1.), kde odborníci na excel vyrábějí odpovědi na business otázky, kterým né vždy rozumí - často se stává, že ad-hoc odpovědi na vaše ad-hoc hypotézy vznikají dlouhé dny (nastává vyhoření zadavatele)
  4. do excelů se kombinacema ručních operací a maker co vyrobil "ten co tu už nedělá" vnáší chyby, díky kterým kolabuje kosmír!!

Je asi jasné, že excelový reporting by měl končit na úrovni živnostníka. Efektivně s ním nejde dělat nic seriozního. Můžete si být jistý, že excely co jsou na "zetku" (síťový disk přece!) obsahují chyby, nejsou aktuální a byly vyrobeny lidma, kterým to někdo zadal, takže věděli prd o podstatě dat, které do toho VLOOKUPu zapojili. Excel Inženýr většinou nemá v genech dělat "data discovery" a i kdyby na něco zajímavého narazil, asi si toho nevšimne. Co je v danou chvíli správná informace poznáte nejlépe vy sami (a excel opravdu není to, co byste měli v roce 2013 ovládat na úrovni VBS maker a dirty hacků)! 

Vizualizace

Dnešní trh je přesycený nástroji, které mají za cíl pomoct vizualizovat nějakou business informaci. Pod tím si představte třeba počet objednávek za dnešní den, čistou marži za poslední hodinu, průměrný zisk na jednoho uživatele, aj. V drtivé většině případů to funguje tak, že si u sebe tuhle "informaci" spočítáte a přes nějaké rozhraní to automaticky posíláte dané službě, která se stará o prezentování dané metriky. Příkladem takových služeb může být například Mixpanel, KissMetrics, StatHat, GeckoBoard nebo třeba KlipFolio. Výhoda oproti Excelu je hlavně v tom, že se reporty a dashboardy dají snadno automatizovat a následně sdílet. Sdílení informací je dost podceňované! Příkladem takto vizualizované informace může být počet datových transformací, které jsou v minutové granularitě spouštěny v našem staging layeru:

Z takovýchto reportů si poskládáte Dashboardy a chvíli budete mít dobrý pocit. Problém nastane v momentě, kdy zjistíte, že každé rozšíření takového dashboardu vyžaduje tím složitější zásah od vašich programátorů, čím složitější jsou vaše otázky. Pokud děláte v B2C a máte transakční data, můžete si být jistý, že klinickou smrtí této formy reportingu bude například otázka na počet zákazníků v čase, co utratili alespoň o 20% více než je průměrná objednávka za minulý kvartál a zároveň mají společné to, že prvně tento měsíc koupili produkt "ABC". Pokud by to náhodou vaši programátoři zvládli implementovat, prostřelí si hlavu, pokud jim k tomu doplníte, že chcete jen denní počty TOP 10 zákazníků z každého velkoměsta, kteří splňují předchozí pravidlo. V případě, že máte jen trochu "víc" transakcí, bude to znamenat překopat existující DB na vaší straně a časem to 100% zkolabuje. I pokud to budete držet vší silou při životě, můžete si být jistý, že díky tomu zadek konkurenci nenatrhnete (nulová flexibilita - nebudete schopný ani zlehka točit "analytickým kormidlem", jak bude kolem vás pivotovat trh).

Je možné, že podobné otázky na vaše podnikání nemáte a netrápí vás to. Krutá pravda ale je, že vaše konkurence se na to ptá už teď a vy na to budete muset nějak zareagovat...

Pseudo BI

Excel ani vizualizační nástroje nemají většinou žádný sofistikovaný backend. Podobně jsou na tom služby typu Domo nebo Jolicharts. Na první pohled vypadají super sexy, uvnitř je to ale převlečený soubor vizualizačních nástrojů, občas obalených trochou statistických funkcí, které většinout nepoužijete. Společným jmenovatelem je absence nějakého jazyka, pomocí kterého byste mohli vykročit z přednastavených dashboardů a začít podobné služby implementovat tak, aby vám byly opravdu k užitku. 

Jedinou jejich výhodou je, že se rychle implementují. Bohužel to tím končí a po krátkém opojení přijde vystřízlivění. Pokud jste jen trochu náročnější, nemáte tady šanci na spokojený život. 

Low Level přístup

Existují služby, které vám umožní nahrát data a klást dotazy. Nejvíc "hot" je dneska podle mě Google BigQuery. Pro nás v Keboole je to ohromný pomocník při transformacích dat, denormalizaci a JOINech obrovských tabulek. Pro vás bude sloužit skvěle, pokud vám bude připadat jako dobrý nápad psát tohle:

abyste získali tohle:

Asi je jasné, že pokud se neživíte jako SQL konzultant a nemáte ambice vyrábět vlastní analytickou službu, bude lepší, když tenhle přístup necháte nerdům a budete ladit vlastní business :) 

Cloud BI

Pokud vygooglíte "cloud BI", vrátí vám Google jména jako BirstGoodData, IndiceeJaspersoftMicrostrategyPentaho, aj. (pokud máte mezi výsledkama Zoho Reports, zacyklil se asi vesmír, protože tohle by mělo zůstat v Asii :).

Z mnoha směrů je zřejmé, že "Cloud" hýbe dnešním světem. V ČR je nejčastější obavou při střetu s tímto pojmem strach o data a pocit, že "moje IT" zvládne něco lépe než daný vendor. Pokud trpíte stejnou obavou, vězte, že v případě jakýchkoliv problémů, které v Cloudu mohou nastat, makají nejlepší lidi co na týhle planetě jsou, aby všechno zase šlapalo jako hodinky. Hezky to shrnul Dave Girouard v tomto článku (shodou okolností zároveň board member GoodData). 

Kromě Microstrategy, která Cloud nejspíš objevila dneska dopoledne, jsou výše uvedené značky v Cloudu poměrně zavedené. Pod pokličkou skrývají ale různá překvapení. Pentaho vyžaduje velmi technické znalosti k tomu, aby jej bylo možné ždímat na plný kotel, Jaspersoft je Excel na webu, který se slušně řečeno moc nepovedl, Indicee by si přála hrát první ligu, ale vím minimálně o jednom velkém zákazníkovi z Vancouveru, který po roce snahy naimplmentovat jejich řešení přešel na GoodData, Birst v době kdy jsem jej zkoušel byl celý ve flashi a ani přes velkou snahu jsem to pořádně nepochopil :(

Jak jsem na začátku řekl, všechno kromě GoodData stojí za prd. Důvodů je hned několik:

  1. GoodData má silný jazyk pro definice metrik. Díky tomuto jazyku je možné, aby kdokoliv tvořil reporty, byť budou sebesložitější. To že se reporty pouze "neklikají" je víc než podstatné - dává vám to flexibilitu, kterou budete potřebovat v boji o první místa s vaší konkurencí. Pokud GoodData uspokojí Tomáše Čupra (ex-Slevomat, DámeJídlo.cz), můžete si být jistý, že bude vyhovovat i vám. Na první pohled možná složité konstrukty, se rychle naučíte v Keboola Academy.
  2. GoodData, na rozdíl od své konkurence, disponuje fundamentálně navrženým API rozhraním, díky kterému firmy jako Keboola dokážou celou analytickou platformu ohnout tak, aby hrála první housle ve vašem prostředí. Bezešvá integrace do jiných informačních systémů, white-labeling, single-sign-on nebo framework pro datové extrakce a transformace znamenají, že při implementaci neexistují kompromisy.
  3. GoodData nejsou jen reporty ve webovém prohlížeči, ale celý soubor abstraktně oddělených funkčních vrstev (fyzickým modelem reprezentujícím data počínaje až logickým modelem reprezentujícím business vztahy konče), díky kterým implementace neobsahuje věci jako "průzkum proveditelnosti", "technická specifikace", apod. GoodData se implementuje ve srovnání s konkurencí ohromnou rychlostí (žádné "projekty na dlouhé měsíce").
  4. GoodData má v Brně fantomasovu laboratoř, kde probíhá R&D jehož výstupem jsou inovace, které nevím, jestli můžu dneska veřejně říct. Nicméně s klidným svědomím můžu konstatovat, že se z toho ostatní brzo poserou. Určitě to sem zavčas doplním!

Suma sumárum, kvalitu GoodDaty dokazuje mj. i spousta napojení, včetně třeba Zendesk.com (největší služba pro podporu zákazníků na světě). Schopnost podobné ohebnosti je podle mě úplně nejpodstatnější esencí pro budoucí úspěch. Kdokoliv z vás si může pronajmout nejvýkonější servery, navrhnout super-cool UI, naprogramovat konkrétní statistické funkce (nebo si je třeba půjčit od Google BigQuery), ale v dohledné době nikdo nepřijde s uceleným konceptem, který dává smysl a je použitelný pro malé dashboardíky (máme klienta co v GoodData kouká na pár dat z Facebook Insights) i gigantické projekty s šestimístným $ rozpočtem jen na úvodní fáze implementace. 

GoodData Rocks! 

Howg!

P.S. Zvědavci si mohou pustit veřejné video, kterým otvíráme v Keboola Academy úvodní Business User kurz:


Business User One Star Intro from Keboola Academy on Vimeo.


UPDATE: kupón na 70% slevu pro Keboola Academy (kurzy Business User 1 a Business User 2), platný do konce května 2013 pro prvních 10 lidí: 72b0eb8ede337dcefce2 

GoodData Bootstrap

V Keboole (kromě Keboola Academy a vývoje nástroje na rapid (GoodData) project development) řešíme našim klientům jednu základní otázku: "Jak vydělat víc peněz?". Dnešní svět se točí kolem dat a tak i my, líný kluci, na to jdeme přes data. 

Největší dobrodružství pak začíná na úplném začátku, kdy je potřeba pochopit souvislosti a dát si dohromady obrázek o tom, co klient dělá, protože bez toho nepochopíme jeho data.  

Tady je Vojta v momentě kdy jeho mozek olizuje business vazby nového projektu. Často je to kruciální moment - pokud "to" nesepne, čeká ho následujícíc týdny dost peklo :)

Doporučené čtení: Co vlastně děláme v Keboole?


Keboola Academy

Dneska jsme spustili Keboola Academy.

Pracujeme na tom prakticky od listopadu 2012, kdy jsem na předchůdci dnešní Akademie začal zaučovat Tomáše, který k nám akorát nastoupil do Kebooly. Tehdy jsem pro něj vyráběl hodně hrubý projekt v GoodData.com, ve kterém se měl naučit všechny triky. Navíc bylo skvělé, že to pak Milan obratem použil pro kluky co nastupovali do kanclu v Kanadě.

Celá Keboola Academy dává obrovský smysl firmám, které používají GoodData.com a potřebují, aby jejich zaměstnanci ovládali všechny finesy které tam jsou. Pokud to lidi ve firmách neovládají, zásadně to snižuje potenciál celého řešení. No a naše ambice je tohle řešit. Je to vedle Keboola Connection a práce našich analytiků takový třetí pilíř v našem podnikání. 

Jsem zvědavej, jak se to chytí u klientů. Adam, Jakub, Miro a Tomáš na tom odvedli obrovský kus práce a posunuli to celé přesně tam, kde by to podle mě mělo být. Jediný možný vstup je s použitím Linkedin účtu, platí se přes Stripe, školní projekty dostane člověk téměř na počkání a loguje jej do toho skvělý Single Sign On mechanismus GoodData - celé je to díky tomu co možná nejvíc bezešvé. 

Po úspěšném dokončení konkrétního kurzu pak Keboola Academy přes LinkedIn API doručí patřičný "badge" přímo do vašeho profilu.

Pokud mi napíšete, rád vám dám kupón s 50% slevou, výměnou za feedback. 

Update: Zapoměl jsem poděkovat Martinovi za design a hromadě dalších lidí, kteří nám dělali například beta testing.

Týdenní digest novinek v Keboola Connection #3

Transformation UI

Indexy

Je možné v Input Mappingu říct, jak mají být data v Transformační DB indexovaná. 

Účel: zjednodušit transformaci samotnou, aby nemusela obsahovat SQL ALTERy. Transformation API podporuje indexy přes více sloupců, používejte je! :)


Datové typy

V Input mappingu je možné říct, jak má vypadat tabulka v transformační databázi. Je nutné znát přesné datové typy daného DB backendu! Transformační API pro nás strukturu databáze připraví.

Účel: Není nutné do samotných tranformací přenášet SQL příkazy, které ALTERují cílové tabulky. Je to celé přehlednější a otevírá to možnosti, kdy jedny data máme v transformační DB v různé struktuře (ID může jednou být VARCHAR a jindy UNSIGNED INTEGER). Transformace samotná pak obsahuje jen SQL QUERY, které “přidávají hodnotu”, nikoliv technicky upravují prostředí, aby se dalo dané hodnoty dosáhnout.


Input Optional

Při načítání vstupní tabulky je možné říct, že není nutné, aby existovala.

Účel: Pokud potřebujeme někam odložit data spočítaná v jednom běhu transformace a později je načíst (například při počítání snapshotů a generovnání FULL outputu), je potřeba zajistit, že při první iteraci transformace vstupní tabulka neexistuje (ještě ji transformace nevytvořila). To jak se to bude chovat je nutné pořešit v samotném SQL.


Sandbox

Postupně budeme rušit “sandbox” tak jak jej znáte. Nově bude sandbox fungovat pouze nad konkrétní transformací nebo skupinou transformací. V úplném začátku tvorby projektu si sandbox vyrobíte tak, že jednoduše založíte novou transformaci, dáte jít Input Mapping a pak z ní vyrobíte Sandbox. Sandbox transformace je de-facto normální spuštění ve speciálním módu (Dry-Run / Prepare). Jedna verze pouze připraví prostředí pro aplikaci vašeho SQL (nebo testování SQL), druhá verze navíc aplikuje SQL query, ale nezapíše výstupy zpět do Storage API. V průběhu vyrobení transformačního sandboxu vám Transformační API vyrobí SQL DB a dá k ní vaše vlastní jméno a heslo. V takto vyrobené DB vám data vydrží do dalšího spuštění sandoxu nebo transformace pod vaší vlastním tokenem. Vesnicky řečeno, co token, to právo na jednu databázi (budeme asi rozšiřovat na 2).

Účel: Nemuset lidem vytvářet sandbox credentials a sandbox databáze. O všechno se teď stará naše Provisioning API, které přiděluje transformační databáze ad-hoc. Aktuálně jsou sandboxy a transformace deployovány na cr1.8xlarge serveru.


Filtrování řádků na neexistující hodnoty

Filtrování řádků nově umožňuje negace. Je možné například z tabulky s 40M řádků, plné neregistrovaných úživatelů, vytáhnout pouze ty, co nemají prázdný email.

Účel: Zrychlit a zjednodušit přípravu transformačního prostředí.


Transformation API

Performance Monitoring

Transformační API nově loguje veškeré časy a vyrábí komplexní report v GoodData, který používáme na optimalizaci a validaci celého vákonu KBC. V blízké době budou tyto data dostupná v bucketu sys.logs v každém projektu. 


Orchestrator 2.0

Nový orchestrátor je k dispozici od minulého týdne v produkční verzi ve všech projektech.

Možnost zrušit čekající job

V orchestrátoru jsou vidět naplánované joby, čekající na spuštění. Tyto “waiting” stavy jde zrušit, dřiv než proběhnou.

Účel: Cpt. Obvious :)


Více notifikačních emailů

Chybové notifikace je možné posílat na více než jeden email. Do vstupního pole se zadávají další emaily oddělené čárkou.

Účel: Cpt. Obvious :)


Keboola Academy

Na adrese https://academy.keboola.com/ spouštíme tento týden (konečně!:) Online školení zaměřené na GoodData uživatele. Akademie je zaměřená na role Business User, Report Master a Solution Architect

Všechny kurzy jsou “hands-on”, doplněné perfektníma videotutoriálama. V obsahu kurzů jsou promítnuté stovky hodin našich zkušeností. Makáme na tom od konce prosince 2012, doufám, že budeme moct vaše LinkedIn profily brzo ocenit badgema! 

Účel: Zvýšit hodnotu GoodData projektu. Čím víc lidí u klienta GoodData ovládá, tím lépe je využita investice do celého BI projektu. 


Konec

-Petr


Týdenní digest novinek v Keboola Connection #2

SAPI

On-The-Fly Admin Tokeny

Do Storage API byste měli chodit odkazem v https://connection.keboola.com/admin:

Nově každý pozvaný KBC uživatel dostane automaticky vlastní ADMIN token do SAPI:

Tyhle osobní ADMIN tokeny slouží k tomu, abyste v Eventech věděli, kdo co měnil. Nově tak není veškerá aktivita spojená do “Master Token”. Původní Master Token v nových KBC projektech dál nebude existovat. Pokud máte vlastní scripty, které s KBC komunikují, vyrobte jim vlastní token, nepoužívejte osobní tokeny jinak než pro váš přístup. V momentě, kdy někoho z KBC projektu odpojíte, smaže se mu jeho Admin Token.

Výběr řádků - operátory pro filtrování řádků

V minulém týdnu jsme do TAPI UI vypropagovali filtrování řádků. Dneska je drobně rozšířena funkcionalita na backendu tak, že není nutné filtrovat “sloupec = zaplaceno”, ale je možné použít i operátor “není rovno”. V UI to ještě není.

Účel: snížit objem dat již při prvotním exportu ze SAPI -> mám bambilión řádků, které obsahují email zákazníků, přičemž neregistrovaný zákazník má pole prázdné. Chci počítat datum první objednávky pro který nepotřebuju nevyplněný email. Doteď jsme museli přenést vše do Transformační DB a tam provést indexování a DELETE FROM moje_tabulka WHERE email <>’’; Dnes se tento filter přesune do SAPI. Operátor je dokumentovaný zde.

KBC

Orchestrátor 2.0

Minulý týden avizovaný orchestrátor je vidět v KBC. Postupně vám migrujeme starý Orchestrátor za nový. Stay tuned!


Konec

-Petr

Týdenní digest novinek v Keboola Connection #1

Transformation UI

Chytré našeptávání ze Storage API

Při výběru vstupních tabulek do transformace vám UI našeptává jméno tabulky napříč celým “data warehousem”. Ve jménech tabulek zvýrazňuje podtrháváním. 

Účel: Má to pomoct zadávat vstupy bez chyb, zvlášť v momentě, kdy máme podobná jména tabulek.

Výběr sloupců (columns filtering)

V nastavování vstupních dat pro transformace (Input Mapping) je možné vybrat jen některé sloupce. Jména sloupců jsou našeptávána. Není pro ně žádný množstevní limit, nezáleží na pořadí. 

Účel: nepřenášet do Transformací zbytečné informace => zvýšení rychlosti a přehlednosti. Pokud mám tabulku o 10 milionech řádcích, ve které jsou tři zbytečné sloupce, každý o délce 30 znaků (třeba HASH, ID, etc.), sníží jejich vynechání objem zpracovaných dat o 858MB. 

Trik: pokud potřebuju roztrhat tabulku podle sloupců, použiju jí víckrát v Input mappingu:

Výběr řádků (rows filtering)

V nastavení Input Mappingu je možné zvolit jeden sloupec a definovat hodnotu, která se na vstupu do transformace použije jako filter. Podmínka filteru musí být přesná a může mít více hodnot. 

Účel: nepřenášet irelevantní řádky, případě předpřipravit transformační tabulky rovnou. 

Tip: kombinace s filtrováním sloupců mi umožňuje optimalizovat běh transformace a udělat ji přehlednější. Místo vyrábění nových tabulek v transformační databázi si v definici Input mappingu předpřipravím co potřebuju. Pokud mám tabulku, ze které potřebuju mít v transformační databázi tabulku “user_error” (projectID, tokenID kde result=error) a “sandbox_creation” (runID, start kde request=create-sandbox) 

Editace existujících Input Mappingů

Doteď Transformation UI neumělo editovat již existující Input Mapping. Tohle asi nepotřebuje dál popisovat :)

Editace SQL dotazu

Poměrně zásadní, ale málo viditelná vlastnost Transformation UI je, že když v transformaci kliknete na konkrétní SQL query, tak se editor otevře s kurzorem zapozicovaným na daný SQL dotaz. Zároveň jsou všechny SQL dotazy natvrdo odsazené mezerou.

Transformation API - změny co nejsou v UI

Indexy a Datové typy

TAPI umožňuje v definici Input Mappingu říct, jaký datový typy má který sloupeček v tabulce mít. TAPI pak připravuje transformační databázi rovnou s datatypem a indexem. Odpadají tak ALTERY přímo v uživatelských SQL queries.

Účel: Pokud je jedna vstupní tabulka použitá ve více transformacích, umí TAPI spojit rozdílné indexy dohromady. Pokud bych měl tabulku “users” a nad ní 2 transformace, jedna co počítá uživatele ženy (index nad sloupcem “sex”) a druhá co počítá uživatele co mají tento měsíc narozeniny (index nad sloupcem birthday), bude mít tabulka users v transformační databázi při zavolání každé transformace separátně vždy jen jeden index. V případě, že se zavolají obě transformace dohromady, bude mít tabulka users indexy oba.

Run Mode

TAPI má nově tři módy běhu: Full (default), Dry-Run, Prepare.

  • Full funguje jako doteď - tedy přenese v rámci každé transformační fáze data do Transformační databáze, aplikuje na ně SQL přípazy a výstupy podle definice output mappingu vrátí do Storage API.
  • Dry-Run provede to samé co Full, jen nevrátí poslední fázi a vše ponechá ve stavu, v jakém to v tranformační databázi zůstalo.
  • Prepare mód připraví v transformační databázi všechny tabulky a s vyjímkou poslední fáze je i všechyny vykoná. Poslední fáze se ale neprovede a transformace zkončí v momentě, kdy je možné ručně aplikovat všechny SQL příkazy.

Účel: v případě jakékoliv uživatelské chyby v normálním běhu transformace je Dry-Run nejsnazší režim pro debug. Puštěním té samé transformace v Dry-Run módu se provede vše až k chybě a stav se ponechá pro diagnostiku (=ruční opravu přímo v chybovém prostředí běhu transformace). Prepare mód pak umožní do poslední fáze běhu aplikovat SQL příkazy ručně (“mít čistý stůl pro ladění”)

Orchestrator (beta)

Informace o časové zóně

Jsme těsně před spuštěním nového orchestrátoru. Nově má v UI možnost editovat momenty běhu a varuje před konfliktem časových zón.

Editace scheduleru

Editace času má “cron style” a nevyžaduje hlubší znalost formátu vstupu. Nastavení spuštění každou hodinu v 0, 7, 12 a 31 minut pak vypadá takto:

Příklad bizardní konfigurace, která se inicializuje 5., 12. a 17. den v měsíci, v 5:11, 5:22, 5:33, 5:44 5:55 a 18:11, 18:22, 18:33, 18:44 a 18:55 pak vypadá takto:

V rámci jednoho projektu je možné mít neomezené množstvý orchestrátorů, které se spouštějí nezávisle. Každý orchestrátor pak může používat úplně jiný token. Token musí patřit projektu, ve kterém orchestrátor běží. Nejde tedy mít orchestrátor, který po cizím tokenem z jiného projektu ošmatlává extraktor zpřátelené firmy :)

Hello Syrup

Spustili jsme obecný kontejner “Syrup”, který je napsaný v PHP a je připravený pro třetí stranu, která chce vyvíjet externí komponenty rozšiřující funkcionalitu Keboola Connection. Použitím Syrupu nebudete muset ladit API interface, logování, aj. Syrup se těší na to, až si ho forknete z našeho GitHubu

Obecný databázový extraktor

V Syrupu je napsaný databázový extraktor, který umí proti cizí SQL databázi aplikovat SQL příkazy, jejichž výstupy správně naformátuje a vrací do Storage API. DB extraktor neřeší zabezpečení spojení mezi ním a vzdálenou databází. Zatím nemá UI. Dokumentaci má zde

Konec

(Další low-level změny jsou k nalezení v naší oficiální dokumentaci)

-Petr