Podcast

Ahoj, zdraví vás Jirka Vicherek a vítám vás u dalšího dílu Data Talku. Data Talk je podcast, který natáčím se sympatickými a velmi chytrými odborníky z oblasti datových technologií. A jednoho takového teď mám naproti sobě, a to Jirka Štojera. Ahoj, Jirko.

Ahoj, Jirko.

Jirka k nám přišel ze společnosti Embed.it, kde už drahně let působí jako architekt, který má na starosti aplikace, data a zejména machine learning. A právě o MLOps a o jedné věci, která se jmenuje Feature Store, se tady dneska budeme bavit. Já to několikrát v našem podcastu přejmenuji na Future Store, protože si myslím, že to je jedna z tul budoucnosti.

Než se ale vrhneme na to, jak si v Embeditu postavili vlastní Feature Store, co Feature Store je a proč je to důležitá věc, o které byste měli vědět, tak by mě zajímalo, Jirko, jak jsi vlastně k tématu machine learningu a dat přišel, jaká byla tvoje cesta, ať víme, kdo tu s námi je.

Děkuji za slovo. Já jsem začal pracovat s počítačem někdy v roce 1986 na Commodore 64. Na střední škole jsem pokračoval v programování v C++ a také v programování masemleru. Konečně na vysoké škole, díky dobrým kantorům, jsem se dostal k tématu i neuronových sítí, ať už to bylo rozpoznávání textu, genetické algoritmy pro řízení ramena robota, nebo experimenty s umělými neuronovými sítěmi, kde jsem zkoušel různé typy aktivačních funkcí. To byly v podstatě začátky.

Ve chvíli, kdy jsem nastoupil do klasického pracovního procesu, nastupoval jsem jako programátor a časem jsem se vypracoval na architekta.

A co byla tvoje první programátorská práce? Nějaký e-shop v PHP?

První programátorská práce byla v C++. Byl to v podstatě nějaký malý sklad, to bylo ještě na střední škole. Možná zajímavější věci přišly v praxi v bance, kde se používaly aproximativní metody v rámci odhadů chování klienta, scoring klienta. Všechno se to většinou točilo kolem schvalování úvěrů, poskytování úvěrů, identifikace fraudů. To jsou témata, která mi jsou blízká.

A jak vlastně vznikla u vás potřeba Feature Store?

Ve chvíli, kdy jsme se podívali na rychlost vývoje modelů a na naše ambice tvořit modely nejen pro riziko, ale i pro sales, next best offer, next best action, a chtěli jsme kvalitu modelů posunout dál, tak jsme hledali cestu.

Jak vypadal tým v té době?

Já jsem na straně IT, a prakticky jsem protihráčem vůči risku, což je pro nás business. Business tvoří modely pro risk-based pricing, což znamená, že ti řeknou, jakou dostaneš cenu podle toho, jak se chováš – podle historie, příjmu, počtu členů domácnosti a tak dále. Ty modely jsou běžně postavené na rozhodovacích stromech a tvorba stromů, tedy podmínky, které do stromu vložíš, jsou součástí nějakého mining procesu, na jehož základě strom vzniká. To je typický scénář.

Důvod, proč jsme se začali zabývat tématem Feature Store, byl velmi jednoduchý. Potřebovali jsme být efektivnější, chtěli jsme rychleji dodávat nové modely a proto jsme si navrhli nějaký koncept, aniž bychom tehdy věděli, že to bude blízké Feature Store, a začali jsme ho rozvíjet.

Zjistili jsme ale, že interní vývoj by pro nás byl příliš náročný, a proto jsme se dívali po technickém řešení na trhu. Zaujal nás koncept Feature Store a asi před rokem a půl jsme se mu začali intenzivně věnovat.

A co byl první krok? Čím vás koncept Feature Store zaujal? Co sliboval, co vám „chytilo uši“?

Hlavním důvodem bylo, jak jsem říkal, zpomalení vývoje. Potřebovali jsme zrychlit dodávku modelů, také chtěli uchovat data z předchozích modelů, vidět, jak byly napočítávané prediktory a jak dopadly modely z hlediska výsledného score. To byly motivy, proč jsme do toho šli.

