Ang mga ideya at pagpupulong tungkol sa kung ano pang mga proseso ang maaaring i-automate ay lumalabas sa mga negosyo na may iba't ibang laki araw-araw. Ngunit bilang karagdagan sa katotohanan na maraming oras ang maaaring gugulin sa paglikha ng isang modelo, kailangan mong gastusin ito sa pagsusuri nito at pagsuri na ang resulta na nakuha ay hindi random. Pagkatapos ng pagpapatupad, ang anumang modelo ay dapat na subaybayan at pana-panahong suriin.
At ito ang lahat ng mga yugto na kailangang makumpleto sa anumang kumpanya, anuman ang laki nito. Kung pinag-uusapan natin ang sukat at legacy ng Sberbank, ang bilang ng fine-tuning ay tumataas nang malaki. Sa pagtatapos ng 2019, nakagamit na ang Sber ng higit sa 2000 mga modelo. Hindi sapat na bumuo lamang ng isang modelo; ito ay kinakailangan upang isama sa mga sistemang pang-industriya, bumuo ng mga data mart para sa pagbuo ng mga modelo, at tiyakin ang kontrol sa operasyon nito sa cluster.
Binubuo ng aming team ang platform ng Sber.DS. Pinapayagan ka nitong lutasin ang mga problema sa pag-aaral ng makina, pabilisin ang proseso ng pagsubok ng mga hypotheses, sa prinsipyo ay pinapasimple ang proseso ng pagbuo at pagpapatunay ng mga modelo, at kinokontrol din ang resulta ng modelo sa PROM.
Upang hindi linlangin ang iyong mga inaasahan, nais kong sabihin nang maaga na ang post na ito ay isang panimula, at sa ilalim ng hiwa, para sa mga nagsisimula, pinag-uusapan natin kung ano, sa prinsipyo, ay nasa ilalim ng hood ng platform ng Sber.DS. Sasabihin namin ang kuwento tungkol sa ikot ng buhay ng modelo mula sa paglikha hanggang sa pagpapatupad nang hiwalay.
Ang Sber.DS ay binubuo ng ilang mga bahagi, ang mga pangunahing ay ang aklatan, sistema ng pag-unlad at sistema ng pagpapatupad ng modelo.
Kinokontrol ng library ang ikot ng buhay ng modelo mula sa sandaling lumitaw ang ideya na bumuo nito hanggang sa pagpapatupad nito sa PROM, pagsubaybay at pag-decommissioning. Maraming mga kakayahan sa library ang idinidikta ng mga panuntunan ng regulator, halimbawa, pag-uulat at pag-iimbak ng mga sample ng pagsasanay at pagpapatunay. Sa katunayan, ito ay isang rehistro ng lahat ng aming mga modelo.
Ang sistema ng pag-unlad ay idinisenyo para sa visual na pagbuo ng mga modelo at mga diskarte sa pagpapatunay. Ang mga binuo na modelo ay sumasailalim sa paunang pagpapatunay at ibinibigay sa sistema ng pagpapatupad upang maisagawa ang kanilang mga tungkulin sa negosyo. Gayundin, sa runtime system, ang modelo ay maaaring ilagay sa isang monitor para sa layunin ng pana-panahong paglulunsad ng mga diskarte sa pagpapatunay upang masubaybayan ang operasyon nito.
Mayroong ilang mga uri ng mga node sa system. Ang ilan ay idinisenyo upang kumonekta sa iba't ibang mga mapagkukunan ng data, ang iba ay idinisenyo upang baguhin ang pinagmulan ng data at pagyamanin ito (markup). Mayroong maraming mga node para sa pagbuo ng iba't ibang mga modelo at mga node para sa pagpapatunay ng mga ito. Maaaring mag-load ang developer ng data mula sa anumang pinagmulan, mag-transform, mag-filter, mag-visualize ng intermediate data, at hatiin ito sa mga bahagi.
Naglalaman din ang platform ng mga nakahanda nang module na maaaring i-drag at i-drop sa lugar ng disenyo. Ang lahat ng mga aksyon ay isinasagawa gamit ang isang visualized na interface. Sa katunayan, maaari mong lutasin ang problema nang walang isang linya ng code.
Kung ang mga built-in na kakayahan ay hindi sapat, ang system ay nagbibigay ng kakayahang mabilis na lumikha ng iyong sariling mga module. Gumawa kami ng integrated development mode batay sa para sa mga gumagawa ng mga bagong module mula sa simula.
Ang arkitektura ng Sber.DS ay binuo sa mga microservice. Maraming mga opinyon tungkol sa kung ano ang mga microservice. Ang ilang mga tao ay nag-iisip na ito ay sapat na upang hatiin ang monolitikong code sa mga bahagi, ngunit sa parehong oras pumunta pa rin sila sa parehong database. Ang aming microservice ay dapat makipag-ugnayan sa isa pang microservice sa pamamagitan lamang ng REST API. Walang mga workaround upang direktang ma-access ang database.
Sinusubukan naming tiyakin na ang mga serbisyo ay hindi magiging napakalaki at malamya: ang isang pagkakataon ay hindi dapat kumonsumo ng higit sa 4-8 gigabytes ng RAM at dapat magbigay ng kakayahang pahalang na sukatin ang mga kahilingan sa pamamagitan ng paglulunsad ng mga bagong pagkakataon. Ang bawat serbisyo ay nakikipag-ugnayan sa iba lamang sa pamamagitan ng REST API (). Ang team na responsable para sa serbisyo ay kinakailangan na panatilihing pabalik-balik ang API hanggang sa huling kliyente na gumagamit nito.
Ang core ng application ay nakasulat sa Java gamit ang Spring Framework. Ang solusyon ay unang idinisenyo para sa mabilis na pag-deploy sa cloud infrastructure, kaya ang application ay binuo gamit ang containerization system (). Ang platform ay patuloy na umuunlad, kapwa sa mga tuntunin ng pagtaas ng paggana ng negosyo (mga bagong konektor, ang AutoML ay idinaragdag) at sa mga tuntunin ng kahusayan sa teknolohiya.
Ang isa sa mga tampok ng aming platform ay na maaari naming patakbuhin ang code na binuo sa isang visual na interface sa anumang sistema ng pagpapatupad ng modelo ng Sberbank. Ngayon ay mayroon nang dalawa sa kanila: isa sa Hadoop, ang isa sa OpenShift (Docker). Hindi kami tumitigil doon at gumagawa ng mga module ng integration para magpatakbo ng code sa anumang imprastraktura, kabilang ang on-premise at sa cloud. Tungkol sa mga posibilidad ng epektibong pagsasama sa ecosystem ng Sberbank, plano rin naming suportahan ang trabaho sa mga umiiral na kapaligiran ng pagpapatupad. Sa hinaharap, ang solusyon ay maaaring madaling isama "out of the box" sa anumang landscape ng anumang organisasyon.
Alam ng mga sumubok na suportahan ang isang solusyon na nagpapatakbo ng Python sa Hadoop sa PROM na hindi sapat na maghanda at maghatid ng kapaligiran ng gumagamit ng Python sa bawat datanode. Ang malaking bilang ng mga C/C++ na library para sa machine learning na gumagamit ng Python modules ay hindi magbibigay-daan sa iyong makapagpahinga nang madali. Dapat nating tandaan na mag-update ng mga package kapag nagdaragdag ng mga bagong library o server, habang pinapanatili ang backward compatibility sa naipatupad na code ng modelo.
Mayroong ilang mga diskarte sa kung paano gawin ito. Halimbawa, maghanda nang maaga ng ilang malimit na ginagamit na aklatan at ipatupad ang mga ito sa PROM. Sa pamamahagi ng Hadoop ng Cloudera, kadalasang ginagamit nila . Ngayon din sa Hadoop posible na tumakbo -mga lalagyan. Sa ilang mga simpleng kaso, posibleng maihatid ang code kasama ng package .
Sineseryoso ng bangko ang seguridad ng pagpapatakbo ng third-party na code, kaya sinusulit namin ang mga bagong feature ng Linux kernel, kung saan tumatakbo ang isang proseso sa isang nakahiwalay na kapaligiran , maaari mong limitahan, halimbawa, ang pag-access sa network at lokal na disk, na makabuluhang binabawasan ang mga kakayahan ng malisyosong code. Ang mga lugar ng data ng bawat departamento ay protektado at naa-access lamang ng mga may-ari ng data na ito. Tinitiyak ng platform na ang data mula sa isang lugar ay makakarating lamang sa isa pang lugar sa pamamagitan ng proseso ng pag-publish ng data na may kontrol sa lahat ng mga yugto mula sa pag-access sa mga mapagkukunan hanggang sa landing ng data sa target na storefront.
Sa taong ito plano naming kumpletuhin ang MVP ng paglulunsad ng mga modelong nakasulat sa Python/R/Java sa Hadoop. Itinakda namin sa aming sarili ang ambisyosong gawain ng pag-aaral kung paano magpatakbo ng anumang custom na kapaligiran sa Hadoop, upang hindi limitahan ang mga gumagamit ng aming platform sa anumang paraan.
Bilang karagdagan, tulad ng nangyari, maraming mga espesyalista sa DS ang mahusay sa matematika at istatistika, gumawa ng mga cool na modelo, ngunit hindi masyadong bihasa sa malalaking pagbabago ng data, at kailangan nila ang tulong ng aming mga inhinyero ng data upang maghanda ng mga sample ng pagsasanay. Nagpasya kaming tulungan ang aming mga kasamahan at lumikha ng mga maginhawang module para sa karaniwang pagbabago at paghahanda ng mga feature para sa mga modelo sa Spark engine. Papayagan ka nitong gumugol ng mas maraming oras sa pagbuo ng mga modelo at hindi maghintay para sa mga inhinyero ng data na maghanda ng bagong dataset.
Gumagamit kami ng mga taong may kaalaman sa iba't ibang lugar: Linux at DevOps, Hadoop at Spark, Java at Spring, Scala at Akka, OpenShift at Kubernetes. Sa susunod na pag-uusapan natin ang tungkol sa library ng modelo, kung paano dumaan ang modelo sa ikot ng buhay sa loob ng kumpanya, kung paano nangyayari ang pagpapatunay at pagpapatupad.
Pinagmulan: www.habr.com