Keboola transformace – v hlavní roli proměnné | Mňamka #432

V BizzTreatu se staráme o jeden parádní projekt, který musíme udržovat téměř identický pro více regionálních mutací. Jádro nápočtů tak zůstává stejné, ale občas se liší důležité parametry, které jsou specifické pro danou zemi. Jak to řešíme? Od hardcodění jsme se přesunuli k hojnému využívání proměnných, které nám dodávají potřebný manipulační prostor a zároveň nám usnadňují správu kódu.

Proměnné v Keboole

Při práci v SQL transformacích v Keboole můžeme narazit na dva typy proměnných - ty keboolácké a ty snowflakové. Pojďme se na ně podívat.

Keboola proměnné

Proměnné definované v části předcházejícím bloku transformací nejsou vázané na kód transformací samotný. V praxi to znamená, že se nechovají přesně jako proměnné SQL nebo Pythonu - transformační proměnné jsou vyhodnoceny a definovány už před spuštěním transformace a jsou platné pro celou dobu běhu jobu dané konfigurace.

Pro zápis využívají moustache variable syntax a definují se v bloku “Variables” předcházejícím script samotný a následně se v kódu vkládá název proměnné do dvojitých složených závorek . Více v Keboola dokumentaci.

Samozřejmě záleží, jakou hodnotu potřebujete vložit do proměnné, ale odpovídá to běžné SQL syntaxi - stringy v jednoduchých uvozovkách, integery bez, pokud potřebujete vložit seznam hodnot, tak se vkládá jako [value1,value2] (tj. bez jednoduchých uvozovek a mezer).

Snowflake proměnné

Tento druhý typ proměnných se definuje přímo v kódu a díky tomu také zůstává jeho součástí a platí po dobu celého jobu, kdy běží transformace. Best practice je nadefinovat si je na začátku kódu, ideálně, pokud je využíváte napříč celým Keboola projektem, tak využít i shared code. Takto definované proměnné se pak v kódu používají předsazené znakem dolaru $ .

Co, kdy a jak používat?

Pro co nejpohodlnější vývoj je ideální použít kombinaci zmíněných proměnných. Pokud si totiž nejdřív nadefinujete Keboola proměnné v záhlaví transformací a pak hned v úvodním bloku si je převedete na Snowflake proměnné, tak při zkopírování celé transformace do vývojového workspace stačí vyplnit hodnoty proměnných pouze na jednom místě, a ne na všech možných i nemožných místech, kam jste v rámci vývoje danou proměnnou umístili. Je to funkční, praktické a elegantní.

Jak na to krok za krokem?

  1. definovat proměnné v KBC transformaci (tj. v části “Variables”)
  2. pomocí SET přiřadit hodnotu Keboola proměnné Snowflake proměnné
  3. používat Snowflake proměnnou v kódu

Nic ovšem není dokonalé - proměnné ve Snowflake jsou limitované. Jak praví Snowflake dokumentace - maximální velikost proměnné je limitována na 256 bytes. Pokud tedy potřebujete využít proměnné delší než 256 bytes, tak musíte zůstat u KBC proměnných, které omezené nejsou.

Tím se pak snadno můžete dostat do situace, kdy v KBC budete mít jako proměnnou definovaný dlouhý seznam hodnot. Co s tím pak ve Snowflake?

  1. KBC proměnnou definovat jako seznam v hranatých závorkách, bez uvozovek kolem hodnot, bez mezer, pouze oddělit čárkami

</> paid_subscription_type ([ value1,value2,value3,value4,value5 ])

  1. na začátku kódu definovat SQL proměnnou pomocí SET

SET paid_subscription_type = ''

  1. v kódu je pak nutné parsovat pomocí:

(SELECT VALUE FROM TABLE(FLATTEN(INPUT => PARSE_JSON($paid_subscription_type))))

Podrobný návod pak najdete na Snowflake forum.

Tak, a to je celé. Pokud máte projekt takto pěkně uklizený, tak pak už není problém dosadit do připravené struktury nové proměnné unikátní pro sesterský projekt a ušetřený čas můžete strávit třeba u kafe. ;)

Máte k článku nějaké otázky nebo připomínky? Klidně nám napište, rádi to s Vámi probereme :-)

Kristýna Jaško
datový detektiv
LinkedIn

Základní pojmy v datovém modelování | Mňamka #457

Základní pojmy v datovém modelování | Mňamka #457

Co je to datový model? Jaký je rozdíl mezi konceptuálním a logickým modelem? A k čemu slouží proces tzv. normalizace? Bez datového modelování se dnes v BI obejdete už jen stěží, Kuba si o něm proto připravil krátkou minisérii, ve které si vše probereme od úplných základů. V prvním díle se seznámíme s nejdůležitějšími pojmy, které byste v této souvislosti měli znát, a na jednoduchém příkladu z oblasti sales si ukážeme, jak takový datový model vlastně vypadá. Tak pojďme na to!

MAQL II. - MAQL Reuse factů & Nesting metrik | Mňamka #454

MAQL II. - MAQL Reuse factů & Nesting metrik | Mňamka #454

Proč se vyplatí recyklovat metriky v MAQL? Máme tady pokračování naší krátké minisérie o dotazovacím jazyku MAQL od Péti. V minulém díle jsme si osvětlili základní rozdíl mezi SQL a MAQL a dnes se zaměříme na výhody metrik vytvořených pomocí MAQL a jejich recyklaci. Funguje to přitom podobně jako v případě klasické recyklace surovin. Pokud ji dělat nebudete, ušetříte si možná půl minutky práce, v budoucnu se vám to ale může velmi nepříjemně vrátit. Tak se na to pojďte podívat!

Šaty dělají kód aneb Proč je někdy lepší kebab než velbloud | Mňamka #441

Šaty dělají kód aneb Proč je někdy lepší kebab než velbloud | Mňamka #441

I špatný standard může být lepší než žádný standard. Bez toho totiž ve vašem kódu velmi snadno zavládne chaos. V praxi se např. často stává, že lidé halabala kombinují různé druhy uvozovek, míchají malá a velká písmena v pojmenování proměnných nebo se pro jistotu vůbec žádných jmenných konvencí nedrží. Ostatně, Tomáš už se o tom mnohokrát přesvědčil na vlastní pěst. Sepsal pro vás proto mňamku, ve které si připomeneme, proč byste přece jen nějaký standard při psaní kódu mít měli!