Analýza nákupního košíku

Nákupní košík a jeho analýza (anglicky Market Basket Analysis (MBA) - někdy také nazývaná jako “afinitní analýza") je celkem podceňovaná záležitost. Cílem MBA je identifikovat položky (v nákupním košíku), které jsou kupovány společně. V momentě kdy známe kombinace kupovaných produktů, můžeme si na nich spočítat výnos a v případě že mám třeba často kupovaný produkt táhne nákup vysoce maržového produktu, stojí za to začít nabízet tuhle kombinaci společně v bundle za výhodnější cenu. 


Jak to funguje? 

Na vstupu jsou data s transakcema a jejich položkama (můj sample):

1, citrus fruit, semi-finished bread, margarine, ready soups
2, tropical fruit, yogurt, coffee
3, whole milk
4, pip fruit, yogurt, cream cheese, meat spreads
5, other vegetables, whole milk, condensed milk, long life bakery product
6, whole milk, butter, yogurt, rice, abrasive cleaner

Ty přechroustá stroj a vyplivne seznamy kombinací, ze kterých můžeme doporučit cross-sell, přeorganizovat umístění produktů, vymyslet akční balíčky a nebo (za mě trochu haluz) vyladit layout katalogu.

Spousta firem se snaží MBA prodat jako vědu. Nástrojů na to je mnoho. IBM SPSS, SAS, RapidMiner, Weka, iPython nebo třeba Rko

U nás (Keboola Connection) je “Basket Analysis” jako připravený recept. K jeho nastavení stačí určit tabulku obsahující “účtenky" a definovat sloupečky - ID účtenky a ID položky (prodaného produktu). 


Dodatečně chceme zadat ještě segment - což je sloupeček, který může obsahovat cokoliv. Pokud je tam měsíc v roce, bude výstupem analýza košíku pro každý měsíc zvlášť. Pokud je tam region, vypadne z toho tolik “analýz”, kolik je regionů. 

Výstupem je pak tabulka plná pravidel. Příklad jednoho:


Takový řádek říká, že pokud někdo nakoupí máslo a kořenovou zeleninu (sloupec lhs (left hand side)), existuje 66% pravděpodobnost (sloupec confidence), že koupí zároveň i plnotučné mléko (sloupec rhs (right hand side)). Tato kombinace produktů se pak vyskytuje v 0.6% všech nákupních košíků (sloupec support). Třetí metrikou co vypadne z MBA je pak ještě “lift”, což je vyjádření toho jak moc se kombinace produktů kupuje víc spolu než samostatně. 

Jednoduchý příklad zobrazení takových dat bez liftu je pak třeba ve scatter plotu:


Určitě je dobré každý produkt v katalogu obohatit o profit nebo náklady s jeho distribucí či propagací. Pokud se vám povede zároveň i říct jak jsou lidi spokojeni s tím co nakupují (spojit data ze supportu s obchodníma transakcema), máte náhle k dispozici skvělé informace pro cross-selling, rozkročené od marketingu po zákaznickou podporu. 

CSV s testovacíma datama nákupů a CSV s výstupem z Keboola receptu.

SQLdep

Máme tu v Praze jednu hodně perspektivní partu, která zatím uniká pozornosti médií. Loni v prosinci mě s nima na “šunkovým” mejdanu seznámil Eda z Avastu. Říkal, že mu je někdo z Wayra dost chaoticky pitchnul jako partu, co optimalizuje SQL dotazy (což není pravda).


Martin Masařík (vpravo) mi v těžké opilosti popsal co dělá a na první dobrou se trefil do problému, který hrozí v každém našem analytickém projektu. Martin stojí za službou sqldep.com, do které se pošle SQL kód a ona ho celý rozebere, zanalyzuje a vizualizuje. K analytikovi se vrátí vizuální vztahy všech operací v databázi. Zní to trochu jako #firstworldproblem, ale pravda je taková, že podobný nástroj potřebuje každý rozjetější 'data tým'.

Dneska jsou firmy plné různých SQL dotazů, pomocí kterých se analytici dotazují interních databází a vytahují data pro různé reporty. SQL, které vrátí počet zákazníků s produktem “abc” vypadá jednoduše:

SELECT Count(client_id)
FROM   clients
WHERE  product = 'abc';

Problém je v situaci, kdy je SQL dotaz veliký a jeho autor navíc opustil firmu před 4 lety a úpravy v něm máte dělat zrovna vy! Chce-li po vás někdo udělat v podobném dotazu změnu, máte na výběr - buď to budete 2 dny zkoumat nebo použijete SQLdep a změnu uděláte přesně a neomylně tam, kde má být. Je rozdíl, jestli máte k dispozici pouze SQL dotazy nebo interaktivní vizualizaci, ve které vidíte souvislosti a dopady:

Kluci ze SQLdepu mají za sebou implementaci svého nástroje v GE bance a co vím, tak se perspektivně chytají v České spořitelně.

Představím-li si situaci, kdy mi někdo řekne, že se od příštího měsíce změní v datech nějaký sloupec a já mám SQL scripty, které mají tisíce řádků, jdu si to bez SQLdepu asi hodit. S ním je to easy úloha - kliknu na vstupní sloupce a vidím všechny souvislosti a na druhý klik i konkrétní řádky SQL příkazů. Vyjádřeno v ušetřeném čase bankovních data-mining expertů a ve větší bezpečnosti prováděných změn, tečou klukům peníze proudem. Podobné nástroje existují jako přidružené tooly kolem databází samotných, ale často jsou drahé (nekoupíte to každému kdo by to potřeboval), neohrabané nebo třeba něco klíčového nezvládají (pl/sql). Dělat podobnou věc jako online nástroj s API je super. 

P.S. Akorát finišujeme implementaci jejich API do Keboola Connection. Všichni naši zákazníci budou mít SQLdep k dispozici nejpozději od konce června. Rozšíří se tím naše existující vizualizace ETL procesů, takže zjistit kde je potřeba upravit transformace odvozených attributů v GoodData projektu bude úkol z kategorie “trapárna” :-)

