Podcast

Dobrý den, jmenuji se Jirka Vichrek a vítám vás u dalšího dílu podcastu Datatalk. Naším dnešním hostem je Tadeáš Václavek, který působí jako data inženýr ve společnosti Oriflame Software.

Ahoj, Tadeáši.
Ahoj, děkuji za pozvání.

Dnes s Tadeášem projdeme jejich velmi zajímavou cestu transformace celého BI a DVH, přechod z OnPremise na cloud a co se při tom naučili. Než však začneme, musím se zeptat na slona v místnosti. Oriflame Software – můžeš nám popsat, jaký software Oriflame vyvíjí a jak vůbec Oriflame a software spolu souvisí?

Jasně. Oriflame, jak většina asi ví, je kosmetická firma a prodáváme kosmetiku i různé wellness produkty. Momentálně operujeme ve více než 50 zemích světa a co je opravdu zajímavé, je to, že veškeré IT pro Oriflame se vytváří v Olomouci, v malé firmě Orisoft. Je nás asi 150 a máme i pobočku v Brně. Pro Oriflame zajišťujeme téměř veškeré IT služby – od logistiky přes e-commerce, sales, forecasting, až po samotné DVH, BI a reporting.

To je opravdu zajímavé, že Oriflame má kompletní IT oddělení zde u nás. Oriflame pochází původně ze Švédska. Jak ses do Oriflame dostal ty? Asi to není první nebo tvá láska ke kosmetice, která tě k tomu přivedla.

Ano, nebylo to proto. Já jsem studoval aplikovanou matematiku na Univerzitě Palackého v Olomouci a jedním z předmětů byla i praxe. Dostali jsme možnost jít na praxi do Oriflame, kde první část spočívala v tom, že si člověk vytvořil vlastní projekt a konzultoval ho s managementem Oriflame. To se jmenovalo Oriflame IT Academy, která stále funguje, a myslím, že máme už asi 20–25 lidí, kteří z této akademie vzešli a stále v Oriflame pracují. V této tradici určitě chceme pokračovat.

Mnoho lidí, kteří přišli ze studia matematiky, nešlo čistě na IT pozice, ale spíše do DVH a BI, kde se více pracuje s daty a je to matematikovi bližší oblast. Po úspěšném dokončení prvního projektu, který se týkal detekce podvodů v R, což byl úplný základ, ale pro mě tehdy skvělá příležitost k učení, jsem nastoupil na internship z posledního ročníku a začal jsem se věnovat tomu, co se v DVH a BI děje. Po státnicích jsem nastoupil na plný úvazek do DVH. Začal jsem jako BI analytik – tedy spíše komunikoval s byznysem a tvořil reporty. Po měsíci jsem zjistil, že taková denní komunikace s byznysem nebude úplně pro mě, a proto jsem se více zaměřil na vývoj a u toho jsem také zůstal. Komunikace s byznysem je dnes samozřejmě větší, zvláště díky projektu, který jsem z technické stránky dodával a zajišťoval já, a ta zkušenost mě hodně posunula.

Když říkáš ten projekt, myslíš transformaci?
Ano, myslím transformaci.

Takže jsi po státnicích nastoupil a mně přijde, že jsi byl trochu hozený do vody, protože projekt, o kterém budeme mluvit, by v jiných firmách zajišťoval tým o 40 lidech s podporou dalších 20 high-endových konzultantů a dodavatelů. Můžeš nám říct, jak to celé začalo?

Tak tedy, jsi v Oriflame, je rok 2019 a přijde okamžik, kdy se chcete transformovat. Bylo to z vrcholu firmy, nebo zespodu, jaký byl ten tlak, iniciativy?

Myslím, že částečně z obou stran. Transformace jak BI, tak DVH přišla hodně z naší iniciativy, což považuji za skvělé, protože management nám naslouchal. V Oriflame jako celku probíhala také transformace směrem k e-commerce a cloudu, což přineslo i potřebu změnit, kam se data ukládají a jak se s nimi pracuje.

Když jsem přišel, reporting byl v Cognosu a data byla v Oracle. Zhruba v té době, kdy jsem nastupoval v červnu, probíhal přerod BI z Cognosu do Power BI. V červenci a srpnu už vyšel první report, na kterém se v té době pracovalo, a já jsem byl přidělen do týmu, který se věnoval novým technologiím. Byl jsem totiž tehdy jediný, kdo měl zkušenosti s nějakým machine learningem (byť jednoduchým), což management zaujal, a řekli, že musím být zapojen do těchto nových věcí, takže tak jsem se dostal k této práci.

Díky tomu, že jsi uměl něco málo z machine learningu, tě tedy nehodili do Oracle databází?

Machine learning bych tomu neříkal, byl to spíš základní model časových řad pro predikci prodeje, s tím jsme dospěli k dobrým výsledkům, takže jsem dostával příležitosti pracovat s novými technologiemi a pomáhal jsem vytvářet datové zdroje a datový model pro Power BI. Začali jsme reportem nazvaným Sales Margin, což byly obchodní a finanční data, na jednu obrovskou tabuli, kde bylo spousta dat. Tento report fungoval nějaký čas, ale postupně přišel návrh rozdělit reporting na více menších reportů podle oblasti – například finance, prodej, skladování, forecasting, a tak se začalo tvořit nové BI.

Jaká byla organizační změna? Všichni byli zvyklí používat Cognos, najednou přišlo Power BI – jak jste zvládli fázi, kdy jste provozovali dualitu systémů? Jak probíhala postupná migrace?