Dalším velmi důležitým faktorem byla údržba modelů. Když vyvineš model a nasadíš ho do produkce, časem degraduje, protože se mění chování uživatelů – z politických důvodů, kvůli inflaci nebo čemukoliv jinému. Modely proto musíš časem udržovat a přizpůsobovat či kalibrovat. Při pomalém vývoji modelů není údržba v nejlepší kondici, proto potřebuješ čas a efektivitu, aby všechno šlo rychleji.

Stále mluvíme o efektivitě a zkracování „delivery cyklu“. Navíc, když chceš rozšířit své machine learningové aktivity nejen na riziko, ale i na frody, identifikaci nestability provozních systémů, nebo na sales – next best offer, next best action, zjistíš, že potřebuješ tým rozšířit klidně dvakrát, třikrát. Pokud lidi nemáš a jsi neefektivní, hledáš cesty – jednou z nich byl právě Feature Store.

Co Feature Store vlastně umí?

Má několik vlastností. První, vytvoří metadatovou strukturu, která popisuje model, vstupní data sloužící k vypočtu score, napočtené prediktory a všechny položky, které verzuje. Jestliže je to meta repository, můžeš toto repository promítnout do fyzického modelu.

Velmi důležité je propojení offline a online částí tvorby machine learningu. Offline část znamená práci s historickými daty, trénink modelu, kontrola jeho fungování. Online část je jeho nasazení a běh v reálném čase. Tyto světy nejsou zcela spojeny, převést offline do online je obtížné. Feature Store v tom pomáhá.

Druhá věc je historizace repository a vstupních dat. V datovém skladu není historizace věcí defaultních – není to jen držení časových razítek, ale i správa verzí. Dá se říct, že potřebuješ do dat přinést něco jako „git“ na úrovni kódu, umožňující spravovat a nasazovat změny do produkce a zároveň je používat v offline.

Jaký byl tedy první krok u vás? Co byla největší bolest, kterou jste řešili? Historizace a metadata? Uchování modelů? Nebo jen ukládání a sdílení modelů mezi sebou?

Šlo opravdu o efektivitu a repository pro machine learning. Máme repository pro vstupní data, uděláš scoring, víš, jak klient dopadl, to se uchovává, ale určitě potřebuješ uchovávat i mezivýpočty – tedy podrobné hodnoty jednotlivých prediktorů, vstupních proměnných do modelů. To je velmi důležitá informace, protože když začínáš dělat nové modely, musíš je porovnat se starými, aby bylo jasné, zda je performance nového modelu lepší nebo horší. To je součást životního cyklu modelu, ověřování, zda výsledek odpovídá vynaloženému úsilí.

Takže to byla první funkcionalita, kterou jste hledali nebo vyvinuli sami, pokud nebyly dostupné komerční řešení?

Přesně tak, byla to historizace hodnot. Druhé klíčové téma, pravděpodobně stále aktuální, je přechod z vývojové fáze modelu do produkční. To znamená možnost škálovat modely v produkci, a to jsou pak věci jako kontejnerizace, škálování a podobně.

Třetí či čtvrtá věc, velmi blízká, je možnost realizace nápočtových pipeline, správa MLOps. Tam dominují témata jako continuous integration a continuous delivery. V rámci Feature Store se k tomu přidává continuous training a continuous monitoring, díky ukládání předchozích modelů v repository. Jde o uzavřený cyklus, který umožňuje efektivní tvorbu modelů, jejich monitorování, sledování driftu a degradace, a efektivní řešení retrénování modelu.

Jaké máte právě vy řešení? Jak váš Feature Store vypadá?

Nejdříve jsme uvažovali o vlastním řešení, ale kvůli nákladům a vysoké pracnosti jsme se nakonec rozhodli pro komerční řešení. Provedli jsme velké cvičení, vybírali jsme zhruba z 20 firem. Výběr jsme zúžili na pět firem, se kterými jsme reálně jednali a pořídili POC, aby nám odpověděly na naše požadavky.

Nakonec jsme realizovali reálné proof of concept se dvěma firmami a vybrali řešení, které nám nejvíce vyhovovalo z hlediska škálovatelnosti, vlastností a zkušeností během testování v našem prostředí.

Měli jsme specifické požadavky, protože naše řešení je primárně on-prem, tedy ne cloudové. To je pravděpodobně kvůli zaměření na Asii, kde jsou GDPR podobné regulace velmi přísné. Proto jsme zvolili řešení provozované na vlastní on-prem platformě.