Trocha čísel z backendu

Kouk jsem se dneska na to, kolik dat držíme a zpracováváme v Keboola Connection. Nejsou to žádný ultra objemy, ale když si uvědomíme, že jsou to primárně čistý obchodní informace našich klientů (transakce a číselníky), je to docela dost. Nepočítám do toho náma vygenerovaný logy a eventy, popisující provozní parametry, ani zálohy a podobné věci. 

Vzal jsem v úvahu období od začátku minulého měsíce do včerejška, čísla jsou vždy agregovaná za jeden konkrétní nejaktivnější den:

  • Počet operací proti Storage API: 37.689
  • Objem přijatých dat: 26.5 GB
  • Objem odeslaných dat: 33.5 GB
  • Čas strávený obohacováním dat: 1.992.890 sec (23 dní!)

A ještě 3 celkové statistiky k dnešnímu dni:

  • Celkový objem držených (živých) dat: 1.3TB 
  • Počet všech řádků : 6 miliard
  • 5 nejčastějších chyb v API: 
    • nesedící struktura dat při importu od klienta
    • validace obsahu tabulky
    • nepovolený přístup
    • překročený počet povolených indexů
    • cílová tabulka nenalezena

A stupínek vítězů pro technologie, které se na tom podílí?

  1. místo určitě stále zastávají Amazon RDS (MySQL) servery
  2. místo nově zabral Amazon Redshift
  3. místo zabírají (měřeno přes palec) Google BigQuery, HP Vertica + R a Amazon CloudSeach

Minulý týden jsme ale měli "IT party" s Karlem Minaříkem a myslím, že Amazon CloudSearch brzo vystřídá ElasticSearch. V kostech cítím, že v tom leží budoucnost. Tlak na co největší rychlost a JSON všude kam se podíváš - trend je jasnej :-)

HR okénko:

Sháním někoho se zkušeností s AWS Data Pipeline a/nebo AWS SWF. Pokud nikdo takový neexistuje :), hledám nadšence, co si s tím pro Keboolu zaexperimentuje. Kontakt nejlépe v komentářích nebo emailem na petr@keboola.com.


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