Nejprve oba systémy fungovaly paralelně a nové reporty často ukazovaly podobná data. Samozřejmě se objevily první problémy s nekonzistencí dat – ať už kvůli různému časovému refreshi nebo rozdílným uživatelům, kteří v novém Power BI vyžadovali nové funkce, filtry a tak dále. Objevily se situace, kdy 10 % dat nesedělo a bylo nutné vysvětlovat nejasnosti uživatelům. Nakonec jsme dospěli k závěru, že současný model paralelních systémů není dlouhodobě udržitelný.

Začali jsme proto vytvářet nový report, který jsme otestovali s uživateli, a až pak vypínali staré verze daného reportu v Cognosu. Takto jsme postupně snižovali počet reportů v Cognosu. Původně bylo v Cognosu přes 500 reportů, z čehož asi 200 se nepoužívalo několik let, takže jsme je deaktivovali, a postupně jsme takto přistupovali k další redukci až do konce roku 2022, kdy jsme Cognos úplně ukončili a přešli jsme plně na Power BI.

Když se podíváme zpětně, co vám přineslo přechod na Power BI oproti starému systému? Co bylo zásadním zlepšením?

Naštěstí, když jsem nastupoval, už bylo rozhodnuto, že Cognos pomalu skončí, takže jsem měl možnost pracovat s čistě novými nástroji. Vedle samotných výstupů, které z původního systému vypadaly trochu jako Excelové tabulky, jsme především chtěli posunout vizualizaci dat na modernější úroveň. V našem prostředí totiž Cognos uměl hlavně tabulky, a my jsme chtěli přidat zajímavější grafické vizualizace.

I když uživatelé většinou chtěli tabulky, snažili jsme se jim nabídnout zajímavější grafy. Po mnoha iteracích ale často opět skončili u tabulek – ale už s lepšími vizuálními prvky, například barvami a přehlednějším uspořádáním.

Prostor vizualizací Power BI tedy přinesl posun a moderní vzhled reportů, který Cogonos nikdy nedokázal nabídnout.

Jak jste při nasazení Power BI řešili data? Přepisovali jste vše z Oracle, nebo jste migrovali části?

Většinu dat jsme zpracovávali téměř od nuly. Vzniklo nové schéma v Oracle, které je jediným zdrojem dat pro Power BI, a většinu věcí jsme přepisovali. Začali jsme prvními tabulkami, při tom jsme hodně kopiírovali logiku původního modelu, ale naším cílem bylo vše vytvořit kompletně znovu. Tak vznikl nový datový model.

V rámci týmu část lidí pracovala na novém datovém modelu a druhá část se zaměřovala hlavně na vyčištění dat. Zdroje používané na Cognos sloužily zároveň i pro Power BI. Proběhl tedy rozsáhlý cleanup, který byl zásadně důležitý. Bez něj bychom jen těžko dokázali novou platformu nasadit.

Bohužel často se zapomíná na to, jak důležitá je příprava starých datových zdrojů a jejich očištění. My jsme například pracovali se starými daty, která byla vytvářena i 20 let a hodně často po salámové metodě, tedy přidáváním nových částí bez nutné optimalizace.

Dokonce krátkou dobu byl BI tým provozován i externě v Indii, konkrétně firmou IBM, což se někdy odrazilo na podobě a kvalitě kódu.

Největší problémy jsme měli při migraci právě s částmi, které nebyly kompletně přepsány nebo upraveny. Přesto jsme museli v Oracle stále pracovat se starými zdroji, a přitom se na ně dívat z nového úhlu pohledu. Vyčistili jsme obrovské množství zbytečných dat přes spolupráci s byznysem a technickými týmy.

Příkladem je sloupeček v reportu, který byznys říkal, že používá, ale ve skutečnosti se šest měsíců nevyplňoval, nebo byl chybně naplňován po změně.

Nebyla to však úplná čistka – mnoho starých datových objektů bylo zachováno. Měli jsme i myšlenku provést kompletní vyčištění před migrací, ale nakonec jsme se rozhodli ponechat některé položky a mazat je postupně, protože nám docházela kapacita a bylo potřeba migrovat rychle.

Přesto nám cleanup dramaticky ulehčil práci a díky němu jsme dokázali celý DVH systém zmigrovat během zhruba roku a jednoho měsíce.

Existují nějaká doporučení pro ty, kdo podobný proces teprve čeká?

Z mé zkušenosti je důležité mít odvahu něco nepoužívaného či nefunkčního smazat. Nicméně se nám několikrát stalo, že jsme něco smazali a později to bylo potřeba obnovit.

V ideálním světě by tým měl být větší a analýza využití dat detailnější. My jsme měli omezené kapacity a párkrát se smazání něčeho ukázalo jako chyba. V těchto případech jsme to ale připravili znova a lépe, a byznys to většinou akceptoval.

Důležité jsou také konzultace s okolními týmy, protože my data nevytváříme sami, ale přebíráme je z Olomouce, Brna a dalších míst. Proto jsme s těmito týmy úzce komunikovali už při tvorbě nových datových zdrojů, abychom jim mohli dát co nejkvalitnější podněty.

Tato spolupráce se nám velmi vyplatila – když nový zdroj vyjel ve dvou zemích, začali jsme ho testovat a postupně roztahovali na dalších padesát zemí. Měli jsme tak problémů méně právě u těch zdrojů, na kterých jsme byli od začátku.

U těch zdrojů, ke kterým jsme se dostali až později, jsme občas zjistili, že nejsou úplně dobře strukturované nebo něco chybí. A to není vina vývojových týmů, ale spíše důsledek toho, že jsme se s nimi dříve nedostatečně bavili.

V Oriflame obecně je velká byznysová logika umístěná přímo v IT týmech a není plně na byznysu. Myslím, že naši inženýři často znají definice klíčových metrik lépe než samotní byznysoví uživatelé, což je v Oriflame spíše unikátní situace.

