Co všechno v Keboole platíme za cloudové služby?

Po 2 letech jsem se pustil do updatu starého postu Cloud - vyhazujeme peníze oknem?...

TL;DR je v starém článku, tady už jen soupis :-)

Komentář: je vidět, že jsme trochu posekali náklady a vypli nepoužívaný věci. Pořád je to ale dost macatý a nevím, jak bysme bez toho fungovali. Díky tomu je dneska úplně jedno, kde sedíme. Co se programátorů týče, tak dva jsou v Kanadě, jeden v Prostějově, jeden v Brně, čtyři v Praze a jeden v lese někde za Prahou - není možný mít v kanclu server, víc než půlka týmu by k němu nemohla. Na zimu se ještě jeden "kanaďan" přesune do snowparku a druhej odletěl někam k Montrealu - totální fragmentace :) K tomu je navíc další půlka český firmy někde mezi domovem, kanclem a klientama. Bez služeb v cloudu by tohle nefungovalo.

Nové

CloudGates ($85) - FTP/SFTP vrstva nad naším Amazon S3, když nám někdo chce poslat data na FTP, uděláme mu tady účet a přijímaný data si vybíráme z Amazon S3; pro klienty co maj data v Adobe Marketing Cloud doslova nepostradatelný
Cloudability ($189) - Hlídá útratu v AWS, denně dostaneme přehled nad nákladama za minulý den - díky tomu nemůžeme ustřelit do vesmírnejch částek
Google Cloud (~$20) - hlavně BigQuery, v našem případě občasný hraní
Slack ($80) - 10 lidí v placeným Slacku (>5 integrací s jinou službou) - nahradilo nám to hipchat.com; po pár týdnech nemáme de-facto žádnou emailovou komunikaci mezi programátorama
Mailgun ($0) - API pro import dat z emailů, life-saver (díky za tip, Rasťa Turek)
DigitalOcean (~$10) - občas si tam nahodíme server pro nějakej test, případně jednorázovej úkol, oproti AWS je to celé mnohem míň uklikané
Posthaven ($10) - tady máme firemní blog.keboola.com a status.keboola.com
Wunderkinder ($5) - takový rychlý task-listy, myslím, že to používám placené jen já
Eventbrite - když něco pořádáme (třeba hackathon), tohle nám řeší věci kolem eventu
GoDaddy/Ignum/Symantec - domeny, SSL

Zdražené

papertrail ($150) - služba, kam posíláme logy a můžeme je tady analyzovat, nad logama se mohou pouštět různé dotazy, které je možné podle výsledku někam notifikovat, zkoušel jsem ještě Splunk Storm a Loggly, ale Papertrail nám sedl nejvíc; máme ho propojený s PagerDuty
Paymo ($135) - tady trackujeme práci na placených projektech, data odsud taháme přes API
Apiary for Teams ($99) - v něm máme dokumentaci všech API; šel jsem to spočítat a je jich tam 21
Google Apps ($127) - emaily na doméně keboola.com (+dokumenty, hangouty, kalendáře, atd...)
AWS (-) - sem nám teče nejvíc $$, v AWS máme servery, databáze, fronty, Redshift, DNS, CloudSearch, atd...
GoodData (-) - srdce našeho podnikání :-)
OVH (-) - nám dodává servery pro některé datové transformace, máme to na východě Kanady

Zlevněné

NewRelic ($199) - serverový profiling aplikací, naprosto super věc, díky tomu vidíme, kde nám co vázne - přešli jsme tam na nějakej spešl tarif pro 8 serverů a asi 10 lidí, nemáme to nasazené všude
Foocall ($15) - používáme na volání do zahraničí. v telefonu si tím vygenerujeme lokální telefonní číslo (pevnou linku), na kterou pak zavoláme a foocall hovor přesměruje kam potřebujeme. skvěle použitelné i na EDGE internetu, cena za minutu téměř zanedbatelná
Zendesk ($493) - supportní systém, tady řídíme věci na support@keboola.com (dneska 17 agentů, downgradováno na nejnižší tarif)

Zrušené

Okta - kde to jde, používáme Google+ autorizaci
Evernote - zrušil sponzorované programy, každý si to musí platit sám, nebo je Evernote for Business, což je nesmyslně drahé (a na spolupráci nad dokumenty to válcuje Google Drive)
LiquidPlanner - to se vůbec neujalo :)

Stejné jako loni

PagerDuty ($49) - používáme pro distribuci notifikací (zalogované problémy detekuje Papertrail, který založí v PagerDuty "problém" a postará se, že se o něm dozvíme)
GitHub ($50)- repository zdrojových kódů, dáváme sem hlavně věci, co jsou veřejné
BitBucket ($10) - repository zdrojových kódů privátních věcí
sendgrid ($10) - tohle je náš centrální mail relay ze serverů, nikdo nás podle IP nepovažuje za spammery a email traffic se dobře monitoruje
Pingdom ($10) - nám nezávisle hlídá dostupnost serverů, kterou veřejně publikujeme
Trello ($20) - skvělá věc na správu projektů (hodně orientovaná na konkrétní úkoly), nediktuje vám žádnou metodiku, taková cloudová tabule s kartičkama
Vimeo ($12)- videoserver pro Keboola Academy video tutoriály
GoToMeeting ($49) - hodně jsme to používali před Google Hangoutem, postupně ustupuje, ale pořád imho mnohem lépe fungující věc na online schůzky (nahrávání, fullscreen mod, app v telefonu, i pro lidi co nemají Google účet, ovládání cizí klávesnice, atd...)
OpenBrand ($0) - tady máme naše brand assety, ale spíš je to mrtvý, nikdo to moc nepoužívá (CI máme v Dropboxu :)
Dropbox ($0)
Mailchimp ($0) - všichni znáte
+ pár "devel" věcí, jako je Travis ($0), Packagist ($0), aj.

Nové v kategorii "koketování"

Microsoft Azure - koketujeme s AzureML, máme nějaký trial, ale zatím žádné vážné použití
Chartio - služba co kreslí grafy z dat získaných z našeho backendu
Birst - CloudBI - chceme posloužit i těm, co už si tohle koupili - tak to zkoumáme
Anaplan - CloudBI - chceme posloužit i těm, co už si tohle koupili - tak to zkoumáme
RJMetrics - CloudBI - chceme posloužit i těm, co už si tohle koupili - tak to zkoumáme
Snowflake - úplně čerstvě "pronajatý" data warehouse včetně analytické nadstavby, máme to zatím v trialu a cenu myslím nechtějí zveřejňovat, aby jim to dalo šanci osejlovat další zákazníky, ale je to dost příznivý!
Flexibee - CZ účetnictví v cloudu
QuickBooks - CA účetnictví v cloudu

Co používáte vy? Podělte se v komentářích :)

GoodData SF Hackathon, duben 2014

