Tohle si sem odložím na památku - dneska ve ~2:00AM se v interní telemetrii Keboola Connection "oficiálně" objevily první 2 operace proti Snowflake.net backendu.
V létě 2013 jsme podobné nadšení s Najlošem zažívali při hrátkách s AWS Redshiftem. Snowflake je ale koncepčně o řádný kus před čímkoliv na trhu.
Jsem zvědavej, jak rychle to objeví místní tech scéna :)
Moje únorové "top" highlighty v pracovním prostředí, bez zpráv o nových klientech.
Zahájili jsme kolonizaci velmi potenciálního regionu - od února funguje "Keboola Singapore Pte Ltd.”. Ještě tak 5~6 kanclů po světě a plány na globální gauč-surfing ve vlastních kancelářích je hotov! :) Náš "asijský startup" vede Jana Žižková, která má BI (a data obecně) v genech. Doteď nechápu, jak se nám povedlo ji zaujmout a nadchnout pro naše plány. Jsem pyšnej! V Singapuru stavíme plnohodnotnou údernou jednotku - kdyby měl někdo zájem dát si v Praze 3~4 měsíční trénink a v průběhu něj se kvalifikovat na přesun do Singapuru, hlašte se na petr@keboola.com. Zajímají nás jen chytrý lidi, co tam chtějí jít na delší dobu >18 měsíců (žádná letní dovolená).
Dali jsme se dohromady s excelentním Tableau partnerem, firmou Billigence. Jejich domovská krajina je Austrálie, kde sídlí na adrese "10 Help Street, Sydney" - což je nejvíc top ulice, když chcete dát najevo, že jsou vaši zákazníci to nejdůležitější, co máte :) Pro Billigence slouží Keboola Connection jako Data framework, DWH a staging layer pro cloudové zdroje dat určených k analýze. Pro nás je podobný vztah doslova požehnáním, protože není nikdo lepší, kdo by nám dal správný feedback na naše konektory pro Tableau.
Spustili jsme další transformační backend v jazyce R. Bez nadsázky se dá říct, že každý zajímavý algoritmus má svojí reprezentaci v R. A jelikož je R jedním z nejrozšířenějších statistických nástrojů, nemohl dlouhodobě chybět. Možnosti, které to našim klientům dává, jsou téměř nekonečné. Rád teď leaknu, že připravujeme podporu Shiny frameworku, ve kterém běží hodně mocné aplikace pracující s daty. Samozřejmě máme před sebou ještě velké zlepšování okolní "R infrastruktury", ale věřím, že udržíme tempo! Tady proběhlo naše oficiální oznámení. UPDATE: Dal to dohromady Najloš, kterej se možná cejtí fakt uraženej, že jsem na něj jakoby zapoměl. Taky mu myslím s R pomáhal Odin, kterej se zatím uraženej asi necejtí, ale radši to sem napíšu. Teď jako čekám smršť potenciálně ukřivděnejch lidí, tak sem nalinkuju http://padak.keboola.com/dalsi-rok-za-mnou kde píšu že jsou všichni super. Snad to stačí :-)
3rd party app - náš transformační backend s R běží v Dockeru. Tady je náš Docker Hub a tady jsou zdrojáky našeho “demo dockeru” - a když už to takhle máme, je nasnadě, aby nám kdokoliv třetí dodal svojí “aplikaci / business nástroje” stejným způsobem. Mimochodem, Microsoft spustil Docker v Azure před pár dny do public beta a Amazon to rozjíždí v AWS jako Elastic Container Service, zatímco CoreOS řekl, že to je crap, a jede si svůj vlastní kontejner. No a u nás máme první dvě vlašťovky našich 3rd Docker aplikací: Yottly.com a Geneea.com. Yottly za náma poslal Vojta Roček - soustředí se na využití machine learning nástrojů v ecommerce. Geneea.com jsou zase experti na Natural language processing - tedy schopnost strojově popsat význam textu. Pro lepší představu co umí "stroje ovládající NLP" si pusťte AlchemyAPI demo - ve výsledcích si klikněte na “Relations” a pak na nějakou vybranou větu. Čeho všeho jde s pomocí NLP v našem prostředí docílit je totální úlet! Takové nejlépe dostupné API pro NLP jsou již zmíněné AlchemyAPI, Semantria a nebo IDOLonDemand (jádro HP Autonomy).
Erik zmigroval naší klíčovou komponentu (Orchestrátor) do kompletně asynchronního režimu. Trvalo nám to věčnost, ale proběhlo to téměř bez problémů a teď díky backendu v Elasticsearch můžeme začít dělat věci jako “notifikuj mě, pokud nějaký job běží o 20% déle, než je průměr za posledních 30 spuštění”.
Když už o tom píšu - hodil by se nám na občasné konzultace někdo, kdo má zkušenosti s Elasticsearch - potřebujeme rady, abysme neimplementovali nějaké anti-patterny. Elasticsearch sám nabízí pouze support od 20kEUR na rok, což je pro nás lehce overkill...
Po skoro 3 měsíční pauze jsme obnovili testování Snowflake.net, který se chystáme zapojit jako další backend na uložení dat. Snowflake je naprostý úlet co se týče výkonu. Poslední, co nám zbývalo otestovat, jsou věci jako monitoring, provisioning, apod. 3 měsíce jsme čekali na nějaké dodělávky od Snowflake - teď je to hotové a já napjatě čekám, co z toho bude :)
Odin vykopnul K-Means segmentaci jako “Recept" běžící v Keboola Connection. Nejlepší popis K-Means, co jsem v poslední době našel, je tady. Pomocí K-Means můžete automaticky najít segmenty v datech, které od nás dostanete jako "další sloupeček", a k němu nákresy binárních stromů, abyste si mohli udělat představu, jak "stroj" k segmentu došel.
Marc udělal “Recept”, který dělá analýzu nákupního košíku. Řekne vám to, že když je v košíku tlačenka, bude tam z 73% i pivo a že se tahle kombinace vyskytuje v 64% všech objednávek, apod. Úplně se nabízí zkoumat profit těchle kombinací a případně je nabízet společně “v akci”. Případně řešit, jestli pochopíme návyky skupiny lidí, co si kupují tlačenku bez piva, apod.
Milan domluvil se Zendeskem zapnutí Zendesk Insights (jo, jako správný socky si platíme nejlevnější tarif, ve kterém to normálně není :) - a tak jsem skočil do GoodData projektu se Zendesk datama a podíval se, jak na tom jsem. Od zavedení Zendesku jsem hlavní jouda L1 support týmu. Brutálně mě to 2. rokem otravuje, ale fakt, že každý ticket dostanu do mobilu a zároveň jich velkou část přímo odbavím, mě udržuje ve stavu, kdy mě nejde interně nabullshitovat, jak je něco super cool, zatímco nám zákazníci píšou, jaký s tím maj problémy. Je mi jasný, že to trvale nepůjde, ale doufám, že to vydržím dělat co nejdýl! Přísné tempo, kdy jsem prvních 6 měsíců zavíral skoro 60% všech ticketů, je dávno pryč, nicméně posledního 1/2 roku útočím na 40%, což je pořád dost a jsem na to pyšnej :)
Naše kanadská parta se hodně angažuje v ekosystému Zendesk.com. Velkou roli v tom hraje náš “školící" produkt Keboola Academy. Tady a tady Zendesk probírá, jak důležité je se daty kolem “customer care” zaobírat.
Pavel Doležal je na tripu po US a mimo jiné zašel na Tableau Konferenci.
Tableau 9 server je úplně jiný svět, má své specifické zákazníky, myslím že se to super doplňuje s GoodData. Oznámené novinky jsou nicméně hodně přísné - do detailů se nepustím a raději to nechám někomu fundovanějšímu :)
GoodData získala zlato za "best Customer Support Department of the Year" - je to určitě zasloužené. Jejich support je opravdu skvělý! Velké gratulace a respekt - určitě to nebylo zadarmo!
Moje lednové "top" highlighty v pracovním prostředí (že Tereza řekla včera ráno smysluplnou větu sem asi dávat nebudu, co? :)
Briskat.com Hynek Vychodil a Vladimír Makovský spustili interaktivní analytickou databázi MIA DB, která vypadá hodně perspektivně. Tady je demo a tady blogují. Hynek a Vladimír mají solidní track record na poli DB backendů a práce s datama. Jsem na to moc zvědavej a mohutně držím palce!
Vertica se konečně přesunula do cloudu jako "Vertica on demand". Od ledna je možné si pronajmout tuhle analytickou databázi přímo od HP. Vertica mi tu figuruje ve dvou postech (první, druhý) a speciálně komentáře pod tím prvním stojí za pozornost.
KBC stats - za leden 2015 k nám přiteklo v 1.19M requestech 3.94TB dat.
Keboola London - v tichosti “otevíráme” UK trh a prostřednictvím Martina Lepky máme od února full-time prezenci v Londýně.
GoodData “Insights as a Service” - masivně oznámená novinka, co mi zaplavila všechny kanály. Jsem zvědavej, jak to bude dál - od spousty super věcí časem ztratili záběr (JS API třeba). Pokud “analytický designer” budou držet na špici, vydají nějaký popis metadat, aby mohl kdokoliv definovat “co” se dá s daty dělat a propojí ho víc se zbytkem GoodData, bude to super. Vypadá to velmi slibně, byť mě “air wars marketing” trochu tahá za uši :) Zároveň se obávám jedný věci - že potenciální odklon od MAQL vezme GoodData to co je na nich dobrý - za okny totiž číhá svět plný těhle tahacích klikátek, kde právě absence "AQE" z nich dělá hračky pro šašky. Držím palce a těším se na to!
Medio Interactive naskočilo na naší 'juchůů' vlnu a pustilo se do pokročilých analýz. My jim po pečlivém zaučení dáváme statut “Keboola Certified Partner”.
Tady je k vidění záznam z jejich prvního webináře, vedeného Honzou Tichým. Časem ho snad přemluvím k rozhovoru, celebritu jednu! :-) Medio je, mimochodem, jediná schůdná cesta jak se u nás dostat ke Google AdWords datům, pokud nemáte vlastní Google Developer Token!
Breezy začalo programovat komponenty do Keboola Connection! Seznámili jsme se s nima jako s partou co technicky stála za projektem Gorila Mobil. Dneska pro naši platformu dělají konvertor z Excelu do CSV, extraktor z iTunes a podle posledních informací je uhání Vojta Roček z Rockaway, aby pro ně udělali nástroj na zpracování mandatorních filtrů do GoodData. Breezy k nám dává svoje aplikace zapouzdřené v Docker.com a pokud to klapne jak má, budeme z nich mít prvního “Keboola Certified Developer”!
Microsoft Power BI (http://www.powerbi.com/) je od konce ledna k dispozici zadarmo. Co nám to na Enterprise Data Hackathonu ukazovali kluci z Bits2s Intelligent Technologies, vypadá to hodně dobře. Myslím že to má potenciál zahýbat s trhem, zvlášť při integraci s MS Azure, kde je dost pěkných nástrojů na zpracování dat (Azure Machine Learning, např.).
UPDATE: Tak PowerBI ještě chvilku kartama míchat asi nebude :-)
Keboola Meetup - proběhl náš první MeetUp pro zákazníky. Brzo budou fotky a videa! Klobouk dolů před lidma co tam vystoupili a pustili nás všechny do svých obyváků. Například papírnictví McPen, projekt našeho partnera Ascoria.cz, tam naživo ukázal svoje dashboardy, všechny čísla, apod. Respekt!
Na wiki.keboola.com od začátku roku veřejně dumpujeme poznámky, návody, postřehy a dokumentaci. Teším se až tam začnou sypat non-Keboola lidi svoje znalosti!
Wishlist zapli jsme veřejný Trello board, ve kterém může kdokoliv hlasovat pro návrhy, co máme dodělat. Je to ideální studnice inspirace pro naší konkurenci :) a cesta jak naši zákazníci natlačí vývojářům vlastní potřeby/představ. Popsané je to na našem "Statusu".
Partneři nám přebírají klienty - na tohle jsem čekal 2 roky! Je to signál živého a fungujícího ekosystému. Doufám ve víc podobných situací - je jasné že my sami budeme nejlepší primárně v podpoře našeho "data frameworku” Keboola Connection a koncovou péči o zákazníka, včetně vysoké vertikální znalosti, musí převzít někdo lepší než jsme my.
Docker se zabydluje v Keboole - což znamená že kdokoliv může svojí business logiku (machine learning algoritmy, R aplikace, apod.) zabalit a nechat nad datama našich klientů monetizovat. Do budoucna budeme nejlepší místo na vydělávání peněz pomocí chytrých aplikací. Něco jako podtitulek Enterprise Data Hackathonu "Real data, from real enterprises, great tools, lots of fun!”. Zbývá dotáhnout jak propojit našeho klienta a 3rd aplikaci a značně vylepšit naší schopnost datům automaticky porozumět (<<HR okénko!). #realData #realMoney
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!
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.
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...
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.
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"
}
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:
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.
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
Nad daty se provádí 2 testy:
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 je soupis přesných SQL příkazů a časů: https://s3.amazonaws.com/padak-share/blog/redshift.sql)
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);
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);
./bq mk rad.randomData
--0s
./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)
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)
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)
Read 50000001 rows from file and successfully inserted 50.000.000 rows (final)
Elapsed time: 1735.586 secondsSELECT
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
-- 330 ms
voltdb compile -o random.jar random.sql
voltdb create catalog random.jar
csvloader randomdata -f randomData10.csv --skip 1
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;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,068sSELECT
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
Č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
Honza Winkler udělal Test A a B na Postresu (9.3.4). Detaily jsou tady: http://goo.gl/xt3qZM
Dodatečně jsem udělal ještě test v MySQL. Server má 64GB RAM, SSD disky...
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:
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
Máme tu v Praze jednu hodně perspektivní partu, která zatím uniká pozornosti médií. Loni v prosinci mě s nima na “šunkovým” mejdanu seznámil Eda z Avastu. Říkal, že mu je někdo z Wayra dost chaoticky pitchnul jako partu, co optimalizuje SQL dotazy (což není pravda).
Včera odpoledne pod taktovkou Felipe Hoffa proběhl workshop na téma “Google BigQuery”. Sešlo se tam asi 15 lidí, které na CZ trhu BigQuery láká. Felipe, jako Google Developer Advocate stručně proskákal historii zpracování velkých dat v Google - počínaje MapReduce v roce 2004, přes white paper Dremelu, konče dnešním BigQuery.
SELECT a.departure_state, b.departure_state, corr(a.avg, b.avg) corr, COUNT(*) c FROM (SELECT date, departure_state, AVG(departure_delay) avg , COUNT(*) c FROM [bigquery-samples:airline_ontime_data.flights] WHERE departure_state = 'NY' GROUP BY 1,2 HAVING c > 5 ) a JOIN (SELECT DATE(DATE_ADD(timestamp(date), 1, 'DAY')) date, departure_state , AVG(departure_delay) avg, COUNT(*) c FROM [bigquery-samples:airline_ontime_data.flights] GROUP BY 1,2 HAVING c > 5 ) b ON a.date=b.date GROUP EACH BY 1, 2 HAVING c > 5 ORDER BY corr DESC;
SELECT Year, Actor1Name, Actor2Name, c FROM (SELECT Actor1Name, Actor2Name, Year, COUNT(*) c, RANK() OVER(PARTITION BY YEAR ORDER BY c DESC) rank FROM (SELECT REGEXP_REPLACE(Actor1Name, "CZECH REPUBLIC", "CZECH") Actor1Name, REGEXP_REPLACE(Actor2Name, "CZECH REPUBLIC", "CZECH") Actor2Name, Year FROM [gdelt-bq:full.events] WHERE Actor1Name < Actor2Name), (SELECT REGEXP_REPLACE(Actor2Name, "CZECH REPUBLIC", "CZECH") Actor1Name, REGEXP_REPLACE(Actor1Name, "CZECH REPUBLIC", "CZECH") Actor2Name, Year FROM [gdelt-bq:full.events] WHERE Actor1Name > Actor2Name), WHERE Actor1Name IS NOT null AND Actor2Name IS NOT null AND (REGEXP_MATCH(Actor1Name+Actor2Name, 'CZECH')) AND Actor1Name != Actor2Name GROUP EACH BY 1, 2, 3 HAVING c > 100) WHERE rank=1 ORDER BY Year;
Na závěr se nejaktivnější účastníci z Netmailu vyfotili
a rozproudila se diskuse. V podvečer měl pak Felipe přednášku na FELu. Na to, že akorát přiletěl a měl jetlag, je dost hustej! :-)
Amazon Kinesis je služba v rámci Amazon Web Services (AWS), která umožňuje zpracování jakýchkoliv dat v reálném čase. Aktuálně běží v neveřejném režimu a přístup k ní se schvaluje žádost po žádosti (moje žádost trvala asi 2 dny).
K čemu to je?
Zatím to zkoumám, ale nevypadá to jako něco moc revolučního. V podstatě jde o to, že Kinesis pro nás provozuje frontu na data, do které může padat cokoliv odkudkoliv a jakoukoliv rychlostí. My si musíme napsat aplikaci, která si z fronty data bere, něco s nima dělá a vrací je na výstupu (třeba zase do jiné Kinesis fronty). Kinesis samotný s psaním aplikací na zpracování dat nijak moc nepomáhá. K dispozici je SDK pro Kinesis - tedy obalené funkce typu GetNextRecords.
A konkrétní příklady?
Kolik to stojí?
Kinesis se, stejně jako všechno ostatní v AWS, platí po hodině provozu za provozní jednotku (shard). Jeden shard zvládne přijímat data rychlostí 1MB/sekundu a odesílat rychlostí 2MB/sekundu. Aktuálním limitem na jeden vložený datový objekt je 50kB. Text tohohle blogpostu by jeden "shard" zvládl přijmout zhruba 500x/sekundu. Cena ze tenhle nejmenší "shard" je $0.015 za hodinu. Další a poslední cena je za vkládající operace. Jeden milion vložení (přijetí) datových objektů stojí $0.028.
Když bych zůstal u objemu tohohle blogpostu a řekl, že má 3.5kB, pak kdyby chodil do Kinesis takovýhle text 300x/sekundu celý měsíc, stálo by to:
Suma sumárum
Největší přidanou hodnotou je tedy hlavně držení streamu dat, o který se nemusíme starat. Bude to možná poměrně konkurence pro Pusher. Pro Keboola Connection je to hlavně příležitost - de-facto na podobném principu dávno fungujeme a Kinesis nám může pomoct "zpevnit základy".
Znovu se tedy potvrzuje to co jsem psal na konci staršího blogpostu - nejenom díky Kinesis si můžeme troufnout na náročnější projekty a cítit se v Cloudu silnější.
K vidění na Kinesis zatím moc není, tady je promo video a odkazy na dokumentaci. Přikládám screenshoty z aktuální Management Console.
Problém?
Cloud - nejvíc nebezpečná věc, zvlášť tady v čechách!
Tohle téma si schovávám od půlky května. Bacha, TL;DR :)
Na Facebooku proběhl post Radka Hulána:
"O data v cloudu se typicky starají lidé s mnohem lepšími znalostmi než váš lokální admin (včetně důrazu na zabezpečení) a jsou k dispozici 24/7. Pro menší firmy nedává dle mého vůbec smysl mít vlastní servery, licence, administrace, pokud daná věc existuje jako cloudová služba…"
(pro datové archeology přidám ještě link na zálohu)
Pod postem se rozhořela klasická česká diskuse. Pár výcuců:
Základní doporučení je samozřejmě nevlastnit žádný počítače, protože pak se nemusím trápit myšlenkou, jestli není v řadiči sběrnice nějakej odposlechovej software. Taky je dobrý nemít umělý koleno, protože to má určitě výrobní číslo, který je v cloudu na nebezpečným úložišti - což radikálně ohrožuje moji svobodu a tím pádem i bezpečí… :)
"Cloud" je skloňované slovo ve všech médiích. Podobně jako BigData. Evidentně polarizuje společnost na 2 skupiny. Češi si myslí, že v Cloudu o svoje data během mžiku přijdou. Řiká se, že každej čech je odborníkem na fotbal a marketing, podle projevů na internetu jsme všichni experti na cloud a IT bezpečnost. Když se to zkombinuje s tím, že si všechno uděláme nejlíp sami, nastane pekelná kombinace.
O čem je vlastně řeč?
Český paradox - obava z dostupnosti
Český paradox - obava z bezpečí dat
Co cizina?
NASA říká, že by bez Identity Managementu (AWS IAM) v Cloudu neuřídila přístup k datům, který generují roboti na Marsu, Pfizer do Cloudu přenáší výzkum léků, NASDAQ tam analyzuje burzovní data, Obama na něm postavil svoji první prezidentskou kampaň a letiště v Norimbergu v Cloudu provozuje portál obsahující osobní data svých zákazníků. Seznam pár "AWS" případových studií je tady (důležité je říct, že Amazon AWS není jediný Cloud provider, vybral jsem si ho jen jako osobně nejbližšího zástupce)
Long story short…
Problém bude vždycky v lidech. Pokud provozujete problematickou webovou aplikaci, ke které se má někdo připojit online, budou vaše data stejně špatně chráněná v interní serverovně jako v Cloudu. Pokud s tím budete ale něco chtít dělat, bude v Cloudu mnohem rychlejší postavit kaskádu firewallů, demilitarizovanou zónu a zapojit systém aktivní kontroly průniku. Všechno tohle dává práci šikovným lidem a bere ji lemplům. Nevím, jestli to je nebo není tím pravým důvodem, proč v čechách lidi tolik křičí, když na Cloud přijde řeč…
Kdo dočetl až sem, může hodit oko na stručný seznam služeb, které používáme v Keboole: http://padak.keboola.com/cloud-vyhazujeme-penize-oknem
UPDATE 22.10.2013: Americká armáda přechází na Google Apps s 50 000 lidmi - link.
