Erikokoisissa yrityksissä syntyy päivittäin ideoita ja tapaamisia siitä, mitä muita prosesseja voidaan automatisoida. Mutta sen lisäksi, että mallin luomiseen voidaan käyttää paljon aikaa, sinun on käytettävä sen arvioimiseen ja tarkistamiseen, ettei tulos ole satunnainen. Käyttöönoton jälkeen mitä tahansa mallia on seurattava ja tarkastettava säännöllisesti.
Ja nämä ovat kaikki vaiheet, jotka sinun tulee käydä läpi missä tahansa yrityksessä sen koosta riippumatta. Jos puhumme Sberbankin mittakaavasta ja perinnöstä, hienosäätöjen määrä kasvaa eksponentiaalisesti. Vuoden 2019 loppuun mennessä Sberbank oli käyttänyt jo yli 2000 XNUMX mallia. Pelkkä mallin kehittäminen ei riitä, on integroitava teollisiin järjestelmiin, kehitettävä datamarkkinoita malleja varten ja varmistettava sen toiminnan hallinta klusterissa.
Tiimimme kehittää Sber.DS-alustaa. Sen avulla voit ratkaista koneoppimisongelmia, nopeuttaa hypoteesien testausprosessia, periaatteessa yksinkertaistaa mallien kehittämis- ja validointiprosessia ja myös ohjaa mallin tulosta PROM:ssa.
Jotta odotuksiasi ei pettäisi, haluan sanoa etukäteen, että tämä viesti on johdanto, ja leikkauksen alla kerrotaan aluksi siitä, mikä on pohjimmiltaan Sber.DS-alustan konepellin alla. Kerromme erikseen tarinan mallin elinkaaresta luomisesta toteutukseen.
Sber.DS koostuu useista komponenteista, joista tärkeimmät ovat kirjasto, kehitysjärjestelmä ja mallin suoritusjärjestelmä.
Kirjasto hallitsee mallin elinkaarta sen kehittämisidean ilmaantumishetkestä sen toteutukseen PROM:ssa, seurantaan ja käytöstä poistamiseen. Monia kirjaston ominaisuuksia sanelevat säätäjän säännöt, esimerkiksi koulutus- ja validointinäytteiden raportointi ja tallennus. Itse asiassa tämä on rekisteri kaikista malleistamme.
Kehitysjärjestelmä on tarkoitettu mallien ja validointimenetelmien visuaaliseen kehittämiseen. Kehitetyt mallit käyvät läpi ensisijaisen validoinnin ja toimitetaan toteutusjärjestelmään liiketoimintojensa suorittamiseksi. Myös suoritusjärjestelmässä malli voidaan laittaa monitoriin käynnistämään ajoittain validointimenetelmiä sen toiminnan ohjaamiseksi.
Järjestelmässä on useita solmutyyppejä. Jotkut on suunniteltu yhdistämään eri tietolähteisiin, toiset - muuttamaan lähdetietoja ja rikastuttamaan sitä (merkintä). Erilaisten mallien rakentamiseen ja niiden validointiin on monia solmuja. Kehittäjä voi ladata tietoja mistä tahansa lähteestä, muuntaa, suodattaa, visualisoida välitietoja, jakaa sen osiin.
Alusta sisältää myös valmiita moduuleja, jotka voidaan vetää projektialueelle. Kaikki toiminnot suoritetaan käyttämällä visualisoitua käyttöliittymää. Itse asiassa voit ratkaista ongelman ilman yhtä koodiriviä.
Jos sisäänrakennetut ominaisuudet eivät riitä, järjestelmä tarjoaa mahdollisuuden luoda nopeasti omia moduuleja. Olemme tehneet integroidun kehitystilan pohjalta niille, jotka luovat uusia moduuleja tyhjästä.
Sber.DS-arkkitehtuuri on rakennettu mikropalveluihin. Mikropalveluista on monia mielipiteitä. Jotkut ajattelevat, että monoliittisen koodin jakaminen osiin riittää, mutta silti he menevät samaan tietokantaan. Mikropalvelumme tulee kommunikoida toisen mikropalvelun kanssa vain REST API:n kautta. Ei kiertotapoja tietokantaan pääsylle suoraan.
Pyrimme estämään palveluista muodostumasta kovin suuriksi ja hitaiksi: yksi instanssi ei saisi kuluttaa enempää kuin 4-8 gigatavua RAM-muistia ja pyynnöt pitäisi pystyä skaalata vaakasuunnassa käynnistämällä uusia ilmentymiä. Jokainen palvelu kommunikoi muiden kanssa vain REST API:n kautta (). Palvelusta vastaavan tiimin on pidettävä API taaksepäin yhteensopivana viimeiseen sitä käyttävään asiakasohjelmaan asti.
Sovelluksen ydin on kirjoitettu Java-kielellä Spring Frameworkin avulla. Ratkaisu suunniteltiin alun perin nopeaan käyttöönotettaviksi pilviinfrastruktuurissa, joten sovellus on rakennettu käyttämällä konttijärjestelmää (). Alusta kehittyy jatkuvasti sekä liiketoiminnan toiminnallisuuden lisäämisen (uusia liittimiä, AutoML:ää lisätään) että teknologisen tehokkuuden kannalta.
Yksi alustamme "siruista" on, että voimme ajaa visuaalisessa käyttöliittymässä kehitettyä koodia missä tahansa Sberbank-mallin suoritusjärjestelmässä. Nyt niitä on jo kaksi: yksi Hadoopissa, toinen OpenShiftissä (Docker). Emme pysähdy tähän vaan luomme integrointimoduuleja koodin suorittamiseksi missä tahansa infrastruktuurissa, mukaan lukien paikan päällä ja pilvessä. Mitä tulee mahdollisuuksiin tehokkaaseen integroitumiseen Sberbankin ekosysteemiin, aiomme tukea myös työtä olemassa olevien ajonaikaisten ympäristöjen kanssa. Tulevaisuudessa ratkaisu voidaan integroida joustavasti "pakkauksesta" mihin tahansa organisaation maisemaan.
Ne, jotka ovat koskaan yrittäneet ylläpitää ratkaisua, joka käyttää Pythonia Hadoopissa PROM:ssa, tietävät, että ei riitä, että valmistetaan ja toimitetaan mukautettu python-ympäristö jokaiselle datasolmulle. Valtava määrä C / C ++ -kirjastoja koneoppimiseen, jotka käyttävät Python-moduuleja, eivät anna sinun levätä rauhassa. Emme saa unohtaa päivittää paketteja lisätessämme uusia kirjastoja tai palvelimia, samalla kun säilytetään taaksepäin yhteensopivuus jo toteutetun mallikoodin kanssa.
On olemassa useita lähestymistapoja, miten tämä tehdään. Valmistele esimerkiksi useita usein käytettyjä kirjastoja etukäteen ja ota ne käyttöön PROM:ssa. Clouderan Hadoop-jakelu käyttää yleensä . Myös nyt Hadoopissa on mahdollisuus juosta - säiliöt. Joissakin yksinkertaisissa tapauksissa koodi on mahdollista toimittaa paketin mukana .
Pankki ottaa kolmannen osapuolen koodin käytön turvallisuuden erittäin vakavasti, joten hyödynnämme Linux-ytimen uusia ominaisuuksia, joissa prosessi toimii eristetyssä ympäristössä. , voit rajoittaa esimerkiksi pääsyä verkkoon ja paikalliseen levyyn, mikä vähentää huomattavasti haitallisen koodin mahdollisuutta. Kunkin osaston tietoalueet ovat suojattuja ja vain kyseisten tietojen omistajien käytettävissä. Alusta varmistaa, että tiedot yhdestä toimialueesta pääsevät toiselle verkkotunnukselle vain tietojen julkaisuprosessin kautta, jonka kaikissa vaiheissa on hallintaa aina lähteiden käyttämisestä datan laskeutumiseen kohdemarkkinoille.
Tänä vuonna aiomme suorittaa Python/R/Java-kielellä kirjoitetun juoksumallien MVP:n Hadoopissa. Asetimme itsellemme kunnianhimoisen tehtävän oppia käyttämään mitä tahansa käyttäjäympäristöä Hadoopissa, jotta emme rajoita alustamme käyttäjiä millään tavalla.
Lisäksi, kuten kävi ilmi, monet DS-asiantuntijat ovat erinomaisia matematiikassa ja tilastoissa, tekevät hienoja malleja, mutta eivät ole kovin perehtyneet suuriin datamuunnoksiin, ja he tarvitsevat tietoteknikkojemme apua koulutusnäytteiden valmistelussa. Päätimme auttaa kollegoitamme ja luoda käteviä moduuleja Spark-moottorin mallien tyypilliseen muuntamiseen ja ominaisuuksien valmisteluun. Tämä antaa enemmän aikaa käyttää mallien kehittämiseen eikä odottaa tietoteknisten valmistelevan uuden tietojoukon.
Meillä on eri alojen osaajia: Linux ja DevOps, Hadoop ja Spark, Java ja Spring, Scala ja Akka, OpenShift ja Kubernetes. Seuraavalla kerralla puhutaan mallikirjastosta, miten malli kulkee yrityksen elinkaaren ajan, miten validointi ja käyttöönotto tapahtuu.
Lähde: will.com