10.-11. dubna 2014 jsme jeli do San Francisco na hackathon, pořádaný v kanclech GoodData, zaměřený na používání jejich nových SDKček. Za 7 měsíců jsem si nenašel čas to sepsat, tak snad bez větších zkratek teď. Po dobu hackathonu jsme měli v Praze i San Francisco dropcam.com kamery - v textu jsou bez kontextu 2 timelapse videa.

Akce to byla super! Účastnilo se jí asi milion lidí z GoodData, jedna jejich externí firma (saama.com), co jim pomáhá s implementacema a my. Hackathon se pořádal paralelně v Praze a SF. Tomáš Trnka a já jsme jeli spolu s Lumírem Kajnarem a Martinem Karáskem z Prahy. Z Kanady dorazil Ondra Hlaváček, Adam Hu a Ling. Největší oběť pak udělal Jakub Nešetřil, když nám nabídl spaní u něj v garáži a nakonec nám dal 2 super pokoje!

Hacking

Na hackathon jsme dorazili pozdě (Uber zklamal! :), ale svižně jsme udělali 2 týmy - jeden v SF a druhý v Praze, kde bylo 6 Kebooláků (Martin Matějka, Jakub Matějka, Martin Halamíček, Tomáš Kačur, Erik Žigo a Miro Čillík).

Keboola Tentacle

Pražský tým makal na projektu, který jsme nazvali “Keboola Tentacle” a měl za úkol analyzovat vztahy v objektech v GoodData projektu, s časovou závislostí. Prakticky to denně olizuje GoodData projekt, archivuje všechny definice datasetů, metrik, reportů a dashboardů a sleduje jejich vztahy. Je pak snadné ukázat na sloupeček s čísly a Tentacle poví, v jaké metrice/reportu/dashboardu je sloupeček použitý. Pokud se tedy něco změní v datech, je snadné říct, jaký to má dopad na ostrý projekt. Vedle toho to umí říct co se stalo, zatímco jsem byl na dovolené. Celé je to postavené nad API, vyrábí to repozitář json objektů, které jsou uložené v S3, zpracovávají se v Elasticsearch a nad nima je AngularJS aplikace na prohlížení.

Keboola Tentacle, jak jsme jej měli na hackathonu, je k vidění tady.

Klikněte si na zelené “entries” - ukáže se seznam sloupečků v datasetu a všech metrik, reportů a dashboardů. U sloupečků je vidět, jestli je to Attribut (A) nebo Fact (F) a kolikrát někde figuruje.

Kliknutím na sloupček “part_in_month” se zvýrazní kde všude daný sloupec figuruje. Tyhle pohledy jde kroutit mezi sebou. K olizování GoodData projektu je použité GoodData Ruby SDK, což koukám, že se dneska jmenuje GoodData Automation SDK - sakra, kam na tyhle rádoby trendy jména choděj :-)

S touhle věcí kluci z pražskýho týmu vyhráli třetí cenu ($500), což je super úspěch!

Syntetizované Objekty

Tomáš Trnka, Adam Hu a Ondra Hlaváček pak v San Fran kanclu kutili projekt, kterej ani nemá název, ale je podle mě hyper cool, jen nikdo nepochopil, co to dělá, protože to vypadalo jako když klonujeme hotový dashboardy normálníma GoodData funkcema.

O co jde? Měl jsem hypotézu, že bez ohledu na model dat, pokud chci udělat graf, co ukazuje “Client Lifetime Value”, stačí mi vědět, co je klient a kde je vyjádřený “value” - pak prostě sečtu value podle klienta a mám to. Pokud to nepůjde, je blbě model, ale to není věc, kterou potřebuju v tenhle moment řešit.

Adam a Tomáš udělali drobný generický Salesforce BI projekt, ze kterého posléze vzali definice metrik, reportů a dashboardů a všechno co se vztahovalo k datům, nahradili nějakým klíčovým slovem (místo ID sloupce pro “revenue” by v definici třeba "%%REV_COLUMN%%”).

Ondra mezitím udělal js aplikaci, napsanou v GoodData JavaScript SDK, která mu umožňuje otagovat přímo v GoodData sloupečky. Aplikace se de-facto ptá na pár otázek typu “vyber sloupec, kde je datum založení objednávky” nebo “označ ID, které určuje zákazníka” nebo “jaký typ transakce znamená, že je zaplaceno?". Takhle získané informace strká přímo do GoodData projektu, aby nad nima následně vygeneroval z šablon metriky, grafy a dashbaordy.

Na první pohled to vypadá, že do prázdného projektu strčíme hotový dashboard, ale celý trik je v “rozhovoru” s uživatelem, kde úplně obecně odpovídá na otázky, ze kterých pak syntetizujeme úplně unikátní projekt (vždy v závislosti na modelu dat).

Udělat tuhle věc byl mega výkon, protože GoodData JS SDK, které jsme chtěli použít k autorizaci a abstrakci od GD, nepočítá (minimálně tehdá - možná se to od té doby posunulo), že by běželo kdekoliv jinde než přímo na serverech GoodData. My jediní jsme neměli to co ostatní - kompletní přístup k testovací infrastruktuře. Takže pro nás bylo nemyslitelné třeba udělat v rámci hackathonu nový druh grafu, co se prezentuje přímo v projektu. Díky tomu jsme třeba jen 8 hodin řešili, jak to celé rozjet, aby se dalo začít programovat. Cejtil jsem to jako docela silný handicap, ale s ohledem přes rameno to samozřejmě nevadilo :) Nutno podotknout, že se o nás kluci hodně dobře starali a snažili se nám to pomoct rozběhnout!

První místo (a $3000) na hackathonu vyhrál Petr Cvengroš s nevím kým. Udělali super interaktivní LDM vizualizaci, u které je jen velká škoda, že ji dodnes nedostali do produktu a leží zahrabaná v prostředí “Labs / Apps” o kterém nikdo moc neví :(

Výstupy z hackathonu zvalidovaly nějaké koncepty, které teď zpracováváme - o tom snad časem.

Lessons learned:

jedna "modrá pilulka" Martina Karáska = spíš celej let
AT&T pořád používá 1000 let starý v.35 kabely
v GoodData kanclu je zakázaný instalovat vlastní kamery (porušeno!)
v GoodData kanclu nesmíme bejt sami bez dozoru (porušeno! dozor usnul :)

v noci maká jen Ondra Hlaváček, pak já, pak indové ze Saama.com; nejvíc to flákaj kmenový zaměstnanci a čínská delegace z Keboola :-)

po GD kanclu na wc jen na koloběžce, nad ránem součastně i na skejtu
Karásek a Trnka jsou teplý => musej mít Corvette :)
když v noci opilej Petr Olmer říká: “tady bydlí Svára” a zvoní na zvonky, tak vyběhne pes a budou po vás střílet
když se acebook snaží, jde v SF koupit i bryndza - a pak pan Tully z Apiary vysmrkne halušky!

