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

První!

Přesně 1.4.2013 mi Facebook zrušil léta používanej účet. Ukázalo se, že to není Apríl, ale smutná realita doprovázená arogancí giganta, který mě omlátí o hlavu podmínky použití (četli jste je někdo?) a dál se odmítá o čemkoliv bavit. 

Od teď si budu svůj "deníček" psát tady. Platím $5/měsíčně a naivně věřím, že cash is king a i když si sem dám fotku svýho nahatýho dítěte, tak mi to nikdo nebude cenzurovat! :-)