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” :-)

9 responses
Jaká je výhoda proti tomu, co nabízí Navicat a podobné nástroje? Primárně v tom, že je to samostatný nástroj a jde s tím pracovat dávkově apod?
U Navicatu znám jen ERD builder. Můžete mě navést, kde tam je třeba právě impact analýza SQL kódu? Jinak asi přesně jak píšete - je to online nástroj zaměřený přesně na tuhle problematiku, proto má potenciál k vysoké adopci ze strany analytiků a databázistů.
> Dělat podobnou věc jako online nástroj s API je super. To si právě nemyslím. Ve většině provozů, se kterými jsem měl tu čest, by bylo odeslání "business logiky" ven hodnoceno jako bezpečnostní incident (jo, sám si myslím, že je to pitomost). Navíc má dost firem drakonické firewally (to občas chápu). Takže pokud to nepůjde používat offline, tak je (podle mne) využití omezené. Ale hračka je to pěkná. A slovo hračka opravdu nemyslím pejorativně.
Rozumím tomu správně tak, že SQLDEP zvizualizuje celé ETL flow? Tzn. nasypu celou sadu skriptů a dostanu ven vizualizaci na úrovni mapování sloupců?
Ondřej: přesně tak, ani se nestaráte o jejich pořadí.
Petr Vaněk: já v tom vidím samé výhody, jak pro ně, tak pro uživatele. Zájem ze stran bank potvrzuje, že sql samotné není to, co se musí tolik chránit.
Dobrej napad s velkym potencialem. Fandim vam!
Pro info -- nabízíme i on-site instalaci pro velké dávky (řádově stovky tisíc řádků kódu a víc). Leč silně preferujeme API. Petr> Šunka party je velmi dobře uložena v mé paměti.. především jak jsem odcházel na poslední metro a šel říct jen 'čau'.. a odjížděl prvním ranním ;) Jirka> Díky!
Ta pani, co mi to tehdy pitchla se jmenovala tusim Filova. U nas jsme strukturu DB vydali proti NDA, ale to se podepsalo pet minut po prvni schuzce v Avastu, proste metodou "Cau, jedno NDA prosim" :-) Je to pro kluky dalsi flavor (TSQL), tak uvidime co s tim dokazi. Drzim palce a na "sunkovou party" vzpominam samozrejme take rad :-)