Pár fotek tady.

Odkazy:

Web Hackathonu: http://hackathon.gooddata.com/ (kopie: http://note.io/1uUQZK4)
Bobův GoodCraft: https://developer.gooddata.com/blog/hackathon-project-goodcraft
Metric Editor: https://developer.gooddata.com/blog/hackathon-project-new-shiny-metric-editor
GoodMigration: https://developer.gooddata.com/blog/hackathon-project-goodmigration
LDM Visualizer: https://developer.gooddata.com/blog/how-we-won-the-all-gooddata-hackathon

Pokud víte o jiných článcích, prosím do komentářů, rád to aktualizuju.

Zeman & Pražský Majdan

Facebookem se šíří zděšení ze Zemanova slovníku. Zbytečný brečet nad rozlitým mlékem...

Místo resharů prezidentských vulgarismů skočte o víkendu na Staromák, kde jede akce Pražský Majdan. Mimo jiné tam můžete podepsat petici proti Zemanovi ("Zeman - putinova loutka") - přijde mi to jako vkusné vyjádření odporu, když volby jsou daleko. Jasný, prdelní lízačku v čínský televizi (záznam na youtube, článek na novinky.cz) nebo jiný jeho vesnický manýry to úplně nekompenzuje, ale lepší než fňukat po sociálních sítích, kde zemanova držka soupeří o emoce s uřezanejma hlavama a opuštěným kanárkem v Dalasu.

Jsem hrdej na Erika, kterej tam každý víkend pomáháním vyjadřuje odpor proti tomu co my ostatní zvládáme jen kritizovat z tepla obyváků. O solidaritě s jeho kámošema už vůbec nemluvím... Klobouk dolů, vydržel jsem tam hodinu a solidně jsem mrznul.

Tady si můžete přečíst o čem Pražský Majdan je. "Jak pomoci Majdanu" najdete tady.

JSON parser do CSV

Spustili jsme do takového semi-experimentálního provozu službu na parsování JSONů.

Běží na json-parser.keboola.com:

Jde do ní nahrát JSON(y) a aniž znáte jejich strukturu - server vrátí ZIP ve kterém jsou CSVčka, vždy podle toho, jak rozprsklé to musí být.

Tady je 1000 JSONů (1.1MB), vždy jeden JSON na řádek. Můžete si zkusit to zkonvertovat - nechte to načíst přímo z URL (http://enterprise.hackathon.bi/sample_1000_obj.json) a zaškrtněte "Line delimited" - za pár vteřin se vám vrátí ZIP.

Jeden řádek v sample souboru obsahuje strukturované informace o tom, jaký dotaz někdo zadal na seznam.cz a co bylo odpovědí. Takhle to vypadá naformátované.

Služba je zadarmo a bez záruky. Má to API (nemusíte nic vyplňovat ručně), jakmile to Kachna popíše, dám sem odkaz do dokumentace. Technicky vzato by to mělo zkonvertovat třeba bambilión jsonů najednou, ale nijak to netestujeme a pokud tam pošlete 1GB zip, asi crashne spojení browseru a CSVčka zůstanou na serveru a nikdy se k nim nedostanete - to časem vylepšíme!

Roman Nováček a Gorila Mobil

Začátkem července 2014 oznámilo O2, že kupuje Gorila mobil, firmu, která podobně jako Dáme Jídlo přišla do Kebooly pár měsíců před svým oficiálním startem a začala si domlouvat analýzu dat. Pokud si dobře vzpomínám, přišli nám jako parta pankáčů - není normální, že vám někdo zavolá, a když mu řeknete, že mu rádi pomůžete, pošle vám rovnou velkej balík peněz jako zálohu za (dosud oficiálně neobjednaný) služby… Jeden z pankáčů je Roman Nováček - mozek, co přemýšlí trošku jinak, než vy nebo já.

Střih o 1.5 roku dozadu.

Je 23.4.2013 a já jedu do TechSquare za Romanem, co toho času stojí za firmou tarifomat.cz. Upřímně se mi tam moc nechtělo. Z tarifomatu se vyklubala firma s neuvěřitelně těžkým postavením (dostávají provize od operátorů poté, co jima dohozený klient 1/2 roku bezchybně platí) a se složitým obchodním funnelem plným pastí typu “kurýr nenašel adresu udanou ve formuláři”. Vyloženě klient pro nás, jen by potřebovali sedět na 30x maržovějším produktu. Zatli jsme zuby a Vojta Roček celej projekt zpracoval k všeobecné spokojenosti. Jinak to nešlo - náš VP of Propaganda jasně napsal, že je na nás spolehnutí - a kdo by si s Goebbelsem zahrával, že? :)

Toho času získal tarifomat perfektní přehled nad celou svojí pipeline (až 1500 poptávek denně), dneska Roman říká, že prvně pochopili, co se ve firmě děje.

O 7 měsíců později zvoní telefon a volá Roman. Tajuplně mluví o virtuálním operátorovi a začíná s náma připravovat design firmy řízené metrikami. Jakmile se někdo takhle chová, přestávám být schopnej udržet pozornost při čemkoliv jiným a začne mě to zajímat. Ze začátku to vypadalo jako řeči, ale pak přišly peníze a hned za nima první zadání, schůzky a plánování, co přesně budem řešit.

Gorila mobil byl další virtuální operátor (v rámci sítě O2), co se snaží být cool - podívejte se na jeho YouTube kanál. Cool styl ale není ingredience úspěchu…

Roman si s naší pomocí postavil denně aktualizované dashboardy, ve kterých sledoval aktivační funnel s rozpadem na marketingové kampaně. V O2 na to koukali jako bacil do lékárny. Počet aktivovaných SIM roste, nákladová cena klesá - všichni slaví. Jen Romanův tým ne. Lidi tarify nepoužívají, jak si v Gorila Mobil představovali. Co teď?

Pátek: “Zavrtáme se do GoodData Dashboardů a vymyslíme to!”

Neděle večer: Claim “Gorila mobil - nejvíc internet, FUP you!” se mění na “Hodina volání za 5 Kč a tolik dat, kolik potřebuješ”.