Nepovažuji to za nevýhodu, naopak jsme za to docela cenní. Nicméně se shodujeme, že komunikace s byznysem by mohla být lepší, i když bychom tím zpomalili vývoj, protože byznys chce častěji nové věci. Díky současnému postupu vyvíjíme nejprve řešení skoro hotové, a pak už jen dolaďujeme a přidáváme další požadavky, což je pohodlnější a efektivnější.

Ještě když jsme u těch datových zdrojů, zmiňoval jsi, že řešíte širokou škálu případů – nejen prodeje a komerční data, ale i logistiku a skladování. Jak jste při tak širokém spektru prioritizovali a jak jste postupovali při návrhu datového modelu? Byl to spíše průběžný proces nebo jste hned na začátku měli jasnou koncepci podle best practices?

Myslím, že se to hodně vyvíjelo a učili jsme se za pochodu. Dělali jsme chyby a jednotlivé aplikace vznikaly postupně.

Naštěstí jsme měli v týmu velmi zkušenou byznysovou podporu, takže nebylo téma, na které bychom si nemohli někoho zeptat. Hlavně my, kteří jsme byli mladší, jsme mohli vždy oslovit zkušené kolegy, kteří v Oriflame pracují i kolem 20 let.

Díky tomu jsme měli neustálou zpětnou vazbu, která nám hodně pomáhala při návrhu i tvorbě.

Business logika je v Oriflame velmi podobná jako v IT, což pro nás z tohoto pohledu bylo jednodušší. Když jsme začínali vyvíjet, vždy jsme začínali od prodejů (sales). Myslím si, že i když se vyvíjelo Power BI a nyní se implementuje druhá verze (DVAčko), první report byl vždy denní report prodejů, tedy v podstatě jednoduchý report. Právě na něj byl největší tlak, protože se na něj dívá nejvíce lidí – vlastně všechny důležité osoby ve firmě. Při migraci jsme zjistili, jak často tyto reporty potřebují – dělali jsme Proof of Concept (POC) a zkoušeli jsme to dělat dokonce v reálném čase, kdy dostaneme event a během půl minuty bylo to v Power BI, což bylo úžasné, ale zároveň zcela nepoužitelné. U Oriflame je totiž podle mě velmi složitá business logika, existuje mnoho pravidel, která postupně musíme do dat dostat, aby bylo možné někomu report ukázat. Tento proces trvá velice dlouho a vyžaduje spoustu vstupů.

Nyní, jen abychom dostali základní prodejní data, musíme konzumovat například šest až sedm zdrojů. Místo jednoho, který by nám poskytl data z více než 90 % během půl minuty, musíme kombinovat různé zdroje a dostáváme se tak na jiné časové nároky. Nicméně tak to prostě musí být, museli jsme se s tím vypořádat. Reporty, které byly založené na minutové refreshi, jsme proto zavrhli a nyní počítáme spíše s 20–30 minutovým intervalem, což už je v pohodě.

To, že jste museli skládat šest zdrojů k sestavení sales reportu, souvisí také s business modelem, kdy máte nezávislé prodejce, kteří jsou v určitých strukturách. Ti sami nemají úplně realtime reporting. Ano, je to také tím, že u nás to není klasická faktura, kdy zákazník nakoupí a firma ví, kolik vydělala, jaký má zisk, jaký obrat. My totiž vyplácíme konzultantům bonusy za to, že pro nás prodávají. Každý má jiné bonusy, protože jsou lidé na různých úrovních.

Ještě k tomu, co je zajímavé – máme 50 zemí a v Latinské Americe to funguje úplně jinak než v Asii nebo v Číně, jinak to funguje v Evropě. Nedávno jsme navíc řešili tři různé business modely, každý s jiným postupem výpočtu bonusů, různými prémiemi za určité věci. Velmi složité bylo pro nás i pro tým, který nám pomáhal vyvíjet Value Added Tax (VAT). Protože v 50 zemích je to hrozně složité uchopit. Například pro Španělsko jsme museli daně řešit jinak, protože tam jsou Kanárské ostrovy s odlišným přístupem. V Polsku mají dvě daně na čokoládu, a my jsme prodávali proteinové šejky. Ukázalo se, že i státy samotné mají v některých ohledech nevyřešené nebo zmatené přístupy. Celkově to bylo velmi složité. Pak jsme také museli zakomponovat data z jednotlivých zemí. Máme katalogy, dříve tištěné, s kterými chodili prodejci. Dnes je stále máme jako formu marketingu, ale lidé se více dívají na internet a elektronické katalogy.

Nicméně každá země má odlišný počet katalogů během roku. Když chcete porovnat data s předchozím rokem, zjistíte, že v jednom roce je to 18 katalogů, v jiném 12, pak se to opět mění na 18. Toto způsobovalo strašné komplikace v kódu. Z původně několika řádků kódu, který nám ukazoval zhruba na 95 %, kolik jsme vydělali, se vytvořilo několik tisíc řádků. Celkově se to zkomplikovalo, ale jinak to asi nejde – náš business model je složitý z hlediska dat a s tím jsme se vždy potýkali.

Byl jsem opravdu překvapený, když jsem přišel do firmy, jak může být složité zjistit, kolik vůbec máme lidí, kteří pro nás prodávají. Každý má jiný titul, jiný status, někdo se započítává, někdo ne. V každé zemi je to jiné. Ve Finsku třeba polovina lidí se nezapočítává vůbec a polovina ano.

