Ideeën en gearkomsten oer hokker oare prosessen kinne wurde automatisearre ûntsteane alle dagen yn bedriuwen fan ferskate grutte. Mar neist it feit dat in protte tiid kin wurde bestege oan it meitsjen fan in model, moatte jo it besteegje oan it evaluearjen en kontrolearjen dat it resultaat net willekeurich is. Nei ymplemintaasje moat elk model wurde kontrolearre en periodyk kontrolearre.
En dit binne alle stadia dy't moatte wurde foltôge yn elk bedriuw, nettsjinsteande syn grutte. As wy it hawwe oer de skaal en neilittenskip fan Sberbank, nimt it oantal fine-tuning signifikant ta. Oan 'e ein fan 2019 hie Sber al mear dan 2000 modellen brûkt. It is net genôch om gewoan in model te ûntwikkeljen; it is needsaaklik om te yntegrearjen mei yndustriële systemen, gegevensmarts te ûntwikkeljen foar it bouwen fan modellen, en soargje foar kontrôle fan har wurking op it kluster.
Us team ûntwikkelet it Sber.DS-platfoarm. It lit jo problemen mei masine learen oplosse, it proses fan testen fan hypotezen fersnelle, yn prinsipe simplifies it proses fan it ûntwikkeljen en validearjen fan modellen, en ek kontrolearret it resultaat fan it model yn PROM.
Om jo ferwachtingen net te ferrifeljen, wol ik fan tefoaren sizze dat dizze post in ynliedend is, en ûnder de besuniging, om te begjinnen, prate wy oer wat, yn prinsipe, ûnder de kap fan it Sber.DS-platfoarm is. Wy sille it ferhaal fertelle oer de libbenssyklus fan it model fan skepping oant ymplemintaasje apart.
Sber.DS bestiet út ferskate komponinten, de kaaien binne de biblioteek, ûntwikkelingssysteem en modelútfiersysteem.
De bibleteek kontrolearret de libbenssyklus fan it model fanôf it momint dat it idee om it te ûntwikkeljen ferskynt oant syn ymplemintaasje yn PROM, tafersjoch en ûntbining. In protte bibleteek mooglikheden wurde diktearre troch regulator regels, Bygelyks, rapportaazje en opslach fan training en falidaasje samples. Yn feite is dit in register fan al ús modellen.
It ûntwikkelingssysteem is ûntworpen foar fisuele ûntwikkeling fan modellen en validaasjetechniken. De ûntwikkele modellen ûndergeane inisjele falidaasje en wurde levere oan it útfieringssysteem om har saaklike funksjes út te fieren. Ek yn it runtime-systeem kin it model op in monitor pleatst wurde foar it doel fan periodyk lansearring fan falidaasjetechniken om de wurking te kontrolearjen.
D'r binne ferskate soarten knopen yn it systeem. Guon binne ûntworpen om te ferbinen mei ferskate gegevensboarnen, oaren binne ûntworpen om boarnegegevens te transformearjen en te ferrykjen (markup). D'r binne in protte knopen foar it bouwen fan ferskate modellen en knopen foar it validearjen fan se. De ûntwikkelder kin gegevens fan elke boarne lade, transformearje, filterje, tuskenlizzende gegevens visualisearje en it yn dielen brekke.
It platfoarm befettet ek ready-made modules dy't kinne wurde sleept en falle op it ûntwerp gebiet. Alle aksjes wurde útfierd mei in fisualisearre ynterface. Yn feite kinne jo it probleem oplosse sûnder ien rigel koade.
As de ynboude mooglikheden net genôch binne, biedt it systeem de mooglikheid om jo eigen modules fluch te meitsjen. Wy makken in yntegreare ûntwikkelingsmodus basearre op foar dyjingen dy't meitsje nije modules út scratch.
De arsjitektuer fan Sber.DS is boud op mikrotsjinsten. D'r binne in protte mieningen oer wat mikrotsjinsten binne. Guon minsken tinke dat it genôch is om de monolityske koade yn dielen te splitsen, mar tagelyk geane se noch nei deselde databank. Us mikrotsjinst moat allinich kommunisearje mei in oare mikrotsjinst fia REST API. Gjin oplossingen om direkt tagong te krijen ta de databank.
Wy besykje derfoar te soargjen dat tsjinsten net heul grut en ûnhandich wurde: ien eksimplaar moat net mear as 4-8 gigabyte RAM konsumearje en moat de mooglikheid leverje om fersiken horizontaal te skaaljen troch nije eksimplaren te lansearjen. Elke tsjinst kommunisearret allinich mei oaren fia REST API (). It team ferantwurdlik foar de tsjinst is ferplichte om de API efterút kompatibel te hâlden oant de lêste klant dy't it brûkt.
De kearn fan 'e applikaasje is skreaun yn Java mei it Spring Framework. De oplossing waard yn earste ynstânsje ûntworpen foar rappe ynset yn 'e wolkynfrastruktuer, sadat de applikaasje waard boud mei in kontenerisaasjesysteem (). It platfoarm is konstant yn ûntwikkeling, sawol yn termen fan tanimmende saaklike funksjonaliteit (nije Anschlüsse, AutoML wurde tafoege) en yn termen fan technologyske effisjinsje.
Ien fan 'e funksjes fan ús platfoarm is dat wy koade kinne útfiere ûntwikkele yn in fisuele ynterface op elk Sberbank-modelútfiersysteem. No binne d'r al twa: ien op Hadoop, de oare op OpenShift (Docker). Wy stopje dêr net en meitsje yntegraasjemodules om koade út te fieren op elke ynfrastruktuer, ynklusyf on-premise en yn 'e wolk. Oangeande de mooglikheden fan effektive yntegraasje yn it Sberbank-ekosysteem, plannen wy ek om wurk te stypjen mei besteande útfieringsomjouwings. Yn 'e takomst kin de oplossing fleksibel "out of the box" wurde yntegrearre yn elk lânskip fan elke organisaasje.
Dejingen dy't ea besocht hawwe om in oplossing te stypjen dy't Python op Hadoop yn PROM rint, witte dat it net genôch is om in Python-brûkersomjouwing te meitsjen en te leverjen oan elke datanode. It enoarme oantal C/C ++-biblioteken foar masine-learen dy't Python-modules brûke sil jo net maklik rêstje. Wy moatte ûnthâlde om pakketten te aktualisearjen by it tafoegjen fan nije biblioteken of servers, wylst wy efterútkompatibiliteit behâlde mei al ymplementearre modelkoade.
D'r binne ferskate oanpak om dit te dwaan. Tariede bygelyks fan tefoaren ferskate faak brûkte biblioteken en ymplementearje se yn PROM. Yn Cloudera's Hadoop-distribúsje brûke se normaal . Ek no yn Hadoop is it mooglik om te rinnen - konteners. Yn guon ienfâldige gefallen is it mooglik om de koade tegearre mei it pakket te leverjen .
De bank nimt de feiligens fan it útfieren fan koade fan tredden tige serieus, dus wy meitsje it measte út 'e nije funksjes fan' e Linux kernel, wêr't in proses rint yn in isolearre omjouwing , Jo kinne beheine, bygelyks, tagong ta it netwurk en lokale skiif, dy't gâns ferminderet de mooglikheden fan kweade koade. De gegevensgebieten fan elke ôfdieling binne beskerme en allinich tagonklik foar de eigners fan dizze gegevens. It platfoarm soarget derfoar dat gegevens fan ien gebiet allinich in oar gebiet kinne berikke fia in datapublisearjenproses mei kontrôle yn alle stadia fan tagong ta boarnen oant lâning fan gegevens yn 'e doelwinkel.
Dit jier binne wy fan plan de MVP te foltôgjen fan lansearring fan modellen skreaun yn Python/R/Java op Hadoop. Wy hawwe ússels de ambisjeuze taak ynsteld om te learen hoe't jo elke oanpaste omjouwing op Hadoop kinne útfiere, om de brûkers fan ús platfoarm op gjin inkelde manier te beheinen.
Derneist, sa die bliken, binne in protte DS-spesjalisten poerbêst yn wiskunde en statistyk, meitsje koele modellen, mar binne net heul goed yn 'e transformaasjes fan grutte gegevens, en se hawwe de help nedich fan ús data-yngenieurs om treningsmonsters te meitsjen. Wy besletten om te helpen ús kollega en meitsje handige modules foar standert transformaasje en tarieding fan funksjes foar modellen op de Spark motor. Hjirmei kinne jo mear tiid besteegje oan it ûntwikkeljen fan modellen en net wachtsje op data-yngenieurs om in nije dataset te meitsjen.
Wy wurkje minsken mei kennis yn ferskate gebieten: Linux en DevOps, Hadoop en Spark, Java en Spring, Scala en Akka, OpenShift en Kubernetes. Folgjende kear sille wy prate oer de modelbibleteek, hoe't it model troch de libbenssyklus binnen it bedriuw giet, hoe't falidaasje en ymplemintaasje foarkomme.
Boarne: www.habr.com