Kompletní switch pozice značky, která se spoléhá pouze na data! Mrazí mě v zádech, a zatímco si v kanclu hrajeme ping-pong, Romanův tým válí dál! 5Kč/hod zafungovalo - mají tvrdá data k dalším vizím, jsou odvážný a plný energie. Romanova filozofie, že data slouží k popisu dnešního stavu a zároveň validaci, zda podnikáním točíme kormidlo správným směrem, se v praxi ukazuje jako super úspěšná. A stejně jako v Dáme Jídlo, i Gorila mobil prostupují data - "nebyl čas něco schovávat, všichni (call centrum, O2, investoři, partneři) ví všechno" - počty objednávek za den, srovnání oproti minulému týdnu/měsíci, ceny objednávek, ceny aktivací, počty lidí v zákaznické bázi, jak dobíjejí, kde dobíjejí… Bohužel tahle pouť trvá jen 3 měsíce - projekt je tak úspěšný, že jej O2 kupuje a Roman chvíli na to odchází do svého nového působiště - a Keboola tím získává dalšího zákazníka, který vypadá neméně super - ostatně kdo máte kryt na mobil třeba z pravýho třešňovýho dřeva? Jsem zvědavej, jak se (datově) postaví k věcem jako je doživotní záruka bambusovýho pouzdra na iPad :-)

Roman je v těchto dnech v Číně a cpe se tam kuřecíma pařátama - takže jsem s ním udělal jen stručnej asynchronní rozhovor přes Google Docs :-)

PŠ: Romane, co bylo na začátku Gorila mobil nejtěžší?

RN: Přesvědčit O2, že musíme takhle agilně fungovat a že není čas na meetingy. Chtěli jsme firmu kompletně zaměřenou na marketing a 100% řízenou daty. Na začátku tomu nikdo (v O2) nevěřil. Dneska (po akvizici Gorila mobil) chtějí (O2) to samé, co jsme měli my (kolik včera stály aktivace a z jakých kanálů jsme je měli). Kope tam za to Dušan Šimonovič a Jiří Caudr - snad budou úspěšný! Když přesně víš, co se ve firmě děje, nemusíš spekulovat. To ti dává obrovskou sílu rozhodovat a makat, protože přesně víš, co děláš. Žádný bloudění ve tmě. Tohle odděluje zrna od plev :-)

PŠ: Jak to myslíš, “odděluje zrna od plev”?

RN: Když nemáš o co svoje rozhodnutí opřít, vytváří ti to - jako manažerovi - vůči investorům jistý polštář, takové semi-alibi. Když něco nevyjde, vždycky můžeš říct, že se změnil trh nebo zapůsobila nějaká externalita. Snadno věci okecáš. Pokud ti většinu rozhodnutí podkládají data a každý ti přes ramena kouká na tvoje výsledky, tak jdeš se svojí kůží na trh. Když něco poděláš, je v datech vidět, jaký okolnosti byly před rozhodnutím a jaké jsou dneska. Já to mám rád a nemůžu to dělat jinak - moje hlava takhle funguje :-)

PŠ: Jak se ti s náma dělal druhý projekt?

RN: Jakmile jsme přesvědčili partnery, že budeme stavět “metric driven company”, byl největší kus dostat tam všechny data. Informace ze sítě, z marketingových tabulek, google analytics, pošty, kurýra, CMS atd. Hodně nám pomohl Martin Hakl a jeho firma Breezy, která dělala web a napojení všech našich dat na vás.

PŠ: Mohl bys něco ukázat?

RN: Jasně, trochu jsem zamazal osy… Asi se hned zeptáš, co to je a jak jsme s tím pracovali, co? :) V tom grafu je vidět, jak se nám dařilo aktivovat SIMkarty v čase. Přerušované čáry jsou lineární extrapolace - tedy zjednodušení průběhu (vyjádření trendu) - abys v grafu viděl, jestli to má “tendenci” růst nebo stagnovat. Tenhle graf jsme měli na dashboardu a mohl sis ho filtrovat podle kanálu, ze kterého SIMkarty přicházejí - například PNS (trafiky). Stejně tak jsme se mohli dívat, jaké aktivace máme podle marketingového kanálu. Kliknutím na body v grafu se otevřel jiný dashboard, kde bylo vidět, kolik peněz nám z daného balíku aktivací padá a jak se lidi chovají. Na obrázku se to špatně předvádí - lepší je to ukazovat :)

PŠ: Mám tendenci se lidí ptát, jaký byl jejich “aha moment” - takové to “Do p*či, kormidlo doleva!” - podělil by ses o něco?

RN: Utráceli jsme něco kolem 1,5MKč/měsíčně. Výkonost marketingu byla super! Když jsme ale různě daty drillovali, všimli jsme si, že máme v bázi několik kampaní, které jsou špatné a celé to táhnou dolů. Paradoxně to nebylo vidět, protože jiné věci byly naopak extra kvalitní. Kdybychom nedrillovali do detailů a dívali se jenom na průměrné výsledky, tak na to nikdy nepřijdeme. Prostě jsme měli extra kvalitní kampaně a extra špatné kampaně, v průměru to bylo OK. Když jsme ale šli do detailu a na tohle přišli, tak jsme okamžitě ty nefunkční kanály stopli a druhý den všechno dělali od znovu. Denně jsme expedovali 500 SIM karet a věděli jsme, kolik nás stojí, za jak dlouho se přihlásí do sítě, kolik utratí, jak dlouhou zůstanou. Mohli jsme “v klidu” spát :-)

PŠ: Takže data guy forever?

RN: Tak to si piš :-) V každý další firmě bude datová analytika to první, co budu řešit. Díky tomu, že do firmy vidíme, tak máme mnohem větší odvahu riskovat a zkoušet nový věci.

Proč nepoužívat Slack.com?

Po asi 1/2 roce testování Slack.com máme v týmu programátorů první vzpouru - přemotivovaný smajlíky, který v defaultním nastavení přináší moc štěstí.

chatyachalupy.cz - příběh naší dovolené

Pronajali jsme si přes web chatyachalupy.cz roubenku v Kořenově (screenshot stránky). Podle webu vypadala moc pěkně, tak jsme zaplatili provizi firmě TOURTREND s.r.o. a zálohu za pronájem majiteli roubenky.

Po příjezdu na místo jsme zjistili, že je roubenka sice fajn, ale místo u lesa je v těsné blízkosti silnice, navíc s odtrženým svahem a na neoploceném pozemku. Místo rekreace s dětma a psem to vypadalo na týjden hysterického hlídání, aby nám děti nespadli pod auta, kterých mezi Kořenovem a Příchovicema jezdí požehnaně. Velká stavba za domem, ve které má dílnu majitel roubenky a denně tam jezdí pracovat, je jen třešnička na dortu k idilické dovolené s kámošema.

Majitelka baráku naše argumenty pochopila, vrátila kauci placenou hotově po příjezdu a sepsala s náma reklamační protokol. Odsouhlasila, že nám vrátí i zálohu za pronájem poslanou na účet, pokud jí k tomu TOURTREND s.r.o. vyzve.

Krok #1

Zkoušíme se s provozovatelem webu chatyachalupy.cz domluvit na uznání naší stížnosti a vrácení peněz. Zatím emailem - který od neděle úspěšně ignorují.

