Digest novinek v Keboola Connection #5

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


Týdenní digest novinek v Keboola Connection #4

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

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


Transformation UI

Tři módy Sandboxu

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

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


Sandbox Credentials

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

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


Transformation API

Tady jen v bodech:

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


Storage API

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


Keboola Academy

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


GoodData Writer 4.0

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

API

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

UI

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

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


Co se jinam nevešlo

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


Konec 

-Petr

Týdenní digest novinek v Keboola Connection #3

Transformation UI

Indexy

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

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


Datové typy

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

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


Input Optional

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

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


Sandbox

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

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


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

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

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


Transformation API

Performance Monitoring

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


Orchestrator 2.0

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

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

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

Účel: Cpt. Obvious :)


Více notifikačních emailů

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

Účel: Cpt. Obvious :)


Keboola Academy

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

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

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


Konec

-Petr


Týdenní digest novinek v Keboola Connection #2

SAPI

On-The-Fly Admin Tokeny

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

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

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

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

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

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

KBC

Orchestrátor 2.0

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


Konec

-Petr

Týdenní digest novinek v Keboola Connection #1

Transformation UI

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

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

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

Výběr sloupců (columns filtering)

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

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

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

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

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

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

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

Editace existujících Input Mappingů

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

Editace SQL dotazu

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

Transformation API - změny co nejsou v UI

Indexy a Datové typy

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

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

Run Mode

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

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

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

Orchestrator (beta)

Informace o časové zóně

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

Editace scheduleru

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

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

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

Hello Syrup

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

Obecný databázový extraktor

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

Konec

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

-Petr