Takže jste si nekonstruovali in-house systém, ale koupili hotový produkt?

Ano, koupili jsme „krabici“, kterou nyní začínáme používat. Díky dlouhému POC, trvajícímu více než pět měsíců, máme jistotu, že využití Feature Store není jen na papíře, ale přinese reálné výsledky.

Když zpětně nahlédneš na firmy vaší velikosti, máš nějaké poznatky nebo lessons learned? Je těch pět firem fakt dobrých? Existuje mnoho nevyřešených problémů kvůli relativní novosti trhu? Na co si dát pozor? Nějaký insight?

Stoprocentně. Oblast Feature Store není stará – je to tři, čtyři roky – takže je relativně nová. Vyplatí se investovat do POC, které opravdu splní vaše požadavky.

Je naivní si představovat, že konzultantská firma vám řekne: vyber si jeden z tří produktů. Toto téma je nové a mnoho firem s ním stále neumí pracovat. Konzultanti často fungují na základě starších projektů, kde Feature Store nebyl běžným nástrojem. Proto doporučuji mít vlastní POC, definovat si klíčové požadavky podle vás a testovat řešení na reálných příkladech i prostředích.

Jaká byla nesplněná očekávání? Myslel jsi si, že technická řešení už budou schopna zvládat více, ale je tam stále raná fáze? Případně, že je váš use case stále poměrně malý?

Jsem pragmatik, a proto si dávám velmi malé cíle. V rámci POC jsme definovali asi 70 use caseů, které jsme testovali – integrace, tvorba pipeline, práce s velkými daty, test stability řešení. Dvě testovaná řešení jedno dopadlo hůře, druhé lépe.

Mohu říct, že žádné nesplněné očekávání nebyly. Možná spíše z naší strany, v rámci firmy, ohledně naší flexibility či neschopnosti. Nicméně samotné nástroje mě nijak nepřekvapily nebo nesklamaly, splnily očekávání.

Přejděme k nejzajímavější části. Implementovali jste nástroj, zvětšili produkční pipeline, vyřešili problémy, které vás trápily. Jak se práce před a po implementaci liší? Co je třeba nastavit v týmu? Předpokládám, že je to i o mindsetu - od vlastního, uzavřeného řešení k transparentnosti a viditelnosti dat. Jaké zkušenosti máte?

Reálné zkušenosti pravděpodobně budeme mít za rok, protože jsme právě ukončili výběrové řízení, vybrali dodavatele a nyní implementujeme řešení do našeho prostředí.

Zkušenosti z fáze výběru ale už máme. Když jsme spočítali přínosy, hlavně co se time to market týče, věříme, že přínosy budou dvě až šestkrát rychlejší dodávka modelů. To je pro nás velký posun.

Ovšem není to jen o Feature Store samotném. Pokud chce někdo být efektivní v machine learningu, musí začít u dat, datové strategie, mít data dostupná a v rozumné kvalitě. Pak může přistoupit k automatizaci, tvorbě pipeline a ML ops. Zde přijde na řadu potřeba Feature Store jako úložiště hodnot a jednoduchý deployment do produkce.

Bez řešení datové strategie nelze efektivně pokračovat.

Takže je potřeba mít v organizaci zralý ML ops?

Ve většině firem by stačilo, kdyby se více zaměřili na data a datovou gramotnost. To znamená znalost a povědomí o práci s daty. Není to jen o tom mít data v dataliku, ale také o kvalitě dat, stavech dat, použití ve specifických use casech, popisu dat – to je základ.

Když dostanu data, která nebudou dobře popsaná nebo kvalitní, vznikne bottleneck v celém zpracování. Nebo výsledky budou degradovány.

Je toto součástí vaší datové strategie? Několikrát jste zmínil výraz „datová strategie“. Co to znamená u vás? Nějaký dokument, vizí, sadu priorit?

Datovou strategii jsme tvořili s konzultantskou firmou. Šlo o vydefinování aktuální pozice, jak jsme na tom s požadavky jednotlivých útvarů, zhodnocení naší maturity, kam se chceme posunout v krátkodobém i dlouhodobém horizontu. Popsat aktuální problémy, slabiny a oblasti, kde je třeba zabrat.

To byla podmínka pro efektivitu v machine learningu.

Co z toho vyplynulo? Představme si, že průměrná délka tvorby modelu je 10 měsíců. Pokud chcete škálovat desetkrát, musíte ten cyklus zkrátit třeba na 2 měsíce?