Stay tuned... zatím bych rád každého před podobným webíkem varoval, zkušenost zákaznického servisu spíš odrazuje...

Kdybysme se takhle chovali my, jsme v krachu. Doufám, že TOURTREND s.r.o. najde ke svýmu chování nějakou super výmluvu :-)

UPDATE 11.8.2014:

V minulém týdnu se Alena asi 30 minut hádala s Markem Meitnerem, jednatelem a 20% společníkem TourTrend s.r.o. (http://daty.cz/f/775754/tourtrend-s-r-o). Pan Meitner to celé vidí jako naší chybu, protože jsme si měli zavolat a všechno si předem zjistit. Fakt, že kdyby publikoval fotky, jaké jsme vyfotili my (viz nahože), nikdy by tam nikdo nejel, je mimo jeho chápání. Komunikovat s nima můžeme jedině poštou nebo po telefonu, protože se jim podařilo nám poslat email jen ve fázi "do zaplacení" - takže příkaz k platbě a potvrzení objednávky došel na Aleny email v pohodě, ale odpověď na email, ve kterém se s nima chceme domluvit na reklamaci už ne.

Vyjádření nakonec poslali poštou. Dorazilo dneska. Stručně v bodech + komentář:

na vyjádření mají 30 dnů, ale přesto nám odpovídají během 3 dnů (tohle je signál, že mluvíme s podnikatelem z devadesátejch let; i když reklamuju SMS jízdenku na Dopravní podnik hl. m. Prahy, odpoví do druhého dne)
všechno na webu odpovídá realitě (ano, a podstatné věci ignoruje)
další informace jsme si měli explicitně vyžádat předem (neřešíme málo široké okno v kuchyni nebo malej proud vody ve sprše, ale tristní stav okolí rekreačního objektu)
to že tam je silnice je naprosto jasně vidět tady http://bit.ly/1sQP6KC (což je pravda, ale je to schovaný a šikovně zamaskovaný na zimní fotce, navíc to mohl vyfotit tak, aby to bylo jasnější a předešel nedorozumění; to že to tam prostě umě schovávají (viz třeba tady: http://bit.ly/1sv1Gl6) je prostě smutný)
majitelce objektu vznikla škoda (stornopodmínky) a může ji po nás vymáhat (majitelka objektu uznala, že to není "ono" a bez řečí nám vrátila kauci placenou na místě a rozloučili jsme se)
naší žádost o navrácení jejich podílu považuje za neoprávněnou (jak jinak, že :)
moje další nepravdivé či subjektivně prezentované informace bude řešit žalobou pro pomluvu (hlavně bych napadl můj subjektivní názor - naštěstí tady nic není nepravda :)

Myslím, že to bude celé ještě docela zábava. Je úplně šokující narazit na podnikatele z Kroměříže, když máte zkušenosti s přístupem k zákazníků, který poskytují firmy typu DámeJídlo Tomáše Čupra. Reálně tady pan Meitner hraje o asi 4.800,- Kč za svojí provizi a asi to samé jako zálohu na ubytování (placené majitelce objektu), kterých se drží zuby nehty. Nejspíš nás vážně vidí jako pomatence, kteří na něj zkouší, jestli neuhrají vratku.

Obrátil jsem se na Sdružení Obrany Spotřebitelů, který mají super právní poradnu. Podle fotek existuje jasná vada bránící či stěžující užívání. Navíc stranám bylo známo, že účelem smlouvy o pronájmu je ubytování s dětmi a psem, což je (opět podle fotek) zhola nemožné a pohyb po pozemku je zdraví ohrožující. Nabízejí bezplatné mimosoudní řešení spotřebitelských sporů a publikaci naší spotřebitelské zkušenosti. Jsem zvědavý, jestli by pan Meitner pak žaloval pro pomluvu i je, když se mě chystá popotahovat u soudů za můj bolgísek :) Co mi ještě uniká - a možná je to o tom, že na něj denně 10 lidí zkouší vrátit peníze za malej tah v komínu nebo málo jasnou hvězdnou oblohu - proč je tak radikální, když to prostě vždycky prohraje? Kdyby nám zkusil navrhnout že se o ten problém podělíme, asi ani nemrkneme, ale až to požene k soudu pro pomluvu, jen se o tom dozví dalších kvantum lidí.

Resume k dnešku - příště spíš Airbnb.com, zásadní je, že tam může člověk dávat komentáře a být v kontaktu s majitelem předtím, než něco objedná.

Next steps:

založím si email na centrum.cz, aby mi od TourTrendu chodily emaily
zkusím navrhnout hledat kompromis
zkusím navrhnout mediační služby SOS

Informace na dosah ruky - Pebble Watch

Komplikované dashboardy za dvojitým přihlášením a trojitým firewallem přestávají být cool. Naši zákazníci potřebují podstatné informace doslova na dosah ruky - a to nesplňuje ani report v iPadu.

Na startu naší vlastní "wearables" mánie jsme zvolili hodinky Pebble.

Proč?

Každý má svoje "jedno číslo", které mu napovídá, jak se mu daří. Obchodníka může motivovat, kolik si vydělal na provizích a jak si stojí oproti svému týmu, CEO bude chtít znát ukazatele od CFO, apod. Nemusí nic dělat, jen se podívá na hodinky...

Jak to funguje?

Do mobilu si nainstalujete Pebble aplikaci (Android, iOS) a v ní si nainstalujete "Keboola Stats" do které zadáte token, který vám vygeneruje náš "Pebble Writer" - ten bude v UI za chvilku.

Co to umí?

Aktuálně to umí každých pár vteřin v hodinkách aktualizovat libovolné číslo, které je dneska zanesené na dashboardu, který může ukazovat 2 čísla a jejich změnu v %. Například: kolik mám obrat od dnešní půlnoci do teď (aktuální přesné číslo) a o kolik % je to jiné oproti obratu včera za stejné období + kolik mám objednávek za dnešek a změna vůči včerejšku:


Obrat 123.000,- Kč (+7%)

Objednávky 600 ks (-12%)

Spočítat takhle umíme téměř cokoliv na co máme data (v tuhle chvíli se umíme napojit na 33 datových zdrojů + máme API pro příjem dat, která k nám posílá zákazník). Rychlost aktualizace čísel v hodinkách je nastavená na 1x/30 vteřin. Spolehlivě můžeme jít tak na 1x/10 sec, pak už to přestává dávat smysl - zpoždění v mobilní síti a čas potřebný pro načtení nových dat a spočítání metrik pro dashboard v hodinkách.

Teď ještě dostat to samé na hodinky od LG, Samsungu a Motoroly. Celý stack, od sběru, analýzy dat a API už máme, zbejvá frontend :-)

Kdo by si to chtěl vyzkoušet, máme jedny červený Pebble hodinky na půjčení - kdo má vlastní, může do toho naskočit hned. Samozřejmě musí mít data v Keboola Connection (data umíme vytahat i z existujících GoodData projektů!).