Jak se to projevilo na tvém modelu nebo schématu? Na začátku bylo hodně výjimek. Byly určité konfigurační tabulky. Jednou z věcí, o kterou jsme se snažili při migraci do nového datového skladu (DV), bylo vyhnout se co nejvíce těmto výjimkám a všechno narvat do skriptů, aby výjimky, které byly ve starém DV, zmizely. A myslím, že se nám to docela povedlo.

Bylo to také o přesvědčení byznysu, protože tam bylo fakt několik tisíc řádků kódu kvůli věcem, které nakonec nikdo ani nezaregistroval. Důležité bylo, aby věděli o těchto výjimkách hlavně dva lidé, kteří rozhodují denně o těchto věcech, aby je měli ve stejném povědomí. A my jsme kvůli tomu měnili kódy. Takže to hodně záleželo na komunikaci s byznysem, že jsme se snažili těmto výjimkám vyhnout. A myslím, že se to povedlo.

Nyní je datový sklad docela pěkný. Vy jste úplně opustili Cognos a přešli plně na Power BI. A co Oracle? Kdy se začalo řešit, že když máme BI v moderní podobě a máme vyčištěný DV, zda nestačí jen vyčistit ten DV? Asi by stačilo, ale my jsme byli zatížení Exoratem, tedy fyzickým hardwarem, u kterého končila licence. Věděli jsme, že buď budeme migrovat na nový Oracle, což by pro nás znamenalo minimální práci, nebo půjdeme jinam.

Diskutovalo se o tom už, když jsem do firmy přišel, a postupně se rozhodlo, že firma přechází do cloudu a my s ní. Začali jsme vybírat technologii, respektive koncept, jak to pojmout. Vím, že rozběh to mělo někdy v letech 2020 a 2021. Byl jsem ve firmě rok nebo dva a jako přísedící jsem chodil na meetingy spíše naslouchat, většině věcí jsem nerozuměl, ale od začátku jsem u toho byl.

Rozhodli jsme se pro Lakehouse a byli jsme poměrně početný tým, asi čtyři nebo pět lidí, kteří se tomu věnovali. Začali jsme u jedné firmy s POC, ale nepovedlo se to, nelíbilo se nám to. Firma prezentovala produkt jako novinku, ale šlo spíše o kopírování starých věcí bez legosub pohledu. Šlo jen o přemístění Oracle do cloudu bez reálného business přínosu. Proto jsme to ukončili a pak začali spolupracovat s firmami Bigab a Solitea, které nám navrhly Lakehouse architekturu a technologii. Udělali několik case studies, například zpracování eventů co půl minuty, což bylo super, i když jsme to nakonec nepoužili.

Vymyslela se architektura na Lakehouse a začal výběr technologie. Bohužel jsme zvolili Synapse od Microsoftu, začali jsme v květnu či červnu 2022 vyvíjet první use case. Pak za námi přišel tým, který chtěl zpracovávat notifikace z eventů. Messaging se předtím moc nereportoval, byly to první ukázky. Řekli jsme si, že na tom postavíme nový DV. Jeden kolega se tomu věnoval zpočátku jeden až dva dny týdně.

Stavba nového DV začala, věděli jsme, že to bude první use case a od toho se odpíchneme, uvidíme, jak to bude fungovat. Po třech či čtyřech měsících, i když to byl spíše part-time job, jsme si řekli, že to funguje, vypadá to dobře, ale nevěděli jsme, jestli je to dostatečně dobré, kdy report běží za 20 minut, což bylo oproti dřívějším dvěma minutám z Oracle. Neměli jsme jistotu, zda je kód udržitelný, zda nás něco nepřekvapí po půl roce změn. Domluvili jsme se s Bigabem, že nám provedou první code review a z té spolupráce, která pokračovala celý další rok a trvá dodnes, vzešla spousta poznatků.

Bigab zhodnotil, že náš přístup byl naivní, i když pěkný. Začali nám pomáhat s přepisem kódů. Zjistili jsme, že Synapse nebyla ideální volba, protože v té době nebyla dostatečně vyspělá, měli jsme problémy s načítáním knihoven, které byly součástí většiny návodů, klustry padaly, celkově byla platforma nestabilní. Mukotně jsme řešili rozbalování JSONu.

Pak Bigab doporučil, že máme změnit technologii. Na meetingu jsem šel k managementu trochu nervózní, protože jsme měnili technologii. Ptali se, co to znamená. Řekl jsem, že máme asi čtyři skripty, které prostě přepíšeme během týdne. Řekli: „OK, jedeme na to.“

Tak jsme přešli ze Synapse do Databricksu a za týden byly skripty migrovány. Začali jsme opravdu tvořit nový DV. To se psalo někdy na přelomu roku 2023. Když se nyní podíváme zpětně na tu naivitu tvých kódů a ETL procesů, co konkrétně vám to přineslo za poučení o dva roky později? Předpokládám, že nás poslouchají lidé, kteří mají podobné situace.

Nemyslím si, že to byla chyba. Měli jsme hodně nezkušený tým. Byl jsem ve firmě dva roky, věděli jsme, že tým se bude skládat ze tří či čtyř lidí, kteří byli hodně juniorní. Byly tam dvě kolegyně po škole. Nikdo neuměl Python na pokročilé úrovni, přestože každý trochu uměl SQL, ve firemní praxi jsme s ním pracovali denně.

Věděli jsme, že i ve Sparku lze psát cykly, ale rozhodli jsme se, že půjdeme do PySparku a budeme psát všechno v Pythonu. Částečně to byl záměr, jak se v něm zdokonalit pochopením každodenní práce. Takže jsme šli do úplně nového jazyka, což představovalo určitou výzvu, ale myslím, že každá z kolegyň si s tím dobře poradila. Na internetu je dnes možné naučit se skoro všechno poměrně rychle.

