Ideid ja kohtumisi selle kohta, milliseid muid protsesse saaks automatiseerida, tekib erineva suurusega ettevõtetes iga päev. Kuid lisaks sellele, et mudeli loomisele saab kulutada palju aega, peate kulutama selle hindamisele ja kontrollimisele, et saadud tulemus pole juhuslik. Pärast rakendamist tuleb iga mudelit jälgida ja perioodiliselt kontrollida.
Ja need on kõik etapid, mis tuleb läbida igas ettevõttes, olenemata selle suurusest. Kui me räägime Sberbanki ulatusest ja pärandist, suureneb peenhäälestuste arv märkimisväärselt. 2019. aasta lõpuks oli Sber kasutanud juba üle 2000 mudeli. Ei piisa pelgalt mudeli väljatöötamisest, tuleb integreerida tööstussüsteemidega, välja töötada mudelite ehitamise andmemargid ja tagada selle toimimise kontroll klastris.
Meie meeskond arendab Sber.DS platvormi. See võimaldab lahendada masinõppe probleeme, kiirendab hüpoteeside testimise protsessi, põhimõtteliselt lihtsustab mudelite väljatöötamise ja valideerimise protsessi ning kontrollib ka mudeli tulemust PROM-is.
Et teie ootusi mitte petta, tahan ette öelda, et see postitus on sissejuhatav ja alguses räägime sellest, mis põhimõtteliselt on Sber.DS platvormi kapoti all. Eraldi räägime loo mudeli elutsüklist loomisest teostuseni.
Sber.DS koosneb mitmest komponendist, millest olulisemad on raamatukogu, arendussüsteem ja mudelite täitmissüsteem.
Raamatukogu juhib mudeli elutsüklit selle arendamise idee ilmumisest kuni selle rakendamiseni PROM-is, seire ja dekomisjoneerimiseni. Paljud raamatukogu võimalused on määratud regulaatori reeglitega, näiteks koolitus- ja valideerimisnäidiste aruandlus ja salvestamine. Tegelikult on see kõigi meie mudelite register.
Arendussüsteem on mõeldud mudelite ja valideerimistehnikate visuaalseks arendamiseks. Väljatöötatud mudelid läbivad esialgse valideerimise ja tarnitakse täitmissüsteemi nende ärifunktsioonide täitmiseks. Samuti saab käitussüsteemis mudeli asetada monitorile, et perioodiliselt käivitada valideerimistehnikad selle toimimise jälgimiseks.
Süsteemis on mitut tüüpi sõlme. Mõned neist on loodud erinevate andmeallikatega ühenduse loomiseks, teised aga lähteandmete teisendamiseks ja rikastamiseks (märgistus). Erinevate mudelite ehitamiseks ja nende valideerimiseks on palju sõlmi. Arendaja saab laadida andmeid mis tahes allikast, teisendada, filtreerida, visualiseerida vaheandmeid ja jagada need osadeks.
Platvorm sisaldab ka valmis mooduleid, mida saab disainialale lohistada. Kõik toimingud tehakse visualiseeritud liidese abil. Tegelikult saate probleemi lahendada ilma ühegi koodireata.
Kui sisseehitatud võimalustest ei piisa, annab süsteem võimaluse kiiresti oma mooduleid luua. Selle põhjal tegime integreeritud arendusrežiimi
Sber.DS-i arhitektuur on üles ehitatud mikroteenustele. Arvamusi selle kohta, mis on mikroteenused, on palju. Mõned arvavad, et piisab monoliitsest koodist osadeks jagamisest, aga samas minnakse ikka samasse andmebaasi. Meie mikroteenus peab suhtlema teise mikroteenusega ainult REST API kaudu. Otse andmebaasile juurdepääsuks pole lahendusi.
Püüame tagada, et teenused ei muutuks väga suureks ja kohmakaks: üks eksemplar ei tohiks tarbida rohkem kui 4-8 gigabaiti RAM-i ja peab võimaldama taotlusi horisontaalselt skaleerida, käivitades uusi eksemplare. Iga teenus suhtleb teistega ainult REST API kaudu (
Rakenduse tuum on kirjutatud Java keeles, kasutades Spring Frameworki. Lahendus oli algselt mõeldud kiireks juurutamiseks pilve infrastruktuuris, mistõttu rakendus ehitati konteinersüsteemi abil
Üks meie platvormi omadusi on see, et saame käivitada visuaalses liideses välja töötatud koodi mis tahes Sberbanki mudeli täitmissüsteemis. Nüüd on neid juba kaks: üks Hadoopis, teine OpenShiftis (Docker). Me ei piirdu sellega, vaid loome integratsioonimooduleid, et käitada koodi mis tahes infrastruktuuris, sealhulgas kohapeal ja pilves. Seoses Sberbanki ökosüsteemi tõhusa integreerimise võimalustega plaanime toetada ka tööd olemasolevate täitmiskeskkondadega. Tulevikus saab lahenduse paindlikult integreerida “kastist välja” mis tahes organisatsiooni igasse maastikku.
Need, kes on kunagi proovinud toetada lahendust, mis töötab Pythonil Hadoopis PROM-is, teavad, et Pythoni kasutajakeskkonna ettevalmistamisest ja edastamisest igasse andmesõlme ei piisa. Pythoni mooduleid kasutavate masinõppe C/C++ teekide tohutu hulk ei lase teil rahulikult puhata. Uute teekide või serverite lisamisel peame meeles pidama pakettide värskendamist, säilitades samal ajal tagasiühilduvuse juba juurutatud mudelikoodiga.
Selle tegemiseks on mitu lähenemisviisi. Näiteks valmistage ette mitu sageli kasutatavat teeki ja rakendage need PROM-is. Cloudera Hadoopi distributsioonis kasutavad nad tavaliselt
Pank võtab kolmanda osapoole koodi käitamise turvalisust väga tõsiselt, seega kasutame maksimaalselt ära Linuxi tuuma uutest funktsioonidest, kus protsess töötab isoleeritud keskkonnas.
Sel aastal plaanime lõpetada Python/R/Java keeles kirjutatud mudelite käivitamise MVP Hadoopis. Oleme seadnud endale ambitsioonika ülesande õppida kasutama mis tahes kohandatud keskkonda Hadoopis, et mitte mingil viisil piirata meie platvormi kasutajaid.
Lisaks, nagu selgus, oskavad paljud DS-spetsialistid suurepäraselt matemaatikat ja statistikat, teevad lahedaid mudeleid, kuid ei ole kuigi hästi kursis suurandmete teisendustega ning vajavad koolitusnäidiste koostamiseks meie andmeinseneride abi. Otsustasime aidata oma kolleege ja luua mugavad moodulid Spark-mootori mudelite standardse ümberkujundamiseks ja funktsioonide ettevalmistamiseks. See võimaldab teil kulutada rohkem aega mudelite väljatöötamisele ja mitte oodata, kuni andmeinsenerid uue andmekogumi ette valmistavad.
Meil töötavad erinevate valdkondade teadmistega inimesed: Linux ja DevOps, Hadoop ja Spark, Java ja Spring, Scala ja Akka, OpenShift ja Kubernetes. Järgmisel korral räägime mudeliteegist, kuidas mudel läbib ettevõttesisese elutsükli, kuidas toimub valideerimine ja juurutamine.
Allikas: www.habr.com