Credits: Tomáš Kačur za to že to celé postavil, Martin Karásek že během asi 45 sec vyšvihl ikonky do Pebble Store.

P.S. Pebble aplikace v telefonu (napsaná v JS) a aplikace v hodinkách (napsaná v Vanilla C) je jako OpenSource k dispozici v našem GitHubu. Backend vrací na metodu stats tohle (dokumentace API bude asap v Apiary.io):


{

    "heading": "Revenue",

    "title1": "Today",

    "percent1": "10",

    "number1": "123.4",

    "title2": "Week",

    "percent2": "20",

    "number2": "245",

    "changed": "2014-07-08T13:44:22+0200"

}

IKEA a "péče" o dětičky

Když jdeme na ORL, cpou tam dětem bonbóny. Je to padlý na palici, ale na druhou stranu proč ne - když můžou doktoři strkat lidem homeopatika, proč by nemohli kazit děti sladkostma, že?

Nechápu to ale v IKEA. Taková 'wannabe' kytičková firma... Když tam dáme Káču do dětskýho koutku (který je super!) na hlídání, dostane na rozloučení lízátko. A samozřejmě druhý pro ségru.

Lízátko s ovocnou příchutí. Složení: cukr, glukózový sirup, regulátor kyselosti: kyselina citrónová, aromatické látky, barviva: E100.

Díky, fuj tajxl největší. Tohle si strkejte do vlastních dětí! Děsí mě, jestli platí, že cukříček za 1.75 Kč spolehlivě pořeší loyalitu kindošů...

Hint pro IKEA v podobný cenový relaci: Pexeso, razítko, omalovánky, korálky, ořezávátko, samolepky, pastelky, prstýnky... a nebo taky nic.

UPDATE: How sugar affects the brain - Nicole Avena:

Agregace v MongoDB, Oracle, Redshift, BigQuery, VoltDB, Vertica, Elasticsearch, GoodData, Postgres a MySQL

"Manažerský shrnutí"

Celý se mi to nakonec asi vymklo z rukou. Snažím se tu dát dohromady popis toho, jak jednu a tu samou úlohu udělat na různých systémech. Na konci jsem to samé udělal s GoodData (linkuju sem z toho 2 screencasty), což je víc high-level nástroj než databáze - přesto je na tom skvěle vidět, jak se s ní dobře pracuje a jak je rychlá.

Tady je souhrnná tabulka:

Intro

Koncem loňského roku jsem našel blogpost "MongoDB 'Lightning Fast Aggregation' Challenged with Oracle”, kde Lukas Eder provádí na Oracle stejné agregace, jako o týden před ním Vlad Mihalcea dělal s MongoDB.

Lukas Edler mi dal zdrojová data, která mají 50.000.000 řádků eventů s časem a hodnotou

created_on,value 2012-05-02T06:08:47Z,0.9270193106494844 2012-09-06T22:40:25Z,0.005334891844540834 2012-06-15T05:58:22Z,0.05611344985663891 2012-01-05T20:47:19Z,0.2171613881364465 2012-02-10T00:35:17Z,0.4581454689614475 2012-06-19T17:46:41Z,0.9841521594207734 2012-08-20T21:42:19Z,0.3296361684333533 2012-02-24T20:29:17Z,0.9760254160501063

Tady je 10.000 řádků na “nažhavení” a celý dataset - obojí s hlavičkou, bez enclosures, delimiter je čárka (ke stažení z mé S3 to bude do půlky září, pak to spadne do Glacieru):

10k rows sample (400kB): https://s3.amazonaws.com/padak-share/randomData10.csv
50M rows sample (1.9GB): https://s3.amazonaws.com/padak-share/randomData.csv

50M gzip verze (770MB): https://s3.amazonaws.com/padak-share/randomData.csv.gz

Nad daty se provádí 2 testy:

Test A - dělá agregaci po letech a dnech v roce, přičemž počítá počet záznamů každý den a jejich průměrnou, minimální a maximální hodnotu
Test B - dělá to samé, ale filtrované na konkrétní hodinu

Zkusil jsem to samé (nebo co nejvíc podobné) provést na dalších databázích - Amazon Redshiftu, Google BigQuery, Volt DB, HP Vertica, Elasticsearch, GoodData, Postgres, MySQL. Nejde mi o to mlátit se po hlavě, kdo je rychlejší, proto moc neřeším, jaké byly HW konfigurace; navíc Google BigQuery je “unknown hw”. Dívám se víc po složitosti, s jakou toho dosáhnout. Na Redshiftu jsem ještě zkoušel 10x to samé - tedy 500.000.000 řádků, které jsou ale 10x opakování zdrojového datasetu. V případě GoodData (na konci) jsem to ještě na závěr zkomplikoval, aby bylo vidět, jak snadné je tam věci řešit.

Tady jsou výsledky:

MongoDB

(detaily přípravy viz Vladův blogpost)

Test A: 129s
Test B: 0.2s

Oracle

(detaily přípravy viz Lukasuv blogpost)

Test A: 32s
Test B: 20s první spuštění, 0.5s druhé spuštění

Redshift

Data jsem do Redshiftu nahrával z S3. Celé to obnášelo udělat před samotným testem tyhle kroky:

vyrobit tabulku
naimportovat do ní data
nešlo mi tehdá při importu rozpoznat formát času ISO8601, tak jsem tabulku musel alterovat

přidat sloupec pro timestamp
nastavit jej podle timestampu v zdrojových datech
smazat původní sloupc s datumy

přidal jsem si tam SortKey, udělal analyze a vacuum