Nebo je to obecnější?

Když se zaměřím na datovou strategii, týká se to budoucnosti používání federovaných dotazů. Řešíme, kam se chceme dostat s datalikem – jestli bude cílovým řešením, jestli chceme zůstat on-prem nebo jít do cloudu. To jsou všechna...

Otázky, na které odpovídá datová strategie a fakticky i vymezuje, které systémy jsou pro co, nejsou o tom, že by existovalo jedno řešení, například nazvané Elon Musk Metrics, do kterého uložíte všechna data a které by splnilo veškeré use cases.

Je to o tom, že například i pozice stávajícího datového skladu (DVH), pozice dataliku (data lake), pozice datových analytiků (dataliku), nástrojů pro reporting, pohledy na práci s nestrukturovanými daty – to všechno jsou use cases nebo nástroje, které mají své opodstatnění dnes a vyvíjejí se v čase. Stejně jako se objevují nová témata, jako jsou distribuované dotazy (distributed query) nebo virtuální data (virtual data), tak to představuje budoucnost datové oblasti, na kterou se chceme připravit.

Proto jsme si řekli, kdy pro nás začnou být tato témata zajímavá, co musíme ve firmě změnit, abychom v těchto oblastech mohli být efektivní, a jak to zároveň použít pro denní rutinu. To znamená, jak to využít pro témata jako strojové učení (machine learning) a jak to všechno spolu souvisí.

Není to tedy jen o datech samotných, není to o tom, abych si zde vytvořil data, ale abych splnil očekávání byznysu: abych vytvořil nové případy použití, zvýšil míru přijetí (take-up rate), zvýšil prodejnost a příjmy.

Když se na to podívám z vaší zkušenosti, jaké konkrétní věci z toho vyplynuly?

Jednoznačně budoucí cesta směřuje do cloudu. Dále virtuální datový sklad a nutnost zabrat v oblasti správy dat (data management), což znamená popisy dat, slovníky, datové modely – to je potřeba řešit. Samozřejmě je také důležité budovat a shromažďovat data na relevantních místech, tedy posunout kvalitu data lake o úroveň výš.

A naopak, v čem jste byli silní? Na co jste mohli být hrdí, když se zaměříte na vaši datovou strategii? Bylo to něco, na co jste mohli být skutečně pyšní, nebo je to spíše standardní OKR s tím, že všechno musí jít vzhůru?

Myslím, že firma Embedit může být hrdá na to, jak jsou tam lidé zapálení – jak jsou to opravdoví srdcaři, jak dokáží zabrat a být samostatní. V této energii firmy vidíme obrovské plus.

Firma navíc nabízí velké množství příležitostí, což lze vnímat jako výhodu i nevýhodu, ale já to považuji za velmi pozitivní věc. Velkým benefitem je její rozsah – není to jen Česká republika, ale i Asie a reakce na různé další trhy.

Za mě je tedy těžké vybrat nějakou oblast, ve které bychom excelovali, spíše bych zdůraznil ty příležitosti.

Jak velký tým se o tuto oblast stará? Kolik lidí se zabývá feature storem? Kolik má uživatelů? Kdo to využívá?

Ve firmě Embedit je to přibližně deset lidí na straně firmy. K tomu je nutno připočítat týmy v jednotlivých zemích, které vytvářejí lokálně specifické modely. Samozřejmě, na straně IT je tým, který se stará o feature store nebo se starat bude – protože momentálně probíhá implementace do produkce a tento tým teprve vzniká. Je relativně malý, ale očekáváme, že ve chvíli, kdy se založí kompetenční centrum, bude tým růst.

Na co všechno je feature store napojený?

Z pohledu use case, což je asi nejdůležitější hledisko, bývá feature store napojený především na rizikové procesy, například risk based pricing, tedy tvorbu ceny pro koncové uživatele.

Dále je to podpora sales, například tvorba „next best offer“ nebo „next best action“. Jakmile je tato oblast pokrytá, často se jdou další kroky do oblasti boje proti podvodům (fraudu) nebo do HR, případně do provozu, kdy se identifikují třeba nestability řešení v daných lokalitách a přepíná se do jiných řešení nebo lokalit.

