Z datového skladu do cloudu: Jak Česká spořitel­na změni­la mind­set a otevřela ces­tu k self-ser­vice analytice

Pře­jít z robust­ního on-premise řešení na cloudový příst­up v reg­ulo­vaném bankovním prostředí je mon­u­men­tál­ní úkol. Změ­na se netýká jen tech­nolo­gie, ale i hluboké trans­for­ma­ce firem­ní kul­tu­ry a myšlení lidí. (Což bývá největší oříšek.) Česká spořitel­na ukazu­je, že právě lid­ský fak­tor a tech­no­log­ická jednodu­chost hra­jí v úspěšné adop­ci nových datových plat­forem a self-ser­vice přís­tupu klíčovou roli. 

V roce 2019 byla datová architek­tu­ra primárně postave­na na Ora­cle (cen­trál­ní datový sklad, reg­u­la­torní report­ing). Pro ana­lyt­ické a repor­to­vací úče­ly se použí­valy nástro­je jako SAS Enter­prise Guide, SAS Visu­al Ana­lyt­ics a Cog­nos. Ten­to cen­tral­i­zo­vaný mod­el se však brzy stal bot­tle­neck­em (úzkým hrdlem). Ros­toucí množství dat a poža­davků z byznysové sféry ved­lo k dlouhým dodacím lhůtám (až 14 dní i v pří­padě jednoduchých ad-hoc reportů). 

Trans­for­ma­ce datového prostředí České spořitel­ny začala kolem roku 2021. Tradiční on-premise architek­tu­ra postavená na Ora­clu a nástro­jích typu SAS nebo Cog­nos začala narážet na své lim­i­ty – v oblasti výkonu, flex­i­bil­i­ty i schop­nos­ti rych­le reago­v­at na potře­by byznysu. 

Cloudový příst­up při­nesl zásad­ní změnu – neš­lo jen o migraci tech­nologií, ale přede­vším o změnu mind­se­tu. Cloud podle architek­tů Honzy a Davi­da zna­me­nal pře­chod od cen­tral­i­zo­vaného mod­elu, kde se úzké hrd­lo datového skladu stále více zužo­va­lo, k decen­tral­i­zo­vané­mu self-ser­vice prostředí. Takové­mu, kde si mohou datové týmy mno­ho úloh obsluho­vat samy. 

Pouť dat do cloudu začala s plat­for­mou Keboola, která běžela na back­endu Synapse (Microsoft). Ta byla zvole­na jako PaaS (Plat­form as a Ser­vice) služ­ba v rám­ci Azure. 

• Per­for­mance a konkurence: Plat­for­ma se potýkala s prob­lémy s výkonem, zamykáním objek­tů a konkurencí uži­vatelů při para­lel­ním přís­tupu. Synapse je nezvládala. 

• Složitý self-ser­vice: Při vytváření tab­ulek s dis­tribuce­mi bylo nut­né psát složité SQL příkazy a zamykat pomocí viewček, což bylo pro byznysové uži­vatele obtížné. 

• Dialek­tová bar­iéra: Pře­chod z Ora­cle SQL na Microsoft SQL dialekt byl pro vývo­jáře a datové spe­cial­isty kom­p­liko­vaný a odváděl jejich pozornost od byznysové logiky k řešení syntaxe. 

Po dvou letech a poma­lé adop­ci nastal v roce 2023 rozho­du­jící obrat. Tehdy se back­end Kebooly pře­sunul na Snowflake (Soft­ware as a ser­vice, SaaS) – plno­hod­not­nou cloudovou data ware­house plat­for­mu postavenou na ​„com­pute-stor­age sep­a­ra­tion“ architek­tuře. Migrace zna­me­nala přep­sání stovek trans­for­ma­cí, kon­trolu typů, řešení rozdílů mezi dialek­ty SQL (např. floaty, datové typy, pro­ce­dury) i inte­graci s orches­trací přes Rock­i­fy. Výsled­kem byl však dra­mat­ický posun ve výkonu, jednodu­chosti a nákladech. 

• Para­lel­ní běh: Migrace probíha­la dup­likováním trans­for­ma­cí uvnitř Kebooly do dialek­tu Snowflake. Pro­jek­ty tak běže­ly paralelně. 

• SQL kon­verze: Největší práce byla s trans­for­ma­ce­mi. Na vině byly rozdí­ly v dialek­tech a prob­lémy se složitější­mi pro­ce­du­ra­mi. Výz­nam­nou pomoc při kon­verzi SQL kódu poskytl ChatGPT. 