Chyběla nám však zkušenost, jak psát kvalitní, čistý kód – věděli jsme pouze základy a velmi často jsme se učili metodou pokus-omyl. Když kód fungoval, pokračovali jsme dál. Chyběl nám jeden člověk, který by řekl: „Jo, funguje to, ale jde to napsat třikrát lépe.“

V tom nám velmi pomohl Bigab.

Takže jste si nechali udělat code review? Jaké to mělo přínosy?

Ano, obrovské. Dalo nám to pravidelnou zpětnou vazbu. Není to tak, že bychom něco přehodili na někoho jiného, ale měli jsme možnost pracovat s odborníky, kteří nám dávali review a pomáhali opravovat chyby.

Ještě než přejdeme k migraci na Databricksu a dalším krokům, říkal jsi, že naučit se nový jazyk bylo v pohodě. Už jsi předtím uměl R a SQL, nyní Python. S odstupem času, co ti přinesla volba nového jazyka oproti psaní všeho v čistém SQL ve Sparku?

Myšlenka byla, že psát to šlo i v SQL, ale jednu věc jsem se obával – pokud to člověk začne psát v SQL, bude mít tendenci dělat copy-paste z Oracle a nebude přemýšlet o tom, jestli jsou i nové datové zdroje správně zahrnuty nebo ne. To byl hlavní důvod, proč jsme nešla do čistých cyklů v SQL.

Nakonec se ukázalo, že když už byl čas na rychlé řešení, občas se opravdu dělaly jen kopie kódů. To pak působilo problémy. Nyní, když něco podobného objevíme, hned to převádíme do Sparku nebo Pythonu.

Dále jsme zjistili, že základ ETL lze napsat v SQL, ale celá „omáčka“ kolem byla psána v Pythonu – úlohy spojené s provozem, technické záležitosti, automatizace security a přístupu. To všechno bylo výrazně efektivnější psát v Pythonu.

Byl to proto skvělý krok a nebál bych se ho doporučit. Pokud máte ve firmě šikovné lidi, naučit se nový jazyk není nic hrozného. Je důležité mít někoho zkušeného, kdo opraví prvotní chyby v kódu, protože každý začátek je o učení.

Tato zkušenost nám dala velmi mnoho – pro nás jednotlivce to byla příležitost naučit se nové technologie, což je také důležité pro kariérní rozvoj.

Moc se mi líbí, jak říkáš, že běžný přístup lift and shift nefunguje. Když implementujete cloudové prostředí nebo nové technologie, musíte se zastavit a zamyslet se nad výhodami a změnami.

Můžeš popsat největší architektonické změny, které jste díky tomu prováděli? Třeba bezpečnost, přístupy, autorizace a podobně.

Jednoznačně je to bezpečnost – security. V předchozím řešení na Oracle jsme uměli udělat marketingovou segmentaci bezpečnosti. Máme 50 zemí a každý uživatel, který se dívá na report nebo data, neměl vidět všechno. Byli tam regionální uživatelé, marketingoví uživatelé a tohle fungovalo v Oracle dobře.

V Databricksu jsme to převedli bez problémů, ale měli jsme problém s bezpečností na úrovni sloupců (column-level security) a s maskováním dat. V Databricks nám skvěle pomohla jednoduchá funkce na maskování, kterou má platforma built-in.

Jediné, co stále nejde, je převést tuto bezpečnostní vrstvu do Power BI, ale na tom se pracuje.

Dále jsem osobně zažil výzvu v přenosu partitioningu, na který jsme byli zvyklí v Oracle. Ten výrazně pomáhal. S novým systémem Synapse partitioning nebyl dostupný a museli jsme se hodně zamyslet, protože špatné partitioningové strategie v prvních ETL nás v budoucnu hodně trápily.

To byla jedna z důležitých věcí, na které jsme si museli dát pozor, a kdybychom to neřešili, mohlo by to vést k problémům.

To nějak fungovalo, ale za půl roku by to bylo doslova peklo. Velmi nám například pomohl BigUp, protože nám ukázali nejlepší postupy – jak to udělat, jak se k těm datům budeme chovat. Hodně nám pomohlo přemýšlet nejen ze technického hlediska, například „super, partitionoval bych to tak a tak“, ale i z pohledu toho, jak to bude používat byznys nebo reporting. Měli jsme tam tabulky, které jsme museli pře-partitionovávat, a pro reporting nebo pro uživatele to byl opravdu zásadní problém.

Co se týče Databricks a Synapse, změna spočívala v tom, že Synapse ještě nebyl dostupný, bylo tam mnoho chyb a Databricks jednoduše fungoval. Navíc jsou tam rozdíly ve filozofii přístupu k celé věci. Myslím si, že Databricks představuje univerzálnější platformu. Jeden z našich cílů také bylo vytvořit nový operační reporting, nejen Power BI, které bylo spíše zaměřené na data pro top management, ale i reporting pro lidi spíše v ad hoc režimu. To Databricks umožňuje jako zabudovanou funkci, mají tam Databricks dashboards, což se mi od začátku moc líbilo.

Když jsme s Databricksem začínali, dashboardy byly ještě v preview verzi, ale mohli jsme si v tomto nástroji věci pomalu připravovat, a to je velmi zajímavé. Nyní, po necelém roce, jsou naše dashboardy na nové platformě už považovány za legacy – mají příznak legacy, protože Databricks během tří měsíců vydal novou verzi. Máme tedy novou verzi, ale dashboardy na ní jsou stále staré. Už přemýšlíme o transformaci všech dashboardů do nové části platformy, což bude docela zábavné a bude velmi zajímavé to byznysu vysvětlovat – po tom, co si na to konečně za dva měsíce zvykli, jim to zase přesuneme jinam. To však přinese obrovské benefity, takže do toho půjdeme.