(tady je soupis přesných SQL příkazů a časů: https://s3.amazonaws.com/padak-share/blog/redshift.sql)

Test A

Použitý dotaz:

SELECT EXTRACT(YEAR FROM created_at), EXTRACT(dayofyear FROM created_at), COUNT(*), AVG(value), MIN(value), MAX(value) FROM RandomData GROUP BY EXTRACT(YEAR FROM created_at), EXTRACT(dayofyear FROM created_at) ORDER BY EXTRACT(YEAR FROM created_at), EXTRACT(dayofyear FROM created_at);

Redshift dw1.xlarge (15s)

Redshift dw2.large (7s)

Verze s 500.000.000 řádků:

Redshift dw1.xlarge (182s)
Redshift dw2.large (53s)

Output

Test B

Použitý dotaz:

SELECT EXTRACT(YEAR FROM created_at), EXTRACT(DAYOFYEAR FROM created_at), EXTRACT(HOUR FROM created_at), COUNT(*), AVG(value), MIN(value), MAX(value) FROM RandomData WHERE created_at BETWEEN TIMESTAMP '2012-07-16 00:00:00' AND TIMESTAMP '2012-07-16 01:00:00' GROUP BY EXTRACT(YEAR FROM created_at), EXTRACT(dayofyear FROM created_at), EXTRACT(HOUR FROM created_at) ORDER BY EXTRACT(YEAR FROM created_at), EXTRACT(dayofyear FROM created_at), EXTRACT(HOUR FROM created_at);

Redshift dw1.xlarge (1.3s)(first run)
Redshift dw1.xlarge (0.27s)(second run)

Verze s 500.000.000 řádků:

Redshift dw1.xlarge (46s)(first run)
Redshift dw1.xlarge (0.61s)(second run)

Output:

Pro fajnšmekry ještě query plán:

Google BigQuery:

Je služba od Google, kterou trochu popisuju tady: http://padak.keboola.com/google-bigquery-workshop-s-felipe-hoffa

Komunikuje se s ní pouze přes REST API nebo webový interface. Já jsem použil klienta v konzoli na serveru. Sample data jsem musel stáhnout na disk.

Celé to obnášelo udělat před samotným testem tyhle kroky:

Založit projekt v https://console.developers.google.com/ a pod API&auth povolit BigQuery (a mít tam platební kartu)
založit “projekt” v BigQuery
naimportovat do něj data (samotné nahrání dat trvalo docela dlouho, přesný čas jsem si omylem nezaznamenal)

U BigQuery se nedá nic moc “ladit”. Nejsou tam žádné indexy, klíče, apod.

Založení projektu z konzole:

./bq mk rad.randomData --0s

Import dat:

./bq load --noallow_quoted_newlines --max_bad_records 500 --skip_leading_rows=1 rad.randomData ./randomData.csv created_on:timestamp,value -- ~1500s (čas jsem bohužel přesně nezaznamenal)

Test A

Použitý dotaz:

SELECT YEAR(created_on) AS Year, DAYOFYEAR(created_on) AS DayOfYear, COUNT(*) AS Count, AVG(value) AS Avg, MIN(value) AS Min, MAX(value) AS Max FROM [rad.randomData] GROUP BY Year, DayOfYear ORDER BY Year, DayOfYear; -- 7s (1.3GB)

Test B

Použitý dotaz:

SELECT YEAR(created_on) AS Year, DAYOFYEAR(created_on) AS DayOfYear, HOUR(created_on) AS Hour, COUNT(*) AS Count, AVG(value) AS Avg, MIN(value) AS Min, MAX(value) AS Max FROM [rad.randomData] WHERE created_on >= '2012-07-16 00:00:00' AND created_on <= '2012-07-16 01:00:00' GROUP BY Year, DayOfYear, Hour ORDER BY Year, DayOfYear, Hour; -- 2.9s / 1.6s (cached)

VoltDB

Tuhle databázi jsem našel nějak náhodou. Pyšní se spoustou věcí, ale nakonec jsem narazil na to, že tam vůbec nejde z timestampu extrahovat třeba den v roce a je potřeba tam udělat pre-precessing a data upravit. Celá moje anabáze skočila na supportu, kde mi začal pomáhat VoltDB Solution Engineer jménem Dheeraj Remella, který tvrdil, že ten test provede. Emailování se nám trochu táhlo, takže mezitím stihli vydat verzi 4.0, kde už EXTRACT() funkci měli. Jeho výsledky jsou následující:

Import dat:

Read 50000001 rows from file and successfully inserted 50.000.000 rows (final) Elapsed time: 1735.586 seconds

Test A:

SELECT EXTRACT(YEAR FROM create_on_ts) AS Year, EXTRACT(DAY_OF_YEAR FROM create_on_ts) AS DayOfYear, COUNT(*) as groupCount, SUM(value) as totalValue, MIN(value) as minimumValue, MAX(value) as maximumValue FROM RandomData GROUP BY EXTRACT(YEAR FROM create_on_ts), EXTRACT(DAY_OF_YEAR FROM create_on_ts); -- 70ms

Test B:

-- 330 ms

Časy jsou to super! Zjišťuju, jestli si předpočítal Rok, Den, Hodinu...

UPDATE: Tak ano, ve testovací DB měl pro daný dotaz předem dopočítané odvozené hodnoty roků, dnů, apod. Tady je jeho DDL: https://s3.amazonaws.com/padak-share/blog/voltdb-ddl.sql

Použitý HW byl MacBook Pro (Intel i5 2.5 GHz processor - 2 cores, Memory 16 GB).

VoltDB vypadá zajímavě a podezřele zároveň. Databáze se tam zakládají voláním klienta v konzoli, který spouští nějaké věci v javě a nasává SQL:

voltdb compile -o random.jar random.sql voltdb create catalog random.jar csvloader randomdata -f randomData10.csv --skip 1

... řekl bych, že mi to moc nesedlo, nicméně to budu dál sledovat. Mohla by se z toho vyklubat docela super věc!

HP Vertica

Tenhle test pro mě udělal Honza Císař, protože to bylo v době, kdy instalátor neuměl ani zalogovat vystřílený file descriptory a nainstalovat ji bylo dost peklo (dneska už to neplatí a instalátor je celkem fajn)

Příprava:

SET TIMEZONE 'UTC'; CREATE TABLE RandomData_T ( created_on TIMESTAMP, value DECIMAL(22,20) ); COPY RandomData_T from '/tmp/randomData.csv' delimiter ',' null as '' enclosed by '"' exceptions '/tmp/load.err'; Time: First fetch (1 row): 121.609s. All rows formatted: 121.609s #předžhavuje :) SELECT * FROM RandomData_T LIMIT 10;

Test A

SELECT EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on), COUNT(*), AVG(value), MIN(value), MAX(value) FROM RandomData_T GROUP BY EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on) ORDER BY EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on); -- Time: First fetch (366 rows): 2,068s

Test B

SELECT EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on), EXTRACT(HOUR FROM created_on), COUNT(*), AVG(value), MIN(value), MAX(value) FROM RandomData_T WHERE created_on BETWEEN TIMESTAMP '2012-07-16 00:00:00' AND TIMESTAMP '2012-07-16 01:00:00' GROUP BY EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on), EXTRACT(HOUR FROM created_on) ORDER BY EXTRACT(YEAR FROM created_on), EXTRACT(doy FROM created_on), EXTRACT(HOUR FROM created_on); -- Time: First fetch (2 rows): 0,026s

Honza na to použil AWS instanci typ 4xlarge, takže asi 30GB ram, SSD disky a 4x Intel Xeon E5-2680

Elasticsearch

Dal jsem na Nový rok na tyhle testy teaser na facebook a ozval se mi Karel Minařík, že by to vyšvihl v Elasticsearchi. Nadšeně jsem souhlasil a tady je výsledek. Managerské summary je, že je to pekelně rychlé, ale poměrně složitě a dlouho to data importuje. Pro mě osobně ovšem nedosažitelné díky množství kódu v Ruby. Tady je jak to Karmi popsal:

