Padákův deníček

11.10.2013, 22:17 - UPDATE: Tomáš Trnka a Radovan Jirka mě v komentářích na Facebooku "sepsuli", že to je moc #nerd. Doplnil jsem pro ně komentáře do závorek :)

Po delší době vykopávám další "weekly digest" novinek v Keboola Connection. Docela úspěšně prodlužuju intervaly mezi publikací těhle změn a novinek,  pokorně jsem se odhodlal přestat tomu říkat "weekly digest" :-) Předchozí 4 proběhly v Google Docs, pak v Mailchimpu a teď jsem to celé přesunul sem, na padak.keboola.com blog. Historické digesty jsou tady: 

• #1 (18.3..2013)
• #2 (25.3.2013)
• #3 (1.4.2013)
• #4 (12.6.2013)

Opět v obraně před "TL;DR" odpověďma přepínám do módu rychlého seznamu s linkama. Dotazy v komentářích, prosím. Čísla bodů nereflektují mnou vnímaný význam.

Obecně Keboola Connection

1. vyrobili jsme generátor UIček a přepisujeme frontend komponent; dovedeme teď různým lidem ukazovat různé UI + stavba UI je skvěle rychlá
2. v backend DB máme nově všechny SAPI tokeny šifrované 
3. servery, které se starají o běh našich komponent, migrujeme do AWS VPC (umožňuje nám to lépe izolovat jednotlivé služby a vynutit si větší bezpečnost na nižší úrovni naší infrastruktury)

TAPI