• Datové typy: Opako­vaně se objevo­valy prob­lémy s převoditel­nos­tí datových typů, zejmé­na typu float. 

• Přínos com­pute: Primárně při­nesl Snowflake rych­le­jší com­pute (výpočet­ní výkon). A po dokončení migrace se dokonce ukáza­lo, že nák­la­dy jsou opro­ti Synap­si zhru­ba na třetině. 

Tech­nolo­gie však byla jen polovi­nou úspěchu. Tou druhou – a pod­stat­nější – bylo zvlád­nutí lid­ského fak­toru. V původ­ním on-premise mod­elu byl vývoj poma­lý… Každý SQL dotaz musel pro­jít přes vývo­jáře, být otestován a schválen. Teprve potom mohl být nasazen. Cloudový příst­up ovšem vyžadu­je důvěru v týmy, které s daty pracují. 

S tro­chou nad­sázky ​„důvěřuj bez prověřuj“. Respek­tive: Nespoléhej na mno­has­tupňové kon­trol­ní mech­a­nis­my a věř těm, co datům rozumí. Self-ser­vice ana­lyti­ka totiž umožni­la týmům získat přímý příst­up k datům a tvořit vlast­ní reporty. A tím pádem také žádoucí akční a pod­stat­ně zrych­lené rozhodování. Ten­to posun však vyžadoval vzdělávání, men­tor­ing a pod­poru. Pomohly ini­cia­tivy jako Datová akademie, která nauči­la zaměst­nance SQL, prá­ci v Tableu i zák­ladům datového myšlení. 

Jak říká David Lacina: ​„Self-ser­vice odle­hčil cen­trál­ním týmům a umožnil lidem dělat jednoduché ad-hoc analýzy samostat­ně. Když potře­bu­ješ čís­la zítra, nechceš čekat dva týdny.“ 

• Rychlost a škálo­vatel­nost ▸ Snowflake umožnil běžet stovkám pipeline para­lel­ně bez výpad­ků a uza­mykání tabulek. 

• Jednodu­chost adopce ▸ Uži­vatelé se mohli připo­jit na libo­vol­ný zdroj dat a během hodin vytvořit funkční datový model. 

• Nižší nák­la­dy ▸ Díky ​„pay-as-you-go“ mod­elu se výpočet­ní výkon platí jen v pří­padech, když je to potřeba. 

• Bezpečnost a com­pli­ance ▸ Řešení splňu­je poža­davky na prá­ci s citlivý­mi daty ve vysoce reg­ulo­vaném bankovním prostředí. 

• Flex­i­bili­ta pro byznys ▸ Týmy si mohou vytvářet vlast­ní data­mar­ty, upravo­vat pipeline a testo­vat nové use-casy bez závis­losti na IT. 

• Rych­lé vítězství pomáhá. Ear­ly adopters a první přík­la­dy úspěšného využití zvyšu­jí důvěru v nové řešení. 

• Plat­for­ma musí být jednoduchá: Složi­tost (jiný SQL dialekt, neznámé příkazy) novou plat­for­mu v očích uži­vatelů diskval­i­fiku­je a brzdí adop­ci. Pře­chod musí být pro uži­vatele co nejméně bolestivý. 

• Pozor na datové typy při migraci: Migrace mezi data­báze­mi vždy přináší neočeká­vané prob­lémy s datový­mi typy. V pří­padě Honzy a Davi­da to byl typ float. 

• Důvěřu­jte real­itě, né papíru (RFP): Řešení, které na papíře v rám­ci RFP (Request for Pro­pos­al) a assess­men­tů vypadá nejlépe (např. Synapse), může v reál­ném provozu sel­hat kvůli prob­lémům s výkonem a složi­tostí. Reál­né nák­la­dy na provoz (TCO, total cost own­er­ship) se se Snowflake ukázaly být mno­hem nižší, než bylo původ­ně odhadováno. 

• Autom­a­ti­zace není všelék. Stále potře­bu­jete lidi, kteří datům i pro­cesům rozumí. 

• Self-ser­vice musí mít hran­ice. Stan­dard­izace, gov­er­nance jsou nut­né, aby se z demokra­cie nestal chaos. 

• Nead­op­tu­jte překryvné funkce! Je nut­né zvážit, zda funkce dos­tup­né v abstrak­tivní vrstvě (Keboola) již nej­sou lépe a efek­tivněji dos­tup­né pří­mo na datovém back­endu (Snowflake Cor­tex), aby se nein­vesto­va­lo úsilí do duplic­it­ních adopcí.