Idees en vergaderings oor watter ander prosesse geoutomatiseer kan word, ontstaan elke dag in besighede van verskillende groottes. Maar benewens die feit dat baie tyd aan die skep van 'n model bestee kan word, moet u dit spandeer om dit te evalueer en te kontroleer dat die resultaat wat verkry word nie lukraak is nie. Na implementering moet enige model gemonitor en periodiek nagegaan word.
En dit is al die fases wat in enige maatskappy voltooi moet word, ongeag die grootte daarvan. As ons praat oor die omvang en nalatenskap van Sberbank, neem die aantal fynverstellings aansienlik toe. Teen die einde van 2019 het Sber reeds meer as 2000 XNUMX modelle gebruik. Dit is nie genoeg om bloot 'n model te ontwikkel nie; dit is nodig om met industriële stelsels te integreer, datamars vir die bou van modelle te ontwikkel en beheer oor die werking daarvan op die groep te verseker.
Ons span is besig om die Sber.DS-platform te ontwikkel. Dit laat jou toe om masjienleerprobleme op te los, versnel die proses om hipoteses te toets, vereenvoudig in beginsel die proses om modelle te ontwikkel en te valideer, en beheer ook die resultaat van die model in PROM.
Om nie u verwagtinge te mislei nie, wil ek vooraf sê dat hierdie pos 'n inleidende een is, en onder die snit, om mee te begin, praat ons oor wat in beginsel onder die kap van die Sber.DS-platform is. Ons sal die storie oor die lewensiklus van die model van skepping tot implementering afsonderlik vertel.
Sber.DS bestaan uit verskeie komponente, waarvan die sleutel die biblioteek, ontwikkelingstelsel en modeluitvoeringstelsel is.
Die biblioteek beheer die lewensiklus van die model vanaf die oomblik dat die idee om dit te ontwikkel verskyn tot die implementering daarvan in PROM, monitering en uitdiensstelling. Baie biblioteekvermoëns word bepaal deur reguleerderreëls, byvoorbeeld verslagdoening en berging van opleiding en valideringsmonsters. Trouens, dit is 'n register van al ons modelle.
Die ontwikkelingstelsel is ontwerp vir visuele ontwikkeling van modelle en valideringstegnieke. Die ontwikkelde modelle ondergaan aanvanklike validering en word aan die uitvoeringstelsel verskaf om hul besigheidsfunksies uit te voer. In die looptydstelsel kan die model ook op 'n monitor geplaas word met die doel om periodiek valideringstegnieke te loods om die werking daarvan te monitor.
Daar is verskeie tipes nodusse in die stelsel. Sommige is ontwerp om aan verskeie databronne te koppel, ander is ontwerp om brondata te transformeer en dit te verryk (opmerk). Daar is baie nodusse vir die bou van verskillende modelle en nodusse vir die validering daarvan. Die ontwikkelaar kan data van enige bron af laai, transformeer, filter, intermediêre data visualiseer en in dele opbreek.
Die platform bevat ook klaargemaakte modules wat na die ontwerparea gesleep en laat val kan word. Alle aksies word uitgevoer met behulp van 'n gevisualiseerde koppelvlak. Trouens, jy kan die probleem oplos sonder 'n enkele reël kode.
As die ingeboude vermoëns nie genoeg is nie, bied die stelsel die vermoë om vinnig jou eie modules te skep. Ons het 'n geïntegreerde ontwikkelingsmodus gemaak gebaseer op vir diegene wat nuwe modules van nuuts af skep.
Die argitektuur van Sber.DS is gebou op mikrodienste. Daar is baie menings oor wat mikrodienste is. Sommige mense dink dat dit genoeg is om die monolitiese kode in dele te verdeel, maar terselfdertyd gaan hulle steeds na dieselfde databasis. Ons mikrodiens moet slegs met 'n ander mikrodiens kommunikeer via REST API. Geen oplossings om direk toegang tot die databasis te kry nie.
Ons probeer verseker dat dienste nie baie groot en lomp word nie: een geval moet nie meer as 4-8 gigagrepe RAM verbruik nie en moet die vermoë bied om versoeke horisontaal te skaal deur nuwe gevalle te begin. Elke diens kommunikeer slegs met ander via REST API (). Daar word van die span verantwoordelik vir die diens vereis om die API agteruit versoenbaar te hou tot die laaste kliënt wat dit gebruik.
Die kern van die toepassing is in Java geskryf deur die Spring Framework te gebruik. Die oplossing is aanvanklik ontwerp vir vinnige ontplooiing in die wolkinfrastruktuur, so die toepassing is gebou met behulp van 'n houerstelsel (). Die platform ontwikkel voortdurend, beide in terme van toenemende besigheidsfunksionaliteit (nuwe verbindings, AutoML word bygevoeg) en in terme van tegnologiese doeltreffendheid.
Een van die kenmerke van ons platform is dat ons kode kan laat loop wat ontwikkel is in 'n visuele koppelvlak op enige Sberbank-modeluitvoeringstelsel. Nou is daar reeds twee van hulle: een op Hadoop, die ander op OpenShift (Docker). Ons stop nie daar en skep integrasiemodules om kode op enige infrastruktuur uit te voer nie, insluitend op die perseel en in die wolk. Wat die moontlikhede van effektiewe integrasie in die Sberbank-ekosisteem betref, beplan ons ook om werk met bestaande uitvoeringsomgewings te ondersteun. In die toekoms kan die oplossing buigsaam "buite die boks" in enige landskap van enige organisasie geïntegreer word.
Diegene wat al ooit probeer het om 'n oplossing te ondersteun wat Python op Hadoop in PROM laat loop, weet dat dit nie genoeg is om 'n Python-gebruikersomgewing voor te berei en aan elke datanode te lewer nie. Die groot aantal C/C++-biblioteke vir masjienleer wat Python-modules gebruik, sal jou nie toelaat om maklik te rus nie. Ons moet onthou om pakkette op te dateer wanneer nuwe biblioteke of bedieners bygevoeg word, terwyl ons terugwaartse versoenbaarheid met reeds geïmplementeerde modelkode handhaaf.
Daar is verskeie benaderings tot hoe om dit te doen. Berei byvoorbeeld vooraf verskeie biblioteke wat gereeld gebruik word voor en implementeer dit in PROM. In Cloudera se Hadoop-verspreiding gebruik hulle gewoonlik . Ook nou in Hadoop is dit moontlik om te hardloop -houers. In sommige eenvoudige gevalle is dit moontlik om die kode saam met die pakket af te lewer .
Die bank neem die sekuriteit van die bestuur van derdeparty-kode baie ernstig op, daarom maak ons die meeste van die nuwe kenmerke van die Linux-kern, waar 'n proses in 'n geïsoleerde omgewing loop , kan jy byvoorbeeld toegang tot die netwerk en plaaslike skyf beperk, wat die vermoëns van kwaadwillige kode aansienlik verminder. Die dataareas van elke departement word beskerm en slegs toeganklik vir die eienaars van hierdie data. Die platform verseker dat data van een area slegs 'n ander area kan bereik deur 'n datapubliseringsproses met beheer in alle stadiums van toegang tot bronne tot landing van data in die teikenwinkelfront.
Hierdie jaar beplan ons om die MVP van die bekendstelling van modelle wat in Python/R/Java op Hadoop geskryf is, te voltooi. Ons het onsself die ambisieuse taak gestel om te leer hoe om enige pasgemaakte omgewing op Hadoop te bestuur, om nie die gebruikers van ons platform op enige manier te beperk nie.
Daarbenewens, soos dit geblyk het, is baie DS-spesialiste uitstekend in wiskunde en statistiek, maak cool modelle, maar is nie baie goed vertroud met grootdata-transformasies nie, en hulle benodig die hulp van ons data-ingenieurs om opleidingsmonsters voor te berei. Ons het besluit om ons kollegas te help en gerieflike modules te skep vir standaardtransformasie en voorbereiding van kenmerke vir modelle op die Spark-enjin. Dit sal jou toelaat om meer tyd te spandeer om modelle te ontwikkel en nie te wag vir data-ingenieurs om 'n nuwe datastel voor te berei nie.
Ons neem mense in diens met kennis in verskillende areas: Linux en DevOps, Hadoop en Spark, Java en Spring, Scala en Akka, OpenShift en Kubernetes. Volgende keer sal ons praat oor die modelbiblioteek, hoe die model deur die lewensiklus binne die maatskappy gaan, hoe validering en implementering plaasvind.
Bron: will.com