Celkově vzato je portál a všechno ostatní v Databricks mnohem lepší než v Synapsu. Zajímavé ale je, že jsme v Synapsu trošku zůstali kvůli Power BI, a to hlavně proto, že většina věcí byla nad Analysis Services, na které se z Databricksu zatím není možné připojit – nevím, zda vůbec někdy bude. Proto jsme potřebovali dostat data do Analysis Services, a k tomu se ukázal Synapse jako vhodný nástroj. Stejně tak v Synapsu zůstaly starší části ETL, například z pohledu Data Factory, protože část Synapsu tvoří pipelines, což je vlastně Data Factory. Zvláště loady dat z Oracle databází, které máme v Oriflame, tam vyšly finančně i časově lépe. Synaps tedy úplně nezahazujeme, ale myslím, že asi 90 % dat jsme přesunuli do Databricksu.

Je to poněkud nešťastné, že máme dvě takto velké technologie, ale benefity jsou obrovské. Synaps nyní primárně slouží k poskytování dat do Power BI a kompletní ETL máme v Databricksu. Kompletní MR (machine-readable?) věci jsme přemístili do Databricksu, takže celé to máme v jedné platformě. Dříve to bylo rozdrobené přes Oracle, asi na pěti různých technologiích, než jsme data dostali z warehouse, něco spočítali a vrátili je zpět pro reporting. Nyní je všechno v jednom, což je skvělé.

Nyní k další otázce: co vše jste museli přemýšlet a udělat jinak při přechodu z Power BI napojeného na už vyčištěnou Exadata, přes Synapse až k migraci části na Databricks? Existují nějaké koncepty, které platí pro jakýkoliv warehouse připojený k Power BI, a co je naopak velmi specifické, na co je potřeba dát pozor, když máte takto širokou zkušenost?

Základem je dobrý datový model, bez toho to nejde. Už při návrhu je třeba přemýšlet o datech, protože například Power BI neumí spojovat přes více sloupců než jeden. Už zde je potřeba být na to připravený, ale to si myslím platí pro všechny systémy. Na co bych si ale opravdu dával pozor, je Oracle. Ten umožňuje data refreshovat kdykoliv chceme a na začátku jsme na to narazili jako na limit. Právě to je hlavní důvod, proč jsme se rozhodli pro Synapse – tam se platí za objem uložených dat. Oracle měla poměrně složitá data, ale zase jich nemáme mnoho, myslím si, že v porovnání s jinými firmami máme opravdu málo dat. Celý původní datový sklad měl asi 20 TB včetně historie, kdy jsem chtěl například vidět data z roku 1997. Z toho důvodu jsme se rozhodli pro Synapse, protože je pro nás neskutečně levný. Fakt za to platíme stovky až tisíce procent méně než u Databricksu. V Synapsu se platí za čas a my data potřebujeme refreshovat pořád, ale jich je relativně málo. Máme totiž hodně agregovaných dat pro Power BI a obecně pro reporting, protože využíváme technologii, kdy se v ETL počítají agregační vrstvy. To nás nestojí mnoho peněz, je to poměrně levné, a ušetříme tak obrovské částky za refreshování a reporting, který je zároveň rychlejší. Samozřejmě to znamená spoustu dodatečné práce pro vývojáře, ale to jsme takto zvolili.

Dokonce hodně duplikujeme data ve finální reportingové vrstvě, a přestože nás mnozí odrazovali, že to nebude správně fungovat a data nebudou konzistentní, ukazuje se, že to byl dobrý krok. Hlavní reporty máme refreshované každé dvě až tři minuty, data mohou být aktualizována velmi rychle. V Databricksu pak používáme nejlevnější clustery pro operační reporting, protože nemusí načítat velká množství dat – čtou pouze menší tabulky a mohou je číst průběžně. Tím jsme vyřešili problémy s obrovskými tabulkami a pomalými reporty z minulosti a myslím si, že se nám to povedlo.

Jak tento příběh vypadá dnes, v druhém čtvrtletí 2024? Kde teď jste, co se vám podařilo a co je ještě třeba dodělat?

Dostali jsme tvrdý deadline na migraci, a to na únor. Zajímavé je, že když jsme s migrací začínali mluvit v dubnu předchozího roku, říkali nám, že bychom měli mít hotovo do dubna. O tři čtvrtě roku později nám však řekli, že to musíme udělat o měsíc dříve – do března, a nakonec začátkem roku 2023 byly termíny posunuty na únor. I když to vypadá jako malý posun, v konečném důsledku jsme přišli o dva měsíce času na práci. To znamenalo, že poslední měsíce jsme pracovali jinak, intenzivněji. Naštěstí to byl přestupný rok, takže jsme měli o jeden den navíc, což bylo opravdu užitečné.

Byly celé týdny, kdy se pracovalo přes víkendy a dlouho do večera, aby se vše stihlo. Věděli jsme, že hned vše nestihneme, ale ani jsme nemuseli – měli jsme podporu z byznysu, který nám umožnil migrovat data a reporty postupně, aby byly všechny informace dostupné a byla vytvořena dobrá záloha Exadata. Následně bylo naším úkolem v březnu a dubnu dořešit a opravit reporty.

Po celé ty dva měsíce jsme fixovali různé problémy, které se v provozu objevily, například chyby či potřebu častějších aktualizací. Velkým problémem, a to hodně na hraně, bylo testování kvality dat. Měli jsme deadline na konec února a myslím, že přibližně druhý týden v únoru jsme řekli klíčovým uživatelům reportů, že mají asi tři dny na kontrolu, a po uplynutí této doby staré řešení vypneme. Potřebovali jsme totiž Exadata vypnout nejpozději 20. února, abychom měli deset dní na kompletní archivaci dat – přitom nám stále přicházela nová data, takže jsme nevěděli, co se změnilo, co ne. To se pak řešilo za pochodu.