Čau,
tak jsem se na to mrknul (http://goo.gl/A3j1Up):
Je tam hezký detail, že se nedají použít klasické "date" agregace, protože jestli jsem to dobře pochopil tak v tom SQL seskupuješ podle dne v roce *bez ohledu na rok*, a to samé pro hodiny atd. Nejprve jsem to udělal zkusmo přes `script` ve facetu, ale to bylo dooooost pomalé -- nepřekvapivě, musí evaluovat script pro každý dokument z těch 50M. S filtrem to bylo i tak pod sekundu. Takže jsem tu manipulaci udělal při indexaci, tzn. v Ruby rovnou parsovat datum a ukládat `day_of_year` atd, což logicky zpomalilo indexaci, ale rychlost je teď po zahřátí:

Agregace: 16398ms

Agregace + filtr: 10ms

Tím se mi potvrdilo že ES je na tyhle věci pekelně, pekelně rychlý.

Nějak extra jsem to netunil -- je to EC2 xlarge stroj, ES má 7GB paměti, index má 1 shard, disk to používá ephemeral, tzn. relativně rychlý, ale spinning crap, ES je kromě paměti v továrním nastavení.

Celkové výstupy v příloze, nevím jestli jsem ty query převedl správně, neměl jsem na to moc klidu.

Vcelku zajímavé a hezké cvičení :)

Měj se!,

Karel

GoodData

Na závěr jsem si nechal test GoodData. Určitě nebude útočit na milisekundové mety, ale suveréně zničí všechno ostatní v jednoduchosti jakou toho dosáhnete.

Data z S3 jsem nahrál do Keboola Connection (což je složitost asi jako připojit přílohu do emailu). V Keboola Connection jsem řekl, jak se to má do GoodData nahrát. Samotná příprava GoodData projektu je jednoduchá - označím první sloupec jako datum (s časem) a druhý že je číslo.

Po zmáčknutí tlačítka “Upload Table” Keboola Connection připraví vše ostatní sama: na straně GoodData vyrobí fyzický i logický datový model, zparsuje a exportuje data do formátu který GoodData spolehlivě načte. Pro fajnšmekry přidávám odkaz na log komunikace s jejich API. Klient má tohle schované za jedno tlačítko, případně za jeden API call a nemusí se tím vůbec zabývat.

GoodData si pak data přebere, různě je dál podle náma dodaného manifestu překroutí a naimportuje do BI projektu. Lidem říkám, ať nad tím dál přemýšlí jako nad kompaktní tabulkou, kterou vidí u sebe na vstupu, přestože je to vlastně celé roztrhané po sloupečcích, které na sebe různě odkazují a vytváří vztahy, které se zakreslují jako “sněhová vločka”. Víc o tom, co se v GoodData vevnitř děje, jsem popsal v listopadu 2013 tady (GoodData XAE): Load dat (po zparsování v Keboola Connection má tabulka asi 4GB) trvá asi 60 minut.

Testy:

Pro první test - agregaci přes celých 50 milionů řádků - je potřeba vyrobit tři metriky:

Metrika 1 - počítá počet záznamů [ COUNT(Records of randomData) ]
Metrika 2 - počítá průměrnou hodnotu [ AVG(value) ]
Metrika 3 - počítá minimální hodnotu [ MIN(value) ]
Metrika 4 - počítá maximální hodnotu [ MAX(value) ]

a "podívat se na ně” přes Rok a Den v roce.

Pro druhý test se pouze přidá filter na konkrétní datum a hodinu.

Obojí jsem natočil a dal nesestříhané na youtube - můžete tak vidět, jak je to svižné. Změřit přesně dobu spočítání reportu je možné, ale není to úplně snadně dostupné - v tuhle chvíli to neřeším. Jde mi hlavně ukázat, že je to ve srovnání s jiným přístupem dost snadné.

Ještě mě napadlo to trochu zkomplikovat a ukázat v reportu jak udělat "O kolik % se změnil počet agregovaných záznamů oproti předchozímu dni". Opět nesestříhané video zde:

GoodData nabízí ke každému reportu něco jako “explain” v DB - tedy "co je pro získání dat potřeba udělat". Nakreslené to vypadá takhle:

Postgres

Honza Winkler udělal Test A a B na Postresu (9.3.4). Detaily jsou tady: http://goo.gl/xt3qZM

Import trval: 2 minuty (od oka, neměřeno)
Test A (bez indexu, vacuum, ničeho): 33.55 s
Test B (bez indexu): 4.5 s
Test B (s indexem na created_on, první spuštění): 0.06 s
Test B (s indexem na created_on, další spuštění): 0.015 s

MySQL

Dodatečně jsem udělal ještě test v MySQL. Server má 64GB RAM, SSD disky...

Test A

SELECT YEAR(`created_on`), DAYOFYEAR(`created_on`), COUNT(*), AVG(value), MIN(value), MAX(value) FROM `randomData` GROUP BY 1,2 ORDER BY 1,2; -- 46sec

Většina času je na tmp tabulku:

Test B

SELECT YEAR(`created_on`), DAYOFYEAR(`created_on`), HOUR(`created_on`), COUNT(*), AVG(value), MIN(value), MAX(value) FROM `randomData` WHERE `created_on` BETWEEN '2012-07-16 00:00:00' AND '2012-07-16 01:00:00' GROUP BY 1,2,3 ORDER BY 1,2,3; -- 0.022sec

Resume k MySQL: je to děs :) Hynek Vychodil to vydřenil na 33sec (http://goo.gl/7qKsP4).

Závěr

Pokud nepočítáme loady dat do databází (které jsou pokaždé o rozličné složitosti), lze říct, že na testovaném objemu dat je agregace pro koncového uživatele vždycky celkem svižná. Pokud umíte SQL a potřebujete pár dotazů, hodí se BigQuery, pokud chcete dělat kvantum dotazů a nechcete si spravovat vlastní DB cluster, hodí se Redshift. Pokud nemají data úplně perfektní strukturu, oceníte Elasticsearch (Karmi mi například říkal, že nějaký němec sype do ES clusteru 1TB dat denně a sviští mu to o 106). Pokud budete chtít dál data zpracovávat a/nebo budou vaše dotazy o fous komplikovanější a bude vhodné, aby je někdo kladl interaktivně, užijete Keboola Connection + GoodData.

<Ad>

Klientům přibalujeme kurzy z Keboola Academy, aby uměli psát svoje vlastní jednoduché i složitější metriky, tak jak je vidět třeba tady na videu + jim se vším ochotně pomáháme. Chcete-li si to zkusit, napište mi!

</Ad>

UPDATE 2014-08-05:

Našel jsem Orzo.js od Tomáše Machálka. Jeho vlastní test je tady.