Použití je skutečně široké. Obecně bych řekl, že feature store podporuje efektivitu v oblasti machine learningu. Ať už si vyberete jakoukoliv oblast strojového učení či umělé inteligence, pokud chcete být efektivní a tvořit modely, budete potřebovat modely historizovat a vytvářet pipeline, které nejsou jen o MLOps, ale o rychlém nasazení modelů do produkce. V tom velmi výrazně pomáhá právě feature store.

Moje otázka je teď stále: od jaké velikosti či maturity organizace, nebo počtu lidí či týmu, má smysl feature store zavádět? Předpokládám, že startupy s 20 lidmi, kde je jeden data scientist a jeden BI analytik, by to zatím asi nebylo efektivní.

Já bych to nespojoval tolik s velikostí týmu, ale spíše s efektivitou dodávky modelů. Pokud dnes někdo dodává modely půl roku, rok, i dva roky, je to špatně.

Pokud si někdo řekne, že by chtěl model dodat rychleji, kdyby měl k dispozici data správně popsaná, kdyby mohl proces spouštět automaticky a kdyby bylo možné nasadit model do produkce jednoduše, například stiskem jednoho příkazu, to je ta cesta.

Feature store pak může být vhodný pro velké korporáty, které řeší next-best pricing, i pro malé startupy zaměřené na front-end klienta na mobilním zařízení – zkrátka pro kohokoliv.

Je tu ještě důležitá otázka, kterou jsme nezmínili – často se ptají, jak feature store porovnat s datovým skladem, jaký je mezi nimi rozdíl.

Já sám jsem se tím zabýval a vyhodnotil čtyři, pět oblastí, které jsou důležité.

Co se týká datové kvality, datový sklad typicky řeší duplicity v datech, kontrolu správného typu dat, zda jsou pole povinná nebo nepovinná.

Feature store naopak řeší data jiným způsobem – sleduje, jak jsou data distribuována v čase, zda tam nejsou „díry“, zhluky dat nebo odchylky v datech z pohledu minimálních a maximálních hodnot.

Z toho je vidět, že z pohledu datové kvality je pohled detailnější a jiný.

Dále, co se týká řešených úloh, tak v oblasti datových skladů se používá hlavně SQL, Spark, Impala a pracuje se s velkými objemy dat.

U feature store však kromě SQL často používám Python a machine learningové algoritmy.

Nejde jen o seskupování a agregaci dat, ale například o přepočet měřítek na logaritmické škály, interpolaci hodnot, výpočet směru dodaných dat, vlastní scoring a další.

Takže i v řešených úlohách je jasný posun oproti klasickému datovému skladu.

Pokud jde o uložení dat, klasicky...

(což už nebylo úplně dokončeno, poznámka vynechána).

Co to znamená v reálném používání? Toto, co říkáte, svým způsobem znamená, že už pracujeme s real-time daty – to je více než pouze historická data.

A to vyžaduje agilnější přístup a schopnost měnit věci za chodu.

Mám pocit, že jde o přechod od klasického „waterfall“ přístupu k agilnímu, protože už nestačí jednou systém postavit, nechat dva roky běžet a pak refaktorovat, ale potřebujeme průběžně a agilně měnit a vylepšovat.

Je v této oblasti mindset změny nebo ho tam jen vidím?

Myslím, že ho tam vidíte správně.

Ve chvíli, kdy model nasadíte do produkce, průběžně ho monitorujete.

Můžete zavčas identifikovat, že nejen výsledné skóre modelu se posunulo, ale i jednotlivé prediktory se v čase mění.

To umožňuje automatizovat některé procesy a dělat věci efektivněji.

Například data z produkce se automaticky dostávají do data lake a feature store a featury jsou automaticky přepočítávány.

Není tedy potřeba znovu parsovat data a počítat prediktory týdny, protože je to kontinuální proces.

To podporuje rychlou dodávku a umožňuje zapomenout na některé rutinní věci, protože jsou „mark by default“.

To je příjemné – dává vám víc času věnovat se zajímavější práci, tedy samotným modelům?

Přesně tak.

Díky efektivitě mohou týmy zaměřit pozornost na kvalitu dat, nové machine learningové oblasti a další činnosti.

To je podle mě jeden z trendů, kam se bude téma feature storu vyvíjet.

Pokud přemýšlíme o budoucnosti, o tématech jako digitální dvojčata (digital twins), federované strojové učení (federated machine learning) či další témata spojená s ML, všude bude potřeba efektivity.

