Nápady a stretnutia o tom, aké ďalšie procesy je možné automatizovať, vznikajú v podnikoch rôznych veľkostí každý deň. Ale okrem toho, že pri vytváraní modelu možno stráviť veľa času, musíte ho venovať aj jeho vyhodnocovaniu a kontrole, či získaný výsledok nie je náhodný. Po implementácii musí byť každý model monitorovaný a pravidelne kontrolovaný.
A to sú všetky fázy, ktoré je potrebné absolvovať v každej firme bez ohľadu na jej veľkosť. Ak hovoríme o rozsahu a dedičstve Sberbank, počet doladení sa výrazne zvyšuje. Do konca roka 2019 už Sber používal viac ako 2000 XNUMX modelov. Nestačí len vytvoriť model, je potrebné integrovať sa s priemyselnými systémami, vyvinúť dátové trhy pre budovanie modelov a zabezpečiť kontrolu jeho prevádzky na klastri.
Náš tím vyvíja platformu Sber.DS. Umožňuje riešiť problémy strojového učenia, urýchľuje proces testovania hypotéz, v princípe zjednodušuje proces vývoja a validácie modelov a tiež kontroluje výsledok modelu v PROM.
Aby som neklamal vaše očakávania, chcem vopred povedať, že tento príspevok je úvodný a pod rezom, na začiatok, hovoríme o tom, čo je v zásade pod kapotou platformy Sber.DS. Príbeh o životnom cykle modelu od vytvorenia až po implementáciu si povieme samostatne.
Sber.DS pozostáva z niekoľkých komponentov, z ktorých kľúčové sú knižnica, vývojový systém a systém vykonávania modelov.
Knižnica riadi životný cyklus modelu od momentu, keď sa objaví nápad na jeho vývoj, až po jeho implementáciu v PROM, monitorovanie a vyradenie z prevádzky. Mnohé funkcie knižnice sú diktované pravidlami regulátora, napríklad vykazovanie a ukladanie vzoriek školenia a overovania. V skutočnosti je to register všetkých našich modelov.
Vývojový systém je určený na vizuálny vývoj modelov a validačných techník. Vyvinuté modely prechádzajú počiatočnou validáciou a sú dodávané do vykonávacieho systému, aby mohli vykonávať svoje obchodné funkcie. V runtime systéme môže byť model umiestnený na monitore za účelom periodického spúšťania validačných techník na monitorovanie jeho prevádzky.
V systéme je niekoľko typov uzlov. Niektoré sú určené na pripojenie k rôznym zdrojom údajov, iné sú určené na transformáciu zdrojových údajov a ich obohatenie (označenie). Existuje veľa uzlov na vytváranie rôznych modelov a uzlov na ich overovanie. Vývojár môže načítať údaje z akéhokoľvek zdroja, transformovať, filtrovať, vizualizovať prechodné údaje a rozdeliť ich na časti.
Platforma obsahuje aj hotové moduly, ktoré je možné presúvať myšou na plochu dizajnu. Všetky akcie sa vykonávajú pomocou vizualizovaného rozhrania. V skutočnosti môžete problém vyriešiť bez jediného riadku kódu.
Ak vstavané možnosti nestačia, systém poskytuje možnosť rýchleho vytvárania vlastných modulov. Vytvorili sme integrovaný vývojový režim založený na
Architektúra Sber.DS je postavená na mikroslužbách. Existuje veľa názorov na to, čo sú mikroslužby. Niektorí ľudia si myslia, že stačí rozdeliť monolitický kód na časti, no zároveň idú stále do tej istej databázy. Naša mikroslužba musí komunikovať s inou mikroslužbou iba cez REST API. Žiadne riešenia na priamy prístup k databáze.
Snažíme sa zabezpečiť, aby sa služby nestali veľmi veľkými a nemotornými: jedna inštancia by nemala spotrebovať viac ako 4 – 8 gigabajtov RAM a musí poskytovať možnosť horizontálneho škálovania požiadaviek spustením nových inštancií. Každá služba komunikuje s ostatnými iba cez REST API (
Jadro aplikácie je napísané v jazyku Java pomocou Spring Framework. Riešenie bolo pôvodne navrhnuté pre rýchle nasadenie v cloudovej infraštruktúre, takže aplikácia bola postavená pomocou kontajnerového systému
Jednou z funkcií našej platformy je, že môžeme spúšťať kód vyvinutý vo vizuálnom rozhraní na akomkoľvek systéme vykonávania modelov Sberbank. Teraz sú už dva z nich: jeden na Hadoop, druhý na OpenShift (Docker). Nezastavíme sa pri tom a vytvoríme integračné moduly na spustenie kódu v akejkoľvek infraštruktúre vrátane lokálnej a cloudovej. Vzhľadom na možnosti efektívnej integrácie do ekosystému Sberbank plánujeme podporovať aj prácu s existujúcimi exekučnými prostrediami. V budúcnosti môže byť toto riešenie flexibilne integrované „out of the box“ do akéhokoľvek prostredia akejkoľvek organizácie.
Tí, ktorí sa niekedy pokúsili podporiť riešenie, ktoré spúšťa Python na Hadoop v PROM, vedia, že nestačí pripraviť a dodať používateľské prostredie Pythonu do každého dátového uzla. Obrovské množstvo knižníc C/C++ pre strojové učenie, ktoré využívajú moduly Python, vám nedovolí byť pokojní. Pri pridávaní nových knižníc alebo serverov musíme pamätať na aktualizáciu balíkov, pričom musíme zachovať spätnú kompatibilitu s už implementovaným modelovým kódom.
Existuje niekoľko prístupov, ako to urobiť. Napríklad vopred pripraviť niekoľko často používaných knižníc a implementovať ich do PROM. V distribúcii Hadoop spoločnosti Cloudera zvyčajne používajú
Banka berie bezpečnosť spustenia kódu tretích strán veľmi vážne, takže maximálne využívame nové funkcie linuxového jadra, kde proces bežiaci v izolovanom prostredí
Tento rok plánujeme dokončiť MVP spúšťania modelov napísaných v Pythone/R/Java na Hadoop. Dali sme si ambicióznu úlohu naučiť sa spúšťať akékoľvek vlastné prostredie na Hadoop, aby sme nijako neobmedzovali používateľov našej platformy.
Okrem toho, ako sa ukázalo, mnohí DS špecialisti sú vynikajúci v matematike a štatistike, vyrábajú skvelé modely, ale nie sú veľmi zbehlí v transformáciách veľkých dát a pri príprave tréningových vzoriek potrebujú pomoc našich dátových inžinierov. Rozhodli sme sa pomôcť našim kolegom a vytvoriť pohodlné moduly pre štandardnú transformáciu a prípravu funkcií pre modely na motore Spark. To vám umožní stráviť viac času vývojom modelov a nečakať, kým dátoví inžinieri pripravia nový súbor údajov.
Zamestnávame ľudí so znalosťami v rôznych oblastiach: Linux a DevOps, Hadoop a Spark, Java a Spring, Scala a Akka, OpenShift a Kubernetes. Nabudúce si povieme niečo o knižnici modelov, ako model prechádza životným cyklom v rámci firmy, ako prebieha validácia a implementácia.
Zdroj: hab.com