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