Ideoj kaj renkontiĝoj pri kio aliaj procezoj povas esti aŭtomatigitaj aperas en entreprenoj de diversaj grandecoj ĉiutage. Sed krom la fakto, ke multe da tempo povas esti elspezita por krei modelon, vi devas elspezi ĝin por taksi ĝin kaj kontroli, ke la rezulto akirita ne estas hazarda. Post efektivigo, ajna modelo devas esti monitorita kaj periode kontrolita.
Kaj ĉi tiuj estas ĉiuj etapoj, kiujn oni devas plenumi en iu ajn kompanio, sendepende de ĝia grandeco. Se ni parolas pri la skalo kaj heredaĵo de Sberbank, la nombro da fajnagordoj signife pliiĝas. Antaŭ la fino de 2019, Sber jam uzis pli ol 2000 modelojn. Ne sufiĉas simple evoluigi modelon; necesas integriĝi kun industriaj sistemoj, evoluigi datumvendejojn por konstrui modelojn kaj certigi kontrolon de ĝia funkciado sur la areto.
Nia teamo disvolvas la platformon Sber.DS. Ĝi permesas vin solvi maŝinlernajn problemojn, akcelas la procezon de testado de hipotezoj, principe simpligas la procezon de evoluigo kaj validigo de modeloj, kaj ankaŭ kontrolas la rezulton de la modelo en PROM.
Por ne trompi viajn atendojn, mi volas diri anticipe, ke ĉi tiu afiŝo estas enkonduka, kaj sub la tranĉo, por komenci, ni parolas pri tio, kio, principe, estas sub la kapuĉo de la platformo Sber.DS. Ni rakontos la historion pri la vivociklo de la modelo de kreado ĝis efektivigo aparte.
Sber.DS konsistas el pluraj komponentoj, la ŝlosilaj estas la biblioteko, evolusistemo kaj modela ekzekutsistemo.
La biblioteko kontrolas la vivociklon de la modelo ekde la momento, kiam aperas la ideo disvolvi ĝin, ĝis ĝia efektivigo en PROM, monitorado kaj malfunkciigo. Multaj bibliotekkapabloj estas diktitaj de reguligistoj, ekzemple, raportado kaj stokado de trejnado kaj validumadprovaĵoj. Fakte, ĉi tio estas registro de ĉiuj niaj modeloj.
La evolusistemo estas dizajnita por vida evoluo de modeloj kaj validumadteknikoj. La evoluintaj modeloj spertas komencan validumon kaj estas liveritaj al la ekzekutsistemo por plenumi siajn komercajn funkciojn. Ankaŭ, en la rultempa sistemo, la modelo povas esti metita sur ekranon kun la celo de periode lanĉado de validumteknikoj por monitori sian operacion.
Estas pluraj specoj de nodoj en la sistemo. Iuj estas dizajnitaj por konektiĝi al diversaj datumfontoj, aliaj estas dezajnitaj por transformi fontajn datumojn kaj riĉigi ĝin (markado). Estas multaj nodoj por konstrui malsamajn modelojn kaj nodojn por validigi ilin. La programisto povas ŝargi datumojn de iu ajn fonto, transformi, filtri, vidi interajn datumojn kaj dividi ĝin en partojn.
La platformo ankaŭ enhavas pretajn modulojn, kiuj povas esti trenitaj kaj faligitaj sur la dezajnareon. Ĉiuj agoj estas faritaj per bildigita interfaco. Fakte, vi povas solvi la problemon sen ununura linio de kodo.
Se la enkonstruitaj kapabloj ne sufiĉas, la sistemo provizas la kapablon rapide krei viajn proprajn modulojn. Ni faris integran evoluan reĝimon bazitan sur por tiuj, kiuj kreas novajn modulojn de nulo.
La arkitekturo de Sber.DS estas konstruita sur mikroservoj. Estas multaj opinioj pri kio estas mikroservoj. Iuj opinias, ke sufiĉas dividi la monolitan kodon en partojn, sed samtempe ili ankoraŭ iras al la sama datumbazo. Nia mikroservo devas komuniki kun alia mikroservo nur per REST API. Neniuj solvoj por aliri la datumbazon rekte.
Ni provas certigi, ke servoj ne fariĝu tre grandaj kaj mallertaj: unu kazo ne devus konsumi pli ol 4-8 gigabajtojn da RAM kaj devas disponigi la kapablon horizontale skali petojn lanĉante novajn petskribojn. Ĉiu servo komunikas kun aliaj nur per REST API (). La teamo respondeca por la servo devas konservi la API malantaŭen kongrua ĝis la lasta kliento kiu uzas ĝin.
La kerno de la aplikaĵo estas skribita en Java uzante la Spring Framework. La solvo estis komence desegnita por rapida deplojo en la nuba infrastrukturo, do la aplikaĵo estis konstruita uzante kontenerigsistemon (). La platformo konstante evoluas, kaj laŭ kreskanta komerca funkcieco (novaj konektiloj, AutoML estas aldonitaj) kaj laŭ teknologia efikeco.
Unu el la trajtoj de nia platformo estas, ke ni povas ruli kodon disvolvitan en vida interfaco sur iu ajn modelo de ekzekutsistemo de Sberbank. Nun jam estas du el ili: unu sur Hadoop, la alia sur OpenShift (Docker). Ni ne ĉesas tie kaj kreas integrigajn modulojn por ruli kodon en ajna infrastrukturo, inkluzive surloke kaj en la nubo. Koncerne la eblecojn de efika integriĝo en la Sberbank-ekosistemon, ni ankaŭ planas subteni laboron kun ekzistantaj ekzekutmedioj. En la estonteco, la solvo povas esti flekseble integrita "el la skatolo" en ajnan pejzaĝon de iu ajn organizo.
Tiuj, kiuj iam provis subteni solvon, kiu funkcias Python sur Hadoop en PROM, scias, ke ne sufiĉas prepari kaj liveri Python-uzantmedion al ĉiu datumnodo. La grandega nombro da C/C++-bibliotekoj por maŝinlernado, kiuj uzas Python-modulojn, ne permesos al vi ripozi. Ni devas memori ĝisdatigi pakaĵojn aldonante novajn bibliotekojn aŭ servilojn, konservante malantaŭan kongruon kun jam efektivigita modelkodo.
Estas pluraj aliroj al kiel fari tion. Ekzemple, preparu plurajn ofte uzatajn bibliotekojn anticipe kaj efektivigu ilin en PROM. En la distribuo Hadoop de Cloudera, ili kutime uzas . Ankaŭ nun en Hadoop eblas kuri -ujoj. En iuj simplaj kazoj eblas liveri la kodon kune kun la pako .
La banko tre serioze prenas la sekurecon pri rulado de triaparta kodo, do ni profitas la novajn funkciojn de la Linukso-kerno, kie procezo funkcias en izolita medio. , vi povas limigi, ekzemple, aliron al la reto kaj loka disko, kio signife reduktas la kapablojn de malica kodo. La datumaj areoj de ĉiu fako estas protektitaj kaj alireblaj nur por la posedantoj de ĉi tiuj datumoj. La platformo certigas, ke datumoj de unu areo povas atingi alian areon nur per datuma eldonprocezo kun kontrolo en ĉiuj stadioj de aliro al fontoj ĝis surteriĝo de datumoj en la cela vendejo.
Ĉi-jare ni planas kompletigi la MVP de lanĉaj modeloj skribitaj en Python/R/Java sur Hadoop. Ni starigis al ni la ambician taskon lerni kiel prizorgi ajnan kutiman medion sur Hadoop, por neniel limigi la uzantojn de nia platformo.
Krome, kiel montriĝis, multaj DS-specialistoj estas bonegaj pri matematiko kaj statistiko, faras bonegajn modelojn, sed ne tre bone konas grandajn datumajn transformojn, kaj ili bezonas la helpon de niaj datumaj inĝenieroj por prepari trejnajn specimenojn. Ni decidis helpi niajn kolegojn kaj krei oportunajn modulojn por norma transformo kaj preparado de funkcioj por modeloj sur la Spark-motoro. Ĉi tio permesos al vi pasigi pli da tempo disvolvante modelojn kaj ne atendi ke datumaj inĝenieroj preparos novan datumaron.
Ni dungas homojn kun scio en malsamaj areoj: Linukso kaj DevOps, Hadoop kaj Spark, Java kaj Spring, Scala kaj Akka, OpenShift kaj Kubernetes. Venontfoje ni parolos pri la modelbiblioteko, kiel la modelo trapasas la vivociklon ene de la kompanio, kiel validado kaj efektivigo okazas.
fonto: www.habr.com