1. máme Redshift TAPI backend; jakoukoliv existující transformaci s MySQL backendem je možné odbavit na Amazon Redshift clusteru. Kratičká zkušenost s MySQL / Redshift / Vertica / BigQuery je popsaná tady. (Redshift je sloupcová databáze, kterou Amazon "koupil" od http://www.paraccel.com/. Je to SQL na steroidech, de-facto bez limitů.)

SAPI

1. plná podpora asynchronních loadů (díky tomu můžeme ještě lépe horizontálně škálovat)
2. možnost bezpečně emailem doručit nově vyrobený token (kolegovi / klientovi)
3. mazání sloupců tabulek, přidávání a odebírání indexů je zpracováno asynchronně
4. je možné snapshotovat tabulky - pak se provede otisk všech dat, metadat a eventů dané tabulky
1. ze snapshotu je možné vyrobit novou tabulku (rychlá forma "copy")
2. tabulku je možné ze snapshotu taktéž obnovit (rollback)
5. máme API na mazání řádků v tabulce
6. máme API na vyprázdnění tabulky
7. u každé tabulky je možnost nechat si vykreslit Graf, který ukazuje jak daná tabulka vznikla; graf je de-facto pavouk, který ukazuje, jaké transformace načítají jaké tabulky a jaké tabulky z nich pak vyrábí/zapisují. Jednotlivé objekty v grafu jsou klikací a slouží jako navigace

Extraktory

1. databázový extraktor podporuje MSSQL
2. ConstantContact (něco jako Mailchimp, jen trochu víc profi)
3. YouTube
4. Mailchimp
5. Recurly (systém na vyúčtování předplatného)
6. NetSuite (největší cloud ERP systém)
7. Konvertor měn (získává kurzy měn z Evropské Centrální Banky a Česká Národní Banky a různě konvertuje měny v datech v Storage API)
8. všem extraktorům brzo doplníme chybějící UI
   

Writer

1. nově nepoužívá pro upload dat do GoodData CL Toolu - děláme přímý REST API load (zahazujeme komponentu, kterou GoodData dál nechce podporovat - díky tomu zároveň získáváme větší kontrolu nad celým procesem zpracování dat)
2. UI je přepsané do Angular JS
3. ze SAPI exportuje data komprimovaně (jen prostě zrychlení :-)
4. umí se vypořádat s problémem GoodData Auth Proxy, která vrací u některých jobů chybu 401 (bud v Q4 od GD opraveno)
5. report execution provádíme přes REST API a né přes CL Toolu (viz bod 1)
6. veškeré logy v S3 jsou privátní, UI generuje podepsané odkazy, platné 2 dny
7. podpora SSO, pokud writer dostane email platného uživatele, umí na něj vrátit SSO link (SSO je Single Sign On - mechanismus, jak do GoodData přihlásit lidi, aniž musí někam zadávat heslo)
8. podpora Mandatorních Filterů - objekt k filtraci se zadá tečkovou notací dle SAPI, například "out.c-main.orders.product = 7" - writer se postará o všechno ostatní; konfigurace je v SYS stage a je v takovém formátu, aby byla generovatelná z transformace. Je tedy možné pomocí joinu zjistit, který obchodník nově prodává který produkt a připravit mu pro to MUF (mandatorní filter je princip, jak lidem zamezit koukat na část dat v projektu, aniž sami vědí, že koukají na filtrovaná data)

Provisioning

1. pro více sandboxů jednoho KBC uživatele vyrábí společné SQL credentials - není nutné při přepínání projektů přelogovávat SQL klienta
2. umí fallback na perzistentní transformační backend v OVH - ochrana před sleháním SPOT instancí (provisioning zajišťuje vyrobení SQL databáze pro konkrétní datovou transformaci; transformace provozujeme na serverech, které kupujeme v aukci. Tyhle typy serverů nejsou úplně stabilní. Pokud něco selže, přehodí se zpracování transformací do jiného datacentra, které máme rezervované na východě Kanady, u firmy OVH)
3. veškerá data o účtech v SAPI šifruje

Sardine

1. zrychlená pomocí cachování odpovědí ze SAPI
2. podporuje GoodData js eventy
1. Sardine umí ovládat odkazy z dashboardů a dělat s nima volitelné věci (například můžeme přesměrovat odkazy z reportů do modálního okna, místo do nového tabu prohlížeče)
2. umí k reportům, které uživatel downloaduje, doplnit plné texty z dat v SAPI (do GoodData se dá poslat text (buňka v tabulce) s maximem 255 znaků, někdy je ale potřeba v rámci exportu reportu doplnit osekané texty na původní velikost, tohle umíme udělat bezešvě během pár vteřin, díky těsné integraci dashboardu s originálními daty v Storage API)

MISC

1. úspěšně jsme provedli PoC s realtime backendem a transformacema, které jsou inicializované stažením dat; klient nahrává data do Storage API a v momentě stažení jsou vrácena modifikovaná - takto upravené data pak fungují jako realtime reporty v GoodData dashboardech (plní Google Charts na dashboardu)
2. máme frontend k AWS CloudSearch na tagování nestrukturovaných textů (díky tomu se mohou přímo na dashboardu definovat kategorie (např.) konverzací)

Máma mi vždycky říkala, ať si vezmu hypotéku a koupím si byt, že v pronájmu platím cizím peníze a až pronájem skončí, nic mi nezbyde. Že je lepší splácet to samé bance a že jsem divnej když nemám stavební spoření...

Tehdá, před ~11 lety, jsem se po civilce začal starat v První multimediální o servery. Časem jsme měli 3 racky v GTS Nagano, pár serverů v Casablanca, pár serverů v TTC u SuperNetworks (Zdeněk mi opakovaně kradl křížový šroubováky!:), rack serverů v kanceláři, switche Cisco Catalyst, optický konvertory, diskové pole, 2 nezávislé konektivity do kanceláře, hromadu OpenVPN linek, spoustu interních subnetů routovaných přes OSPF, telefonní ústřednu Daktelu a dedikovanej Windows server s Synergy ERP (peklo na zemi!), který se kupovalo na leasing. Všechno jsme vlastnili a bylo to "super" (hlavně v účetnictví - myslím, že to mělo celej vlastní šanon :-). 

Na Šumavě, kousek od Modravy směrem na Antýgl, je parkoviště, kde postavili parkovací automat do staré dřevěné budky, ve které ještě nedávno sedával člověk, vybírající parkovné.

Tahle budka, ve které elektronický automat doslova zasedl židli "dědovi z vedlejší vesnice", na mě křičí jediné: inovace vede k záhubě existujících obchodních modelů. Nemá cenu bojovat za snižování nezaměstnanosti, protože nezaměstnanost bude normální. Nebude práce, převezmou ji stroje. Lidi budou dělat jen tam, kde jiný lidi chtějí potkávat lidi (baristi v kavárně budou ještě chvilku v bezpečí :-) a nebo kde ještě není dost efektivní nasadit techniku. Zhroutí se existující model, ve kterém získáváme za práci peníze, které utrácíme za cizí práci. 

Dva modely, stojící na předpokladu, že práce opravdu není, všichni jen konzumují: Pracují roboti, kteří potřebují jen energii, tu vyrábí elektrárny ve kterých pracují opět jen roboti. Roboti se porouchávají, ale opravují/vyměňují je opět jen roboti. Pro lidi zbyla jen "zábava". Produkce potravin, distribuce zboží, doprava lidí, školní systém (co se bude učit když nebude profesní uplatnění?), zdravotnictví, 99% zábavy, atd... všechno zajišťují roboti. Lidi jsou jen od toho, aby měli kámoše, s nima se bavili, množili se, atd... (omfg!).

1. každý vlastní jednoho či více robotů, kteří makají za něho samého, tihle roboti vydělávají peníze pro svého majitele; stávající ekonomické modely de-facto fungují bez zásadních úprav - jen za kždého maká technické alter ego.
2. roboti patří státu na jehož území operují, jakoby za ně nikdo neplatí, systém je samosvorný (jediný vstupní prvek je energie a materiál). Obchoduje se primárně se surovinama typu chemické prvky a "endemitní" potraviny (mořské ryby se dál musí vozit do vnitrozemí). Lidi objektivně nemají kde získávat peníze - nemakaj - ale přetrvává potřeba "za něco si kupovat zboží a služby". Státy za tímhle účelem primárně přerozdělují "kredity" (peníze?), na kterých vznikne paralelní ekonomika - něco jako gambling. Lidi budou v téhle paralelní ekonomice dělat voloviny a za ně si měnit kredity. Tohle bude prostor, kde vynikne podnikavost, která v primární robo-ekonomice bude zabitá (nemůžu vyniknout jako šikovnej stavbyvedoucí, protože tohle pracovní místo neexistuje). Svět jak ho známe, bude z makroekonomického hlediska nefunkční. 

Co se stane s duševním vlastnictvím? Jak na tom bude majitel licence na tyhle roboty? 

Ponaučení: každá práce musí buď produkovat šťastné lidi (baristi) a nebo směřovat k ničení jiných pracovních míst (inovátoři robotů). Kdo svojí prací neprodukuje (alespoň nepřímo) nezaměstnané, je v tomhle světě ohrožený (hlídač parkoviště, pokladní v TESCO).

Před pár měsícema jsem napsal blogpost "Čím je GoodData výjimečná?". Hodně jsem se od té doby snažil připravit popis něčeho víc reálného. Bohužel jsem často narazil na zákaz publikovat cokoliv, co děláme. Paradoxně nám klienti nezakazují o "jejich" GoodData mluvit kvůli strachu z odhalení reálných čísel, ale kvůli snaze nenavádět konkurenci k podobnému chování ("čím později ostatní na trhu napadne používat GoodData.com, tím víc času budeme mít k upevnění naší pozice"). 

Vykupto.cz naštěstí netrpí nedostatkem sebedůvěry a domluvit s nima nakouknutí pod kalhoty nebyl vůbec problém. Díky za to patří především Jiřímu Musilovi, který ví, že "data rocks", a tak si sehnal Petra Homolu. Petr do Vykupto.cz nastoupil hned po škole (diplomku psal na "Vybrané metody pro aplikace pokročilých analytik v prostředí Cloud"). Petr za svoji práci dostal cenu děkana, i přesto, že to podle všeho bylo psaný v pivnici :)

