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