Nikdo nebude chtít, aby se modely tvořily dlouho.

Každý bude chtít rychlé výpočty, často mimo klasické CPU s využitím grafických karet (GPU), rychlý přístup k datům a to feature store umožňuje.

Kdybyste feature store řešili pouze v data lake, zjistíte, že tam máte hromady dat, se kterými ale nepracujete.

Protože se při tvorbě modelů často pracuje jen s několika procenty dat z data lake.

Proto dává smysl mít vedle data lake i jiné řešení pro tvorbu machine learningových modelů.

Tam můžete mít úplně jinou výkonnost, využívat nejen SQL, ale i Python a GPU.

U vstupně-výstupních (I/O) operací můžete nastavit libovolný replikační faktor, například osm až deset, na rozdíl od běžného datového skladu, kde je replikace většinou trojité.

Můžeš uvést příklad z vašeho POC (proof of concept), kdy se ti tohle hodilo a zachránilo to situaci?

V POC jsme se tímto zatím moc nezabývali, protože jsme měli diskrétní příklady, které jsme chtěli pokrýt.

Ale do budoucna, když chceš tvořit modely a testovat jejich stabilitu na delších datech, například třech až pěti letech, často přes více domén, víš, že výkon potřebuješ.

Někdy potřebuješ hodiny nebo dny na výpočet nějakých prediktorů.

Navíc u hyperparametrizace modelu, kdy spouštíš model s různými parametry několikrát, se výpočet protahuje.

Při strojovém učení často hledáš korelace, závislosti a opět potřebuješ výpočetní sílu, která bývá ideálně na big data platformě.

Ty výsledky pak ukládáš ve feature store a víš, že můžeš být efektivní s automatickými alerty, například když model degraduje a zhoršuje se ziskovost.

Kolik modelů máte nyní ve feature store?

Momentálně jsme ve fázi POC, takže produkčních modelů v feature store ještě nemáme.

Obecně ale v rámci HomeCreditu je to kolem 200 modelů.

Zmíníš-li implementaci feature store, plánujete počet modelů rozšířit?

Máme asi 200 modelů, každý má desítky variant a historických verzí.

S feature storem budeme chtít začít i modely pro sales a další oblasti, takže při stejném týmu zvládneme více modelů.

To je motiv, proč do toho jdeme.

Na které use cases se těšíš nejvíce? Na které si „vroucíš zuby“?

Myslím, že ty nejzajímavější ještě přijdou.

Spíš jde o věci v pipeline podle Gartnerova hypercyklu.

Na začátku potřebujeme vytěžit stávající data, není to o revolučních modelech, ale o efektivním využívání toho, co máme.

To potřebuje většina firem – efektivně využít stávající data a potom se začít věnovat i nestrukturovaným datům a postupovat dál.

To vnímám podobně – přichází éra efektivity.

Šli jsme do škály, sbírali jakákoliv data a hledali vhodné metody, teď se modely stávají komoditou a přístupy jsou v knihovnách.

Otázka efektivity a implementace je nyní na pořadu dne – stojí to energii a ta energie je dražší.

Když se podívám na budoucnost, proč se tímto tématem zabývat: podle Gartnerovy studie by v roce 2025 mělo v oblasti MLOps a feature store být investováno asi 5 až 10 miliard dolarů.

To je jeden indicátor.

Dále, když se podíváme na Gartnerův hypercyklus v oblasti umělé inteligence, vidíme řadu nových témat.

Stejně tak je vidět, že firmy, jako AWS, LinkedIn, Harvey Nash a mnoho dalších, začaly implementovat vlastní feature store nebo používat standardní řešení.

Je zde silný zájem investorů – například firma Iguazio, která se těmito tématy zabývá, získala v minulém roce investici ve výši přibližně 76 milionů dolarů.

Na začátku roku 2022 firma Tekton získala investici 100 milionů dolarů.

To jsou jasné indikátory vzestupu a rostoucího zájmu o problematiku.

Nejde o několik jednotek firem, ale o masivní zájem a velké množství společností.

Jsou ještě nějaké buzzwordy, které můžeme zadat do vyhledávače pro hlubší průzkum?

Nemyslím nějaké složité termíny, ale pokud dnes zadáte „Feature Store“ nebo „Feature Store org“, najdete desítky firem, které se tímto tématem zabývají – buď vyvíjejí vlastní řešení, nebo implementují komerční produkty.