Petrovou úlohou byla hned od začátku péče o firemní analytiku a vznikající GoodData projekt. Do doby "před Homolou" byla firma řízena na základě reportů, které byly naprogramované in-house a pokrývaly základní metriky. Reporting postrádal složitější pohled na data jako celek a jakékoliv změny vyžadovaly zapojit programátory. Cokoliv měnit bylo drahé a neflexibilní, často i na hranici realizovatelnosti. Od GoodData očekávali platformu, nad kterou si postaví vlastní analytický BI projekt, ve kterém spojí svá fragmentovaná data dohromady. 

Do implementace se pustili s naší pomocí. Myslím, že na nás měli od Slevomatu kladné reference, a tak celkem bez přemýšlení sáhli po našem systému Keboola Connection (KBC). Jediné, co na své straně museli udělat, bylo napojení jejich interní databáze do KBC. Všechno ostatní se pak "nacvakalo" u nás online přes browser. KBC je pro ně dneska datawarehousem a místem, kde se data čistí, obohacují a míchají dohromady. Na konci těchto procesů se odesílají finální struktury do GoodData. 

Zajel jsem za Petrem Homolou, abych z něj vytáhl pár informací a pocitů:

já: Ahoj Petře! Díky za tvůj čas a příležitost s tebou pokecat o tom, co v Keboola Connection kutíš nad datama a co z toho pak je v GoodData. Začněme tímhle: jak se změnily procesy kolem sbírání dat?