Bylo to dáno tvrdým deadlinem a myslím, že kdybychom měli o tři měsíce víc, je to jedno, jednoduše by se problém „odsouval“ dál. Člověk se na takových projektech učí, že i kdyby bylo více času, často to stejně skončí na poslední chvíli. Březen a duben byl tedy velmi náročný.

Původně jsme si mysleli, že únor „zabijeme“ Exadatu, oslavíme a začneme zase normálně žít – chodit na obědy do restaurace a nebýt celý den v práci od rána do večera. To se však úplně nepovedlo, takže březen a duben byly stále velmi zábavné měsíce.

Obrovský problém jsme zjistili v souvislosti s náklady (tzv. cost). Byla tam predikce nákladů, kterou jsme se snažili dodržet, ale v březnu jsme zjistili, že skutečné náklady byly trojnásobné. Museli jsme začít více sledovat výkon a efektivitu. Naštěstí jsme dostali rozpočet a bylo nám řečeno, že ať to funguje a náklady řešíme později. Koncem dubna se nám podařilo náklady snížit na polovinu prvního měsíce „poběhu“. Zpočátku nebylo prostředí připravené, proto jsme to „drželi pohromadě“ a teď už to běží stabilně.

Toto je pro nás velká zkušenost a i když jsme náklady částečně optimalizovali, je potřeba se v tomto směru ještě zlepšovat. Nejhorší fáze už máme za sebou, vše funguje a uživatelé si nestěžují, naopak chtějí nové věci, které plánujeme. Začínáme zase normálně žít – chodit na obědy do restaurace a odcházet z práce za světla.

Dobrá rada pro kohokoliv plánujícího migraci data warehouse je plánovat deadline na únor nebo březen, protože kdybychom měli termín v září, nebylo by jednoduché pracovat přes letní měsíce a dovolené. Náš tým byl ochotný pracovat i v nepříznivých podmínkách a to mu pomohlo.

Co nás čeká dál? Tady je důležité zmínit tým, protože vše zvládli ve čtyřech klíčových lidech – já a tři kolegyně v našem BIN DVH oddělení. Pro kontext, kdo na tom pracoval. Když jsi mluvil o optimalizaci a nákladech, slyšíme často, že náklady se špatně predikují a mohou nečekaně vzrůst. Byla tam nějaká lekce, kterou jste vyřešili rychle po březnu, třeba nějaký problém s loadováním nebo podobné?

K týmu doplním: čtyři lidé pracovali na ETL. Následně se k nám připojili další tři lidé z BI, kteří migrovali reporty. Plus pár lidí ještě částečně pracovalo na Exadatě a pomáhalo nám ze svých oblastí. I když jsme byli začátečníci a mladí, tato zkušenost byla největší lekcí. Ukázali jsme, že je možné projekt dokončit i s takto mladým a nezkušeným týmem, pokud mu firma věří.

Měli jsme obrovskou podporu od firmy, která nás postavila před velmi tvrdý deadline. Kdybychom to nestihli, bylo by nutné koupit kompletně novou Exadatu od Oracle, což by firmu velmi zasáhlo. Díky podpoře tým odvedl skvělou práci a myslím, že jsme se i jako tým více srostli. Byla to nekonečná týmová stavba – doslova hackathon. Každý z nás možná narazil na své hranice – nebo na svůj vrchol. Pod tlakem vznikají diamanty, jak jste správně řekl.

Vrátím se k problematice nákladů. Na začátku jsme například vymysleli, jak dostat data z nového salesového systému na SQL Serveru a napsali během dvou dnů ETL v Data Factory. Fungovalo to dobře, ale když jsme spočítali náklady, vyšlo nám to na asi čtyři miliony korun ročně. Důvodem byla velká frekvence iterací – máme 50 zemí, každá má své databáze, mnoho tabulek, některé jsou potřeba aktualizovat i každou hodinu. Náklady tedy rostly do nesmyslných hodnot.

Naštěstí jsme to objevili dřív, než jsme začali produkčně, protože jinak by se to ukázalo až za týden. Takové situace se stávaly i při archivaci dat – kolegyně po škole pustila archivaci bez vědomí nákladů v cloudu, a za víkend jsme vygenerovali několik tisíc korun, což jí bylo spíše na škodu, ale i nás to donutilo lépe kontrolovat náklady.

Od té doby jsme začali více přemýšlet dopředu o tom, jak často může určitý proces běžet, aby nás výrazně nezničil finančně. Rozhodujeme o velikosti a kapacitě strojů, množství dat a optimalizujeme zdroje zapojené do ETL. Čím rychleji to běží, tím vyšší jsou náklady, proto jsme se zaměřili i na optimalizaci kódu.

Například jsme se zpočátku domnívali, že data budou stačit v určité frekvenci, ale byznys potřeboval data častěji, například jednou za hodinu. Ukázalo se, že tenhle proces trvá tři hodiny, což nešlo uskutečnit. Kdybychom dříve zapojili byznys do diskuze, mohli bychom to napsat rovnou správně a nemuset věci předělávat. Na druhou stranu by pak ale bylo potřeba více času, který jsme zkrátka neměli. Takže nyní některé věci předěláváme zejména z důvodu frekvence.

Ovlivnilo to nějak schéma a datový model, nebo byl více z pohledu byznysové logiky a modelu a neměnilo se v závislosti na technologii a nákladech v cloudu?

