Jak vybu­dovat datovou aplikaci, a jaké jsou ​“best prac­tices” při jejím vývoji?

Její pra­cov­ní den se točí kolem kódu, který zajišťu­je, aby data puto­vala tam, kam mají, ať už jde o interní sys­témy, nebo o reg­u­la­torní reporty pro Česk­ou národ­ní banku. ​„Ofi­ciál­ně jsem datový vývo­jář, ale vlast­ně vyvíjím hlavně pod­půrné aplikace,“ popisu­je Jarosla­va svou pozi­ci. Kromě samot­ného zpra­cov­ání dat se stará i o to, aby se jed­notlivé pro­cesy spouště­ly ve správný čas, správném pořadí a měly k dis­pozi­ci vše potřeb­né. Největší­mi výz­va­mi jsou pro ni nedostatek času, množství schůzek a čas­to né zcela defin­i­tivní zadání. 

Aplikace Rock­i­fy vznikla jako odpověď na vel­mi prak­tický prob­lém – jak řídit a hlí­dat stovky až tisíce den­ních úloh, které zpra­cov­á­va­jí data v bankovním skladu. Každý pro­ces musí proběh­nout přes­ně ve správném pořadí, s kon­trolou všech pod­mínek a bez kolize s jiný­mi běžící­mi úlo­ha­mi. Právě tuto orches­traci dnes Rock­i­fy zajišťu­je, a to nejen pro původ­ní datový sklad, ale také pro další týmy, které si na něm staví vlast­ní datové pro­duk­ty. ​„Bylo potře­ba vyro­bit něco, co by umožni­lo sle­dovat a řídit pro­cesy, které load­u­jí a zpra­cov­á­va­jí data do DWH. Žád­ný komerční nástroj, který by splňo­val poža­davky, tehdy na trhu nebyl, “ vysvětlu­je Jaroslava. 

Rock­i­fy dnes fun­gu­je jako uni­verzál­ní orchestrá­tor, který propo­ju­je různé datové plat­formy a zajišťu­je, že úlo­hy běží přes­ně tak, jak mají. Uži­vatelé si v něm mohou jednoduše posklá­dat jed­notlivé kroky, určit jejich pořadí i pod­mínky spuštění. Díky tomu zvládne obsloužit širok­ou škálu pro­cesů – od data­bá­zových pro­ce­dur přes python skrip­ty pro prá­ci s daty z Data­lake až po REST služ­by, které spouštějí úlo­hy na plat­for­mách jako Keboola nebo Data­bricks. ​„Kromě vlast­ní orches­trace pro­cesů umí Rock­i­fy také sle­dovat a vyhod­no­co­v­at SLA, odesílat noti­fikace tře­ba v pří­padě chy­by nebo zpožděného zpra­cov­ání, mon­i­torovat přenosy dat či sbírat ​“události” z jiných aplikací,” dodává Jaroslava. 

Na vývo­ji aplikace Rock­i­fy se podílí celý tým, který momen­tál­ně řeší pře­chod aplikace z plat­formy Ora­cle Weblog­ic Serv­er na Open­Shift, což je nemalá výz­va. První převe­dená aplikace by měla brzy běžet v pro­duk­ci. Vedle Rock­i­fy se tým stará i o rozvoj dalších pěti aplikací, napřík­lad Rel­man pro nasazování změn nebo DETool pro kon­troly a opravy dat. Jed­nou z hlavních kom­p­likací při pře­sunu na Open­Shift jsou tzv. ​„dlouho běžící úlo­hy“. Úlo­hy spouštěné v rám­ci loadů dat mohou běžet i hodiny, což Open­Shift špat­ně zvládá a kom­p­liku­je toJarosla­va se při vývo­ji drží osvědčeného přís­tupu, který začíná u ​„otravných mal­ičkostí“: ​„Je potře­ba nap­sat spousty kódu – různé pro­ce­dury pro zamykání, logov­ání nebo změny stavů. Násled­ně se musí dobře vymyslet a posklá­dat kos­tra celého řešení, to se nemusí povést napoprvé. Takže se kos­tra párkrát zase roze­bere a přeskládá,” popisu­je. Teprve potom začíná efek­tivní skládání jed­notlivých funkcí a rych­lý nárůst nové funkcional­i­ty. ​„Dobře vymyšlená kos­tra a dobře nap­sané otravné mal­ičkosti se poz­na­jí podle toho, že nová funkčnost pak zabere tře­ba jen dvě hodiny práce i se zaver­zováním,“ dodává. údržbu i nasazování. Řešení spočívá v pře­sunu spouštění těch­to úloh do speciál­ní kom­po­nen­ty mimo Open­Shift, která navíc umožňu­je jejich asyn­chron­ní provádění. 

Zep­tali jsme se Jaroslavy, jaký příst­up prefer­u­je při návrhu ETL frame­worků, načež odpověděla, že: ​„Frame­work by měl být jednoduchý v tom smys­lu, aby se uži­vatelům dobře použí­val, ale i v imple­mentaci, aby se dobře rozví­jel a spravo­val. Uni­verzál­nost řešení podle ní záleží na konkrét­ní míře, kter­ou chceme pokrýt, ale cílem není vytvářet extra nástro­je pro kaž­dou mal­ičkost. Nejlepší je hle­dat zla­tou střed­ní ces­tu. Při samot­ném návrhu nového ETL frame­worku vychází z bohatých zkušenos­tí: ​„Nap­sala jsem za živ­ot desítky něče­ho, co by se moh­lo naz­vat frame­workem, takže každý další už není tak docela nový. Můžu použít to, co se nejlépe osvědči­lo, a naopak uprav­it nebo vynechat věci, které neby­ly ideál­ní,“ popisuje. 

Jarosla­va se při vývo­ji drží osvědčeného přís­tupu, který začíná u ​„otravných mal­ičkostí“: ​„Je potře­ba nap­sat spousty kódu – různé pro­ce­dury pro zamykání, logov­ání nebo změny stavů. Násled­ně se musí dobře vymyslet a posklá­dat kos­tra celého řešení, to se nemusí povést napoprvé. Takže se kos­tra párkrát zase roze­bere a přeskládá,” popisu­je. Teprve potom začíná efek­tivní skládání jed­notlivých funkcí a rych­lý nárůst nové funkcional­i­ty. ​„Dobře vymyšlená kos­tra a dobře nap­sané otravné mal­ičkosti se poz­na­jí podle toho, že nová funkčnost pak zabere tře­ba jen dvě hodiny práce i se zaver­zováním,“ dodává. 

Jarosla­va přiznává, že jde o nároč­nou otázku. ​„Mys­lím, že ideál­ní plat­for­ma neex­is­tu­je. Je tře­ba se smířit s tím, že dokon­alé řešení nena­jdeme, a mís­to toho se vydat směrem, který nám při­padá dostatečně dobrý, vytr­vat v něm a pos­tup­ně něco vybu­dovat,“ popisu­je. Ze své zkušenos­ti dodává, že by bylo žádoucí, aby nová řešení byla skutečně ino­v­a­tivní a nevytvářela pouze kopii desítky let starých pos­tupů na nové platformě.