Petr Homola: Dat se sbírá a vyhodnocuje daleko více než předtím. Nově sbíraná data (například editační časy, počty revizí) nám dávají dobrý přehled o efektivitě našich procesů. Vše v Keboole Connection se navíc odehrává v mém oblíbeném jazyku SQL, takže stačilo jenom pochopit princip transformační vrstvy a bylo do pár dní hotovo. Úžasný je běh ETL nezávisle na našich serverech. Dnes můžeme měřit jakékoliv komplexnější vazby, například nákupní chování zákazníků odhlášených z emailingu. Měřit můžeme prakticky cokoliv na čemkoliv. Firemní data se zavedením GoodData/Keboola stala velmi cenným zdrojem informací pro všechna oddělení. Efektivnější přístup k informacím a možnost mít vlastní reporty, přizpůsobení dashboardů na míru, apod. jsou nedocenitelné. Rozhodně se poslední dobou nikdo neptá, jestli to umíme zobrazit/naprogramovat, pouze se ptají, jestli ty data už posíláme/taháme do Keboola Connection a jsou nebo nejsou napojena v GoodData.

já: Co dneska v GoodData přesně děláte?

Petr: Sledujeme tam veškerou statistiku a KPI firmy, např. last-day/týdenní/měsíční přehledy. A především dlouhodobý vývoj a výkon. Krásně se tam zobrazují trendy. S tím pak pracuje každý manažer, jenž chce data hned a přehledně zpracovaná. Adopce celého řešení proběhla skvěle. Máme teď  BI platformu, která nám umožňuje dívat se na firemní data komplexně. GoodData prorostla celou firmou a nyní žijeme v naprosté symbióze. Pokud mi něco chybí, do 10 minut to tam díky Keboola Connection mám. Co se lidí týče, používá aktivně GoodData asi 40% - nejvíc obchodníci, management a marketing.

já: Dostáváte z toho odpovědi, které jsou nad rámec běžného reportingu? Myslím tím opravdové vytěžování znalostí.

Petr: Samozřejmě, Data Mining těch opravdových znalostí je strašně důležitý. Běžně se stává, že nacházíme v datech opravdu cenné informace, které bychom jinak nezískali. Někteří si uvědomují, že cokoliv v datech může být použito proti nim :) Nahradili jsme pocity z fungování za realitu z GoodData. GoodData se často rozebírá i na poradách, většinou ve spojení: “Ale na přehledu obchodníků je to jinak...” nebo “Tenhle deal má boží konverze...”. Ve spojení notebook a projektor se dají reporty stavět “on demand”, což dokáže neuvěřitelně rozpohybovat diskuzi. Například se nám povedlo do GD přenést kompletní data z emailingu, což má potenciál pro velkou optimalizaci.