Jsou ještě nějaké další zásadní věci týkající se feature storu, které jsme zatím nezmínili a neměli bychom vynechat?

Možná jsme nesdělili jednu důležitou věc, která se týká pohledu na real-time zp...

(text končí nedokončeně)

Pracování nebo možná uložení dat. Často, když se bavím s koncovými uživateli, tak někdy je pohled na nové technické řešení jako na zázrak, který přijde do firmy a spasí úplně všechno. Najednou má Feature Store nahradit RTODS-ku, skoro by se dalo říct, že má za tebe vysávat, vařit a já nevím, co všechno.

Já bych tyto věci klidnil a řekl bych, že skutečně neplatí, že si pořídím nové univerzální kladivo na všechno. Ať si pořídím cokoliv, má to nějaké specifické omezení, je to v něčem dobré, v něčem je to neefektivní.

Za mě je velmi důležité se trošku podívat i na tu architekturu, kde jednotlivá řešení, a konkrétně ten Feature Store, mají přidanou hodnotu, kde skutečně něco mohou nahradit, versus kde ho nechci použít, protože je to řešení neefektivní a nevhodné.

Takže třeba jako ODS-ku ho nechci použít? Stoprocentně ho nechci použít jako ODS-ku, stoprocentně ho nechci použít jako komplexní processing řešení, kde se budou zpracovávat miliardy záznamů, stoprocentně ho nechci použít jako OSBčku a dalo by se pokračovat.

Je třeba korigovat tyto vášně, že je to super řešení, ale skutečně to není rovné kladivo, kterým rozbijete úplně všechno.

To jsem rád, že to říkáš, protože někteří vendoři to rádi o svých řešeních říkají.

Co vás teď čeká? Jaké další kroky implementujete? Jak ten projekt vypadá?

Aktuálně děláme deployment do produkčního prostředí toho řešení a budeme dělat integraci, to znamená napojení na datový sklad, napojení na datové lake, vazbu na bezpečnostní systémy – takové ty standardní věci, které se řeší.

A můžu se ještě zeptat, když tady tak probíráme, můžeš nám říct ten stack, na který to napojujete, a jak to vlastně probíhá?

My jsme si vybrali řešení, které podporuje federated query, a díky tomu by integrace měla být pro nás jednodušší. To znamená, že integrace, ať už je to na Oracle DB, integrace na Hadoop nebo integrace na Kafka, případně cokoliv dalšího, by měla být pro nás jednodušší a měli bychom být efektivnější v čase.

Takže ten technologický stack je kromě standardních databází, Big Data platformy a Kafka, pak...

A to je vlastně všechno, protože to je pro nás nejdůležitější. Ostatní věci, na které se budeme napojovat, nejsou tak důležité pro byznys firmy, jsou spíše zajímavé z pohledu korporátních standardů, například zajistit vazbu na Active Directory, zajistit vazbu na IDM, řešit logy, monitoring, řešit bezpečnost přes Square Radar, ale to nejsou byznysová témata.

Byznysová témata jsou skutečně vazba na datové lake, vazba na realtime a nějaké kontrivence.

Super, držím vám moc palce, ať se vám podaří nasadit Feature Store a poté dělat násobně více modelů v násobně vyšší kvalitě za zachování počtu členů týmu.

Děkuji moc, Jirko, že jsi udělal čas.

Taky děkuji, Jirko, za pozvání a přeji pěkný den.

Děkuji, že jste doposlouchali Data Talk až sem. Jak se vám tato epizoda líbila? Co byste na našem podcastu zlepšili? Koho pozvat příště? Dejte mi prosím vědět, co si myslíte.

A to můžete buď osobně na příštím Datameš Meetupu, nebo hned teď na email jirka@datatalk.cz.

A pokud se vám tato epizoda líbila, doporučte ji prosím dále. Klikněte na srdíčka, na hvězdičky, dávejte subscribe, ať nám svítí dashboardy zeleně, křivky dělají hokejku a všichni stakeholdeři schvalují extra rozpočty.

Ještě jednou vám děkuji. Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu Big Hub, Deep Note, Atakama a Manta.

Pokud máte návrh, nějaké tipy na hosty nebo témata, děláte vlastní akci, nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět. Děkuji.

Nechť vás provází data.