Myslím, že to bylo více méně dané byznysem. Původní operační reporting byl in-house řešením s přímým připojením do systémů. Nový operační reporting jsme však chtěli stavět na datovém skladu (DVH), takže nemohl být real-time. To s sebou přineslo problémy, ale naopak to také umožnilo, že neničíme výkon originálních systémů, což jim usnadňuje škálování. Toto byl například problém, na který jsme nedávno narazili…

[Text končí neúplně.]

Pojďme to řešit. Možná to dopadne tak, že se zase budeme živě dívat do těch databází některých, kde je to třeba, protože prostě to jinak nejde, a uvidíme. Toto je ještě ve hvězdách.

Co máš ještě na tu debatu? Na tu debatu, no, vlastně pro nás největší výzvou bylo dostat data z eventů, se kterými jsme nikdy nedělali, tedy streaminková data. Firma teď přechází na Kafku a s tímto počtem. Začneme ty nejdůležitější věci, které nám zabírají nejvíce času, přepisovat – nechci říct od základu, ale minimálně ty datové zdroje. Přechod na Kafku nás tedy čeká v následujících měsících.

Chceme zlepšit dokumentaci, ta prostě nebyla – nešlo to. Takže dopsat dokumentaci, popsat datové zdroje a vytvořit skvělý datový katalog pro uživatele. To je jeden z našich hlavních cílů, který jsme měli už na začátku. Mít kvalitní datový katalog pro uživatele, aby se třeba posunuli v rámci self-service BI, ne úplně kompletně, to asi nejde, ale aby když člověk přijde do VVHčka a řekne, že má nějaké dovednosti v SQL nebo Pythonu a chce dělat zajímavé věci, ale nechce nás zdržovat, dostal od nás prostor.

Jestliže budou data dobře popsána, bude se nás ptát méně, kde co najít, a bude se mu s nimi lépe pracovat. Vzniknou nové věci, které firmě pomohou posunout se dál nebo něco optimalizovat, protože tým je omezený. Čím více lidí se bude těmi daty zabývat, tím lepší to určitě bude.

Naším cílem je otevřít ta data více do firmy, aby více lidí vymýšlelo skvělé věci a aby to, co jsme zde vlastně rok a půl dělali, bylo skutečně využito na maximum. Protože pokud zůstaneme tam, kde jsme, tak jsme to jen přenesli do jiné technologie a máme některé věci rychleji a možná v lepší kvalitě, ale žádné další benefity by tam nebyly.

Jako první vlaštovka toho, že se nám to začíná vyplácet, je, že náš managing director pro IT, který sídlí ve Švýcarsku, začal tvořit první vlastní reporty. My jsme je nyní postupně převzali a tvoříme kompletně nový balík reportů pro MD z každé země, které se podle prvních výsledků budou velmi hojně využívat. Stačilo jen získat nějaký vstup od lidí, kteří ty data skutečně používají, a ti začali vytvářet první vlastní reporty nad našimi daty, což bylo skvělé.

To je hezké, na exa datové platformě se něco takového asi nestalo, to určitě ne. Děkuji moc, Tadeáši, za tvé povídání. Mě hrozně baví tvoje skromnost. Hodně jsi zdůrazňoval, že jde o neskoušený tým, ale z mého pohledu, to o čem jsme se teď zhruba hodinu a více povídali, jsou zkušenosti, které máš za sebou a zažíváš. Myslím si, že v Olomouci se to možná vůbec nenosí, ale máš titul Senior Software Engineer a z pragocentrického pohledu máš i dost zkušeností.

Kdybys mohl poslat sám sobě pár rad v čase, totiž lidem, kteří nás poslouchají a jsou tam, kde jsi byl před čtyřmi, pěti lety, a kdybys jim mohl dát takovou časovou schránku s několika radami a důležitými milníky, co by to bylo? Co si z toho všeho odnášíš?

Nebojte se dělat chyby. Chybami se člověk učí. My jsme začali hodně stylem „pojďme to tam nějak napráskat a uvidíme“, ale zjistili jsme později, že existuje i druhý přístup – všechno si rozmyslet, nadefinovat, napsat a probrat s byznysem. Myslím si, že i kdybychom na tom měli o dva, tři roky více, na tom je sice krása, ale neposunuli bychom se tolik, jako když jsme do toho vletěli trochu po hlavě.

Důležité je mít někoho, kdo vás trochu koriguje, což byl Běhav, za což mu strašně děkujeme, protože byl a je skvělým partnerem, který nás obrovsky pomohl. Sami bychom to určitě nezvládli. Jeden seniorní člověk je tedy vždy potřeba, ale to je dostatečné. Dá se to zvládnout i s malým týmem.

Obrovsky důležitá je důvěra managementu, ale to by byla asi ta největší kolejnice – nebát se dělat chyby. Často věci, které v úvozovkách zahodíte, protože nebyly dokonale promyšlené, použijete později na jiné věci a už je v podstatě máte hotové, nemusíte je vymýšlet znovu.

Děkuji moc a držím palce, aby všechny chyby, které budete nebo budeš dělat v budoucnu, přinášely benefity a ponaučení. Děkuji, že jsi s námi sdílel vaši cestu. Držím palce.

Já děkuji za pozvání, děkuji.

A to je všechno. Díky, že jste doposlouchali až sem. Děkujeme také našim partnerům: BigHubu, Intexu, Sazce, Bystrýtu, Colors of Data, Revolt BI, Gooddatě, Kebulé, E-marku, Karol Data Company a Datamindu.

Pokud vás zajímá více, navštivte naše stránky datatalks.cz a přihlaste se k odběru našeho newsletteru.