já: Máš nějaký report, který měl svůj aha-moment a který můžeme publikovat?

Petr: Jasně! Potřebuju ho ukázat maličko anonymizovaný, ale myslím, že to nevadí. Povedlo se nám integrovat obrovské množství informací o emailingu a data z prodejů. Graf nám ukazuje metriky kolem prodejů v rámci segmentů z emailingu a pokud si dobře vzpomínám, hravě nám to rozdrtilo jednu hypotézu, kterou jsme delší dobu měli a pevně v ní věřili.

já: A co nějaký wow efekt? Něco jako "Do p*či! Kormidlo do leva!"?

Petr: Takhle bych to asi neřekl, ale jsi blízko :) Ten příklad s emailingem a obchodem se tomu trochu blíží. Obecně se dá říct, že před GoodData jsme neměli tak zjevné informace o prostředí, ve kterém podnikáme. Nyní se cítíme strašně sebejistí, dokážeme téměř všechno a velmi rychle a navíc s vypovídající hodnotou.

já: Co chystáš s Keboola / GoodData do budoucna?

Petr: Tlačím na ještě těsnější integraci do firmy. Akurátní a rychlé informace každému obchodníkovi na stůl. Rád bych tu viděl po ránu vysedávat lidi s kafem, croissantem a GoodData dashboardem v iPadu :-) Technicky ale připravuju hlavně rozšíření našeho ETL o pokročilejší analytiku a forecasting, rád bych dotáhl dynamickou segmentaci a trochu vylepšil existující metriky o GoodData Extensible Analytics Engine (XAE) a o poznatky z Keboola Academy. 

já: Petře, co bys mi řekl na závěr? Když se ohlídneš, jaký to byl pro tebe rok? Jak se cejtíš po té dlouhé cestě?

Petr: Rozhodně je to výjimečná zkušenost, člověk se naučí nejen dělat statistiku a vytvářet diagramy, ale také ovládat a budovat celé řešení. Jelikož je CLOUD a BI poměrně stoupající trend, určitě se dá říci, že člověk ovládající tyto technologie se rozhodně neztratí. Jsem moc rád, že jsem ve Vykupto.cz a mám příležitost dělat na tomhle projektu. Co myslíš, měl bych si jít říct o větší plat? ;)

já: No tak to rozhodně! Šéf bude mít radost, k čemu tě navádíme :-) 

Abych to nenechal úplně náhodě, zašel jsem ještě ke klukům ze Skrz.cz. Pro ty, kdo je neznají, Skrz.cz je největší agregátor slevových serverů. Díky své ojedinělé pozici se může pasovat do role "auditora" trhu. Oni vědí, kdo podvádí, vědí první, kdo krachuje, vědí prostě všechno. Poprosil jsem je o komentář k pozici Vykupto.cz na trhu, jak je ze svého pohledu vnímají, a zda na nich je něco zajímavého. 

"Vykupto.cz se stabilně drží na 2. pozici mezi slevovými servery. Ačkoliv se pozice nemění, je zejména v roce 2013 znatelný nárůst obratu a získávání většího podílu na trhu. Oceňuji na spolupráci s Vykupto, že se vždy bavíme o kampaních jen v řeči čísel a rozhodnutí nepadají na základě emocí.", Petr Kováčik, ředitel vyhledávače slev Skrz.cz

K tomu jen dodám, že Petr Kováčik trefil hřebíček na hlavičku. "You can't manage what you can't measure"...

Přeju Vykupto.cz, ať se jim nadále daří a ať jim práce s daty přináší co nejvíc ovoce. Jsem rád, že k tomu můžeme svojí troškou přispívat!

Read more »

Koncem tohoto týdne měla česká část GoodData.com společný program v Hradci Králové. Sjeli se tam z Prahy a Brna aby spolu 2 dny řešili jak se jim daří a co plánují dál. Jako hosty nás tam všechny z Kebooly pozvali a i přes to, že si tam odhodlaně prali spodní prádlo, nezavřeli nám jediné dveře a nechali nás s nima prožít všechno pěkně na 100%. Byl to od nich projev ohromné důvěry a zároveň sebejistoty. Zní to pateticky, ale jsem dojatej a vděčnej. Na jejich místě bych hodně váhal, jestli tam Keboola má bejt. Díky Jardo, ZD, Martine...! 

Celý "offsite" byla kombinace business témat, low-level přednášek, sportu a notné dávky C₂H₅OH :). Sebou jsme si navrch vzali našeho VP of Propaganda Tomáše Čupra a Petra Bartoše. S Tomášem jsem hned po ránu vyvinul ochranu před příjmem těch nejcitlivějších informací. Uvažujem, že si to patentujem!

Nicméně kafe nás nakonec nakoplo :) Tomáš si tam v podvečer střihnul prezentaci o tom, jak používá v DámeJídlo GoodData. Bylo to plný necenzurovanejch čísel, myšlenek a "lidskýho" pohledu na věc. Posléze jsem na to slyšel hodně pozitivní feedback. 

Já měl v plánu se podělit o to, jak v Keboole používáme GoodData, co nás fascinuje a kde nám to naopak drhne. Moc mi to myslím nevyšlo - ZDho dotazy protáhly Tomášovu prezentaci asi na hodinu a když jsem šel na řadu, bylo po půl osmý večer, všichni měli v očích únavu a hlad + Jarda Gergič takovej zvláštní zoufalej výraz. Vsugeroval jsem si 100% nezájem publika a ve snaze všechno co nejvíc zkrátit, nedávalo podle mě nic moc smysl. 

"AZ Kvíz" o trička... (je blbě, opraveno v komentářích :)

Moje klíčová myšlenka: MAQL, resp. AQE, je vaše rodinný zlato a API je to co nám jeho hodnotu pomáhá dostat lidem do života. Dál hlavně rozvíjejte a dokumentujte API a teprve nad ním kódujte svoje UI, tím nám posunete možnosti jak stavět věci, kterým GoodData tepe v hrudi.

Howg

P.S. Tohle jsem si předem "koupil" od Káči. Za 18,- Kč (zmrzlina) byla ochotná sedět 1/2 hodiny na kuchyňský lince a natočit mi pozdravení. Zbožňuju zneužívání dětí :-)

V Keboole se potkáváme se spoustou firem, které se musí (obrazně řečeno) svléknout do naha, abysme jim mohli pomoct s jejich daty. Pokud na začátku nepochopíme princip na jakém zákazník vydělává peníze, je zbytek naší práce na tenkém ledě. Tímhle způsobem se dostáváme ke spoustě podnikatelských "příběhů".

Nedávno jsem narazil na The Paradigm Project, který se zabývá prodejem kamen do Afriky. Ve skutečnosti jde o kamna na vaření - takže spíš sporáky - ale "kamna v Africe" zní trošku šílenějc :) Podstatné na tom sporáku je, že je na dřevo a je hodně účinný.

Proč v Africe někdo kupuje právě tyhle sporáky? Odpověď je jednoduchá: pokud je sporák účinný, spotřebuje méně dřeva, takže kdo na něm vaří, tráví méně času sbíráním klacků. Účinný sporák šetří čas (peníze) při obstarávání paliva, produkuje méně splodin (meně respiračních problémů = lepší zdraví = peníze) a snižuje počet pokácených stromů.

Dobročinný projekt z kategorie "stavíme školu pro děti"? To si ale neřekli lidi co to tlačí dopředu a vymysleli kolem toho super business model. 

Dobře fungující sporák má menší splodiny než otevřený oheň. Pokud si to necháte spočítat a auditovat, můžete prohlásit, že vaše aktivita snižuje emise CO₂ a tím začít generovat karbonové ofsety. Tyhle offsety se dají prodat firmám, které produkují nadměrné množství emisí. Je to docela bizzare business, kolem kterého se točí nejvyfešákovanější konzultanti typu PwC. Mrkněte se na téma "carbon asset management". Existují docela úchylný negativní příklady, kdy třeba čínská firma vyrábějící chladiva vygenerovala $500M v carbon offsetech tím, že instalovala spalovací zařízení za $5M. Takhle velký profit vede k rozšiřování továren jen za účelem generování offsetů, což podrejvá celej systém a trochu to vypadá jako nápad z českýho parlamentu :-)

Naštěstí Africký offsety tímhle moc netrpí. The Paradigm Project sporáky prodává hodně levně (pár dolarů), má síť obchodníků, kteří používají CRM systém komunikující přes SMSky (Afrika = mizerná infrastruktura), prodej pod cenou kompenzuje příjem z offsetů a dotacema od veřejnosti (víc o modelu).

Osobně se mi to moc líbí! Máte nějaký tipy na jiné business modely, které nejsou úplně běžné a prvoplánovité?

• Tady je možné přispět: http://theparadigmproject.org/invest-in-a-project/
• Tady jsou videa o "Woodwalk"pochodu s 25kg dřeva na zádech: http://theparadigmproject.net/videos/1713658/0

"The Stoveman" trailer:

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 :-)

Poslední 2 měsíce jsem v jednom kole. Všem kolem sebe něco jen slibuju a nic moc nedoručuju. Ostuda! :) Začátkem léta jsme stihli dát Tereze poslední povinnou injekci a den na to odjeli na celé léto do Kanady. Otevřeli jsme tu v říjnu 2012 druhý Keboola kancl a tohle byla moje první příležitost, vidět jak to tam šlape.

Samotná cesta byla docela v pohodě, obě děti jsou megatrpělivý a maj za to můj obdiv. Já bych nás na jejich místě zabil :)

Jet lag po příletu byl o fous horší, když spalo jedno dítě, nespalo druhý, když jsme chtěli jít ven, chtěly holky spát a obráceně. Rozsynchronizovaný jsme byli snad týden. Docela by mě zajímalo, jestli na podobný situace nejsou nějaký funkční triky. Oproti dřívějším návštěvám tu moc nestíháme cestovat, já jsem přes den v práci a holky někde na hřišti. Snad ještě ukrouhneme nějaký volný dny... 

2 markantní rozdíly oproti Praze:

Chodím do kanclu pěšky a mám to doslova 5 minut. Denně tím ušetřím skoro 2 hodiny času, což je znát. Přijde mi, že jsme jako rodina pohromadě 2x tolik co v ČR, přitom ale odbavuju snad i o fous víc věcí než doma. Chci bydlet pár minut pěšky od práce!

Cejtim se tu víc odpočatej. Přikládám to čistýmu vzduchu a správnýmu klimatu. Mám tendenci říct, že by tu v práci přes den ani Vojta nepospával :-) Až na jedinou situaci, kdy Marcus usnul v sedě u kompu, nevidím lidi kolem sebe dělat takový ty zheblý gesta. Chci bydlet v čistým prostředí!

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

Mapování okolí patří mezi základní lidské potřeby. Co je zmapované, působí bezpečně. Mapa nám popisuje souvislosti světa, který nás obklopuje, bez mapy nejde najít cestu v neznámém prostředí. Mapa je life-saver!

BC

Mapy se ryly do kamene, uhlem do vydělané kůže nebo třeba později kreslili tuší do papyru. Díky mapám se dokážeme orientovat v prostředí, ve kterém se pohybujeme. 

Potřeba mapovat okolí byla v lidech od pradávna. Pokud nebylo možné mapu nakreslit, hledali jiné formy, jak ji zaznamenat. 

Úplně nejstarší snahu zmapovat svět jsem našel u australských domorodců, kteří přišli z Afriky do Asie kolem roku 70.000 před Kristem a z Asie pak do Austrálie kolem roku 50.000 před Kristem. Aboriginals věřili, že svět byl na počátku plochý. Tuto dobu nazývali "sněním". Podle nich se v této ploché krajině začali vynořovat mýtické bytosti, které dovedli krajinu přeměňovat zpěvem. Písně formovaly prostředí a daly vzniknout dnešní podobě světa. 

Mýty byly pro domorodce inspirací; sami začali písně používat k orientaci v krajině, písně byly jejich mapou. Zpívali o krajině, o tom kde je voda, bažina, údolí - ve slokách popisovali cestu. Zpěvem vytyčené cesty nazývali "songlines". Pokud někdo chtěl jít přes sedmero kopců a sedmero údolí, stačilo se našrotit 4 denní písničku a pak ji precizně za pochodu zpívat :)

AD

Zakreslené mapy byly dlouhou dobu hodně srandovní. Většinou je dělal nějaký umělec, který prostě nakreslil, co viděl. Taková mapa nebyla úplně vhodná k seriózní orientaci, a kdo se na ni spolehl, často se ztratil a nikdy ho už nikdo neviděl.

Změna přišla ve Francii po roce 1663 za vlády Ludvíka XIV. 

Francie v té době byla rozdělena na spousty regionů, které měly každý vlastní dialekt a samosprávu. Ludvík XIV. tehdy rozjel úctyhodný projekt - zmapovat celou zemi. 

Na tento nelehký úkol najal může jménem César-François Cassini de Thury. Cassini byl první, kdo při kreslení map uplatnil znalosti z astronomie a hlavně dovedl správně změřit zeměpisnou délku. 19 let pak trvalo, než Cassini se svým týmem zakreslil přesný tvar francouzského pobřeží. 

Když byly hranice Francie hotové a ukázali je králi, byl zděšen! Francie podle Cassiniho měla dramaticky jiný tvar pobřeží a byla o 20% menší než na všech předchozích mapách. Nicméně Cassini pracoval ve francouzské akademii věd a jeho mapa byla opravdu pečlivě zpracovaná. Ludvík ji právem považoval za to nejlepší, co může mít.

Když bylo hotové pobřeží, pustil se Cassini do mapování vnitřního území. Jediná tehdy dostupná metoda jak sestavit mapu, byla triangulace. Cassini celou zemi rozdělil na malé trojúhelníky, jejichž základny přesně změřili 4m pravítkem a zbylá ramena dopočítali přes úhly spolu svírající.  

Při měření základny každého trojúhelníku bylo nutné srovnat povrch do absolutní roviny. Byla to mravenčí práce! Obrovská ambice, která ale transformovala celou zemi. 

Do té doby byla Francie kolekcí regionů s vlastní identitou, stovky dialektů, lokálních zájmů, aj. Mapováním se tyhle regiony dávaly pomalu dohromady na jednu mapu. Práci na mapě oddali svoje životy 4 generace rodiny Cassiniů. Hotovo to měli v roce 1789, za vlády Ludvíka XVI. Celá práce trvala 126 let!

Mapa byla revolučním počinem. Všechny listy mapy měly jednotné symboly, popisky, jazyk pařížské francouzštiny - vše bylo standardizováno, napříč celou mapou. Byla to mapa pro Krále! Mapa, která centralizovala podobu Francie a umožnila mnoho různých regionů spojit do jednoho obrazu francouzského národa. Lidé se mohli identifikovat skrz jednu mapu - poprvé se tak umocnila jejich identita.

Po revoluci byla mapa základem pro administrativní změny Francie. Na základě Cassiniho mapy vznikly nové administrativní regiony, které jsou používané dodnes.

Mapy provázejí lidstvo po desítky tisíc let. Neobejde se bez nich jakékoliv plánování či strategické rozhodování. 

"Happy Mapping", ať už to bude o čemkoliv!

Legenda:

• mapované území = firma
• regiony s vlastní identitou = finance o patro nahoře, IT ve sklepě, sales ve vedlejší budově
• mapa = GoodData dashboard
• orientace v prostoru = BI

A teď si to přečteme ještě jednou v novém kontextu :)

(fotky: wikipedia a creative common z http://www.flickr.com/photos/wien/5907435455/)