Habri konverents ei ole debüütlugu. Varem tegime üsna suuri Toasteri üritusi 300-400 inimesele, kuid nüüd otsustasime, et aktuaalsed on väikesed temaatilised koosolekud, mille suuna saab paika panna näiteks kommentaarides. Esimene selle formaadi konverents peeti juulis ja oli pühendatud taustaprogrammi arendamisele. Osalejad kuulasid riigiteenuste portaalis ettekandeid taustaprogrammilt ML-ile ülemineku funktsioonide ja Quadrupeli disaini kohta ning võtsid osa ka Serverlessile pühendatud ümarlauast. Neile, kes ei saanud üritusel isiklikult osaleda, räägime selles postituses kõige huvitavamatest asjadest.
Taustaarendusest masinõppeni
Mida teevad andmeinsenerid ML-is? Kuidas on taustaarendaja ja ML-inseneri ülesanded sarnased ja erinevad? Millise tee peate valima, et vahetada oma esimene elukutse teise vastu? Seda rääkis Aleksander Parinov, kes asus masinõppesse pärast 10 aastat kestnud taustatööd.
Aleksander Parinov
Täna töötab Alexander arvutinägemissüsteemide arhitektina ettevõttes X5 Retail Group ja panustab avatud lähtekoodiga projektidesse, mis on seotud arvutinägemise ja süvaõppega (github.com/creafz). Tema oskusi kinnitab osalemine masinõppevõistluste populaarseima platvormi Kaggle Masteri (kaggle.com/creafz) maailma edetabelis 100 parema hulgas.
Miks minna üle masinõppele?
Poolteist aastat tagasi kirjeldas Google'i süvaõppepõhise tehisintellekti uurimisprojekti Google Brain juht Jeff Dean, kuidas pool miljonit koodirida Google'i tõlkes asendati vaid 500 reast koosneva Tensor Flow närvivõrguga. Pärast võrgu treenimist tõusis andmete kvaliteet ja infrastruktuur muutus lihtsamaks. Näib, et see on meie helge tulevik: me ei pea enam koodi kirjutama, piisab neuronite loomisest ja nende andmete täitmisest. Kuid praktikas on kõik palju keerulisem.
ML-i infrastruktuur Google'is
Närvivõrgud on vaid väike osa infrastruktuurist (väike must ruut ülaloleval pildil). Andmete vastuvõtmiseks, töötlemiseks, salvestamiseks, kvaliteedi kontrollimiseks jne on vaja palju rohkem abisüsteeme, vajame infrastruktuuri koolituseks, masinõppekoodi juurutamiseks tootmises ja selle koodi testimiseks. Kõik need ülesanded on täpselt sarnased sellega, mida teevad taustaarendajad.
Masinõppe protsess
Mis vahe on ML-il ja taustaprogrammil?
Klassikalises programmeerimises kirjutame koodi ja see määrab programmi käitumise. ML-is on meil väike mudelikood ja palju andmeid, mida me mudelile viskame. ML-i andmed on väga olulised: sama mudel, mis on treenitud erinevatel andmetel, võib näidata täiesti erinevaid tulemusi. Probleem on selles, et andmed on peaaegu alati hajutatud ja salvestatud erinevatesse süsteemidesse (relatsiooniandmebaasid, NoSQL andmebaasid, logid, failid).
Andmete versioonimine
ML nõuab mitte ainult koodi versioonimist, nagu klassikalises arenduses, vaid ka andmeid: on vaja selgelt aru saada, mille järgi mudelit koolitati. Selleks saate kasutada populaarset Data Science'i versioonikontrolli teeki (dvc.org).
Andmete märgistus
Järgmine ülesanne on andmete märgistamine. Näiteks märgi kõik pildil olevad objektid või ütle, millisesse klassi see kuulub. Seda teevad eriteenused nagu Yandex.Toloka, mille tööd lihtsustab API olemasolu oluliselt. Raskused tekivad "inimfaktori" tõttu: sama ülesande mitmele tegijale usaldades saate parandada andmete kvaliteeti ja vähendada vigu miinimumini.
Visualiseerimine Tensor Boardis
Katsete logimine on vajalik tulemuste võrdlemiseks ja mõne mõõdiku põhjal parima mudeli valimiseks. Visualiseerimiseks on olemas suur hulk tööriistu – näiteks Tensor Board. Kuid ideaalseid viise eksperimentide salvestamiseks pole. Väikesed ettevõtted lepivad sageli Exceli tabeliga, suured aga kasutavad tulemuste andmebaasi salvestamiseks spetsiaalseid platvorme.
Masinõppe platvorme on palju, kuid ükski neist ei kata 70% vajadustest
Esimene probleem, millega tuleb kokku puutuda koolitatud mudeli tootmisse laskmisel, on seotud andmeteadlaste lemmiktööriistaga – Jupyter Notebookiga. Selles pole modulaarsust, see tähendab, et väljund on selline koodi "jalakapp", mis pole jagatud loogilisteks tükkideks - mooduliteks. Kõik on segamini: klassid, funktsioonid, konfiguratsioonid jne. Seda koodi on raske versioonida ja testida.
Kuidas sellega toime tulla? Saate ise tagasi astuda, nagu Netflix, ja luua oma platvormi, mis võimaldab teil need sülearvutid otse tootmises käivitada, edastada neile andmeid sisendiks ja saada tulemusi. Saate sundida mudelit tootmisse laskvaid arendajaid koodi tavapäraselt ümber kirjutama, mooduliteks jagama. Kuid selle lähenemisviisiga on lihtne viga teha ja mudel ei tööta nii, nagu ette nähtud. Seetõttu on ideaalne võimalus Jupyteri sülearvuti kasutamine mudelikoodi jaoks keelata. Kui andmeteadlased muidugi sellega nõus on.
Mudel musta kastina
Lihtsaim viis mudeli tootmiseks saamiseks on kasutada seda musta kastina. Sul on mingisugune mudeliklass, sulle anti mudeli kaalud (treenitud võrgu neuronite parameetrid) ja kui sa selle klassi initsialiseerid (kutsud ennustamismeetodiks, söödad seda pildiks), saad kindla ennustus kui väljund. See, mis sees toimub, ei oma tähtsust.
Eraldi serveriprotsess mudeliga
Samuti saab tõsta teatud eraldi protsessi ja saata selle läbi RPC järjekorra (koos piltide või muude lähteandmetega. Väljundis saame ennustused.
Näide mudeli kasutamisest Flaskis:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Selle lähenemisviisi probleem on jõudluse piiramine. Oletame, et meil on andmeteadlaste kirjutatud Phytoni kood, mis on aeglane ja me tahame maksimaalset jõudlust välja pigistada. Selleks saate kasutada tööriistu, mis teisendavad koodi natiivseks või teisendavad selle muuks tootmiseks kohandatud raamistikuks. Selliseid tööriistu on iga raamistiku jaoks, kuid ideaalseid pole olemas; peate need ise lisama.
ML-i infrastruktuur on sama, mis tavalisel taustaprogrammil. Seal on Docker ja Kubernetes, ainult Dockeri jaoks peate installima käitusaja NVIDIA-st, mis võimaldab konteineris olevatele protsessidele juurdepääsu hosti videokaartidele. Kubernetes vajab pistikprogrammi, et saaks videokaartidega servereid hallata.
Erinevalt klassikalisest programmeerimisest on ML-i puhul infrastruktuuris palju erinevaid liikuvaid elemente, mida tuleb kontrollida ja testida - näiteks andmetöötluskood, mudelitreeningu konveier ja tootmine (vt ülaltoodud diagrammi). Oluline on testida koodi, mis ühendab erinevaid torujuhtmete tükke: tükke on palju ja probleemid tekivad sageli mooduli piiridel.
Kuidas AutoML töötab
AutoML-i teenused lubavad valida teie eesmärkide jaoks optimaalse mudeli ja seda koolitada. Kuid peate mõistma: andmed on ML-is väga olulised, tulemus sõltub nende ettevalmistamisest. Märgistust teevad inimesed, mis on täis vigu. Ilma range kontrollita võib tulemuseks olla prügi ja protsessi pole veel võimalik automatiseerida, vaja on spetsialistide - andmeteadlaste - kontrolli. See on koht, kus AutoML laguneb. Kuid see võib olla kasulik arhitektuuri valimisel – kui olete andmed juba ette valmistanud ja soovite parima mudeli leidmiseks katsete seeriat läbi viia.
Kuidas masinõppesse siseneda
Lihtsaim viis ML-i pääsemiseks on arendada Pythonis, mida kasutatakse kõigis süvaõppe raamistikes (ja tavalistes raamistikes). See keel on sellel tegevusalal praktiliselt kohustuslik. C++ kasutatakse mõnede arvutinägemise ülesannete jaoks, näiteks isejuhtivate autode juhtimissüsteemides. JavaScript ja Shell – visualiseerimiseks ja sellisteks kummalisteks asjadeks nagu neuroni käivitamine brauseris. Java ja Scala kasutatakse suurandmetega töötamiseks ja masinõppeks. R-i ja Juliat armastavad inimesed, kes uurivad matemaatilist statistikat.
Kõige mugavam viis alustuseks praktiliste kogemuste saamiseks on Kaggle, mõnel platvormi konkursil osalemine annab rohkem kui aasta teooriaõpinguid. Sellel platvormil saate võtta kellegi teise postitatud ja kommenteeritud koodi ning proovida seda täiustada, oma eesmärkidele optimeerida. Boonus – teie Kaggle’i auaste mõjutab teie palka.
Teine võimalus on liituda ML-i meeskonnaga taustaarendajana. On palju masinõppega idufirmasid, kus saate kogemusi omandada, aidates kolleegidel nende probleeme lahendada. Lõpuks saate liituda ühe andmeteadlaste kogukonnaga – Open Data Science (ods.ai) ja teistega.
Kõneleja postitas lingile teema kohta lisateavet
"Quadrupel" - portaali "Riigiteenused" suunatud teavituste teenus
Jevgeni Smirnov
Järgmisena esines e-riigi taristu arendamise osakonna juhataja Jevgeni Smirnov, kes rääkis Quadruple'ist. See on suunatud teavitusteenus Gosuslugi portaalile (gosuslugi.ru), mis on Runeti enimkülastatud valitsuse ressurss. Päevane vaatajaskond on 2,6 miljonit, kokku on saidil registreeritud kasutajaid 90 miljonit, kellest 60 miljonit on kinnitatud. Portaali API koormus on 30 tuhat RPS-i.
Riigiteenuste taustaprogrammis kasutatavad tehnoloogiad
“Quadrupel” on sihitud teavitamisteenus, mille abil saab kasutaja spetsiaalsete teavitamisreeglite seadistamise teel pakkumise teenuse kohta talle kõige sobivamal hetkel. Peamised nõuded teenuse arendamisel olid paindlikud seadistused ja piisav aeg postitamiseks.
Kuidas Quadrupel toimib?
Ülaltoodud diagramm näitab ühte Quadrupeli tööreeglitest, kasutades näitena olukorda, kus juhiluba on vaja asendada. Esiteks otsib teenus kasutajaid, kelle aegumiskuupäev aegub kuu aja pärast. Neile näidatakse bännerit pakkumisega vastava teenuse saamiseks ja e-posti teel saadetakse teade. Nendel kasutajatel, kelle tähtaeg on juba möödas, muutuvad bänner ja e-kiri. Pärast edukat õiguste vahetamist saab kasutaja muid teateid – ettepanekuga identiteedis olevaid andmeid uuendada.
Tehnilisest vaatenurgast on tegemist keeruliste skriptidega, milles kood on kirjutatud. Sisend on andmed, väljund on tõene/väär, sobitatud/ei ühti. Kokku on üle 50 reegli – alates kasutaja sünnipäeva määramisest (praegune kuupäev võrdub kasutaja sünnikuupäevaga) kuni keeruliste olukordadeni. Iga päev tuvastavad need reeglid umbes miljon vastet – inimesi, keda tuleb teavitada.
Quadrupeli teavituskanalid
Quadrupeli kapoti all on andmebaas, kuhu salvestatakse kasutajaandmeid, ja kolm rakendust:
- Töötaja mõeldud andmete uuendamiseks.
- Puhkuse API korjab ja toimetab bännerid ise portaali ja mobiilirakendusse.
- Scheduler alustab tööd bännerite või masspostituste ümberarvutamisega.
Andmete värskendamiseks on taustaprogramm sündmustepõhine. Kaks liidest - puhkus või JMS. Sündmusi on palju, enne salvestamist ja töötlemist need koondatakse, et mitte teha tarbetuid päringuid. Andmebaas ise, tabel, kuhu andmeid salvestatakse, näeb välja nagu võtmeväärtuste hoidla – kasutaja võti ja väärtus ise: lipud, mis näitavad asjakohaste dokumentide olemasolu või puudumist, nende kehtivusaega, koondatud statistika teenuste järjekorra kohta see kasutaja ja nii edasi.
Pärast andmete salvestamist seatakse JMS-is ülesanne, et bännerid arvutatakse kohe ümber – see tuleb kohe veebis kuvada. Süsteem käivitub öösel: JMS-i visatakse kasutajate intervallidega ülesanded, mille järgi tuleb reeglid ümber arvutada. Selle korjavad üles ümberarvutamisega seotud protsessorid. Seejärel lähevad töötlemistulemused järgmisse järjekorda, mis kas salvestab bännerid andmebaasi või saadab teenusele kasutajate teavitamise ülesanded. Protsess võtab aega 5-7 tundi, see on kergesti skaleeritav tänu sellele, et alati saab kas töötlejaid lisada või eksemplare uute töötlejatega tõsta.
Teenus töötab päris hästi. Kuid andmemaht kasvab, kuna kasutajaid on rohkem. See toob kaasa andmebaasi koormuse suurenemise – isegi kui võtta arvesse asjaolu, et Rest API vaatab koopiat. Teine punkt on JMS, mis, nagu selgus, pole oma suure mälukulu tõttu kuigi sobiv. Järjekorra ületäitumise oht on suur, mis põhjustab JMS-i krahhi ja töötlemise seiskumise. Pärast seda on võimatu JMS-i tõsta ilma logide tühjendamiseta.
Probleemid on plaanis lahendada shardingi abil, mis võimaldab tasakaalustada andmebaasi koormust. Samuti on kavas muuta andmete salvestamise skeemi ja muuta JMS Kafka vastu - tõrketaluvam lahendus, mis lahendab mäluprobleemid.
Backend-as-a-Service vs. Serverita
Vasakult paremale: Aleksander Borgart, Andrei Tomilenko, Nikolai Markov, Ara Israelyan
Taustaprogramm teenusena või serverita lahendusena? Ümarlauas selle pakilise küsimuse arutelul osalesid:
- Ara Israelyan, CTO CTO ja Scorocode'i asutaja.
- Nikolay Markov, Aligned Research Groupi vanemandmeinsener.
- Andrey Tomilenko, RUVDSi arendusosakonna juhataja.
Vestlust juhtis vanemarendaja Alexander Borgart. Debatte, milles ka kuulajad osalesid, tutvustame lühendatult.
— Mis on teie arusaamises Serverless?
Andrew: See on arvutusmudel – Lambda funktsioon, mis peab andmeid töötlema nii, et tulemus sõltuks ainult andmetest. Mõiste pärines kas Google'ilt või Amazonilt ja selle AWS Lambda teenuselt. Teenusepakkujal on lihtsam sellist funktsiooni hallata, eraldades selle jaoks võimsuse kogumi. Erinevaid kasutajaid saab samades serverites iseseisvalt arvestada.
Nicholas: Lihtsamalt öeldes viime mingi osa oma IT infrastruktuurist ja äriloogikast pilve, allhankele.
Ara: arendajate poolt – hea katse ressursse kokku hoida, turundajate poolt – rohkem raha teenida.
— Kas serverita on sama mis mikroteenused?
Nicholas: Ei, Serverless on rohkem arhitektuuriorganisatsioon. Mikroteenus on mingi loogika aatomüksus. Serverita on lähenemine, mitte "eraldi üksus".
Ara: Serverita funktsiooni saab pakendada mikroteenusesse, kuid see ei ole enam serverita, see lakkab olemast Lambda funktsioon. Serverlessis hakkab funktsioon tööle alles siis, kui seda taotletakse.
Andrew: Nad erinevad oma eluea jooksul. Käivitasime lambda funktsiooni ja unustasime selle. See töötas paar sekundit ja järgmine klient saab oma taotlust teises füüsilises masinas töödelda.
— Kumb kaalub paremini?
Ara: horisontaalselt skaleerimisel käituvad Lambda funktsioonid täpselt samamoodi nagu mikroteenused.
Nicholas: olenemata sellest, kui palju koopiaid seadistate, on neid sama palju; Serverivabal pole skaleerimisega probleeme. Tegin Kubernetesis koopiakomplekti, käivitasin 20 eksemplari "kusagil" ja teile tagastati 20 anonüümset linki. Edasi!
— Kas Serverlessis on võimalik taustaprogrammi kirjutada?
Andrew: Teoreetiliselt, aga sellel pole mõtet. Lambda funktsioonid põhinevad ühel hoidlal – me peame tagama garantii. Näiteks kui kasutaja on sooritanud teatud tehingu, siis järgmine kord, kui ta ühendust võtab, peaks ta nägema: tehing on tehtud, raha on krediteeritud. Selle kõne korral blokeeritakse kõik lambda funktsioonid. Tegelikult muutub hulk serverita funktsioone üheks teenuseks, millel on andmebaasi üks kitsaskoht.
— Millistes olukordades on mõttekas kasutada serverita arhitektuuri?
Andrew: ülesanded, mis ei vaja jagatud salvestusruumi – sama kaevandamine, plokiahel. Kus peate palju loendama. Kui teil on palju arvutusvõimsust, siis saate defineerida funktsiooni nagu "arvuta seal millegi räsi..." Aga andmesalvestusega saate probleemi lahendada, võttes näiteks Amazonist Lambda funktsioonid ja nende hajutatud salvestusruumi . Ja selgub, et kirjutate tavateenust. Lambda funktsioonid pääsevad salvestusruumi juurde ja annavad kasutajale mingisuguse vastuse.
Nicholas: Serverlessis töötavate konteinerite ressursid on äärmiselt piiratud. Mälu ja kõike muud on vähe. Aga kui kogu teie infrastruktuur on täielikult juurutatud mõnes pilves - Google, Amazon - ja teil on nendega alaline leping, kõige selle jaoks on eelarve, siis saate mõne töö jaoks kasutada serverita konteinereid. Selle infrastruktuuri sees on vaja olla, sest kõik on kohandatud konkreetses keskkonnas kasutamiseks. See tähendab, et kui olete valmis kõike pilveinfrastruktuuriga siduma, võite katsetada. Eeliseks on see, et te ei pea seda infrastruktuuri haldama.
Ara: See, et Serverless ei nõua Kubernetese, Dockeri haldamist, Kafka jms installimist, on enesepettus. Sama Amazon ja Google installivad seda. Teine asi on see, et teil on SLA. Sama hästi võite kõike sisse osta, selle asemel, et seda ise kodeerida.
Andrew: Serverita on iseenesest odav, kuid teiste Amazoni teenuste – näiteks andmebaasi – eest tuleb palju maksta. Inimesed on nad juba kohtusse kaevanud, kuna nad nõudsid API värava eest pööraseid rahasummasid.
Ara: Kui me räägime rahast, siis peate selle punktiga arvestama: kogu koodi Serverlessi ülekandmiseks peate ettevõttes kogu arendusmetoodika 180 kraadi pöörama. See võtab palju aega ja raha.
— Kas Amazoni ja Google'i tasulisele Serverlessile on väärt alternatiive?
Nicholas: Kubernetes käivitate mingisuguse töö, see jookseb ja sureb – see on arhitektuuri seisukohast üsna serverivaba. Kui soovid luua tõeliselt huvitavat äriloogikat järjekordade ja andmebaasidega, siis pead selle peale veidi rohkem mõtlema. Seda kõike saab lahendada Kubernetesest lahkumata. Ma ei viitsiks täiendavat rakendamist venitada.
— Kui oluline on Serverlessis toimuva jälgimine?
Ara: oleneb süsteemi arhitektuurist ja ärinõuetest. Põhimõtteliselt peab pakkuja esitama aruandluse, mis aitab devopsi meeskonnal võimalikke probleeme mõista.
Nicholas: Amazonil on CloudWatch, kus voogesitatakse kõiki logisid, sealhulgas Lambda logisid. Integreerige logi edastamine ja kasutage vaatamiseks, hoiatamiseks ja muuks eraldi tööriista. Saate toppida agente alustatud konteineritesse.
- Võtame selle kokku.
Andrew: Lambda funktsioonidele mõtlemine on kasulik. Kui loote ise teenuse – mitte mikroteenuse, vaid sellise, mis kirjutab päringu, pääseb juurde andmebaasile ja saadab vastuse –, lahendab Lambda funktsioon mitmeid probleeme: mitme lõimega, skaleeritavusega jne. Kui teie loogika on nii üles ehitatud, siis tulevikus saate need lambdad mikroteenustesse üle kanda või kasutada kolmandate osapoolte teenuseid nagu Amazon. Tehnika on kasulik, idee on huvitav. Kui õigustatud see äri jaoks on, on endiselt lahtine küsimus.
Nikolay: Serverivaba on parem kasutada tööülesannete jaoks kui mõne äriloogika arvutamiseks. Ma pean seda alati sündmuste töötlemiseks. Kui teil on see Amazonis, kui olete Kubernetesis, siis jah. Vastasel juhul peate tegema üsna palju pingutusi, et Serverless ise tööle saada. Tuleb vaadata konkreetset ärijuhtumit. Näiteks üks minu ülesannetest on praegu järgmine: kui failid ilmuvad kettale teatud vormingus, pean need Kafkasse üles laadima. Võin kasutada WatchDog või Lambda. Loogika seisukohalt sobivad mõlemad variandid, kuid teostuse poolest on Serverless keerulisem ja eelistan lihtsamat, ilma Lambdata.
Ara: Serverless on huvitav, rakendatav ja tehniliselt väga ilus idee. Varem või hiljem jõuab tehnoloogia punkti, kus mis tahes funktsioon käivitub vähem kui 100 millisekundiga. Siis ei teki põhimõtteliselt küsimustki, kas ooteaeg on kasutaja jaoks kriitiline. Samas sõltub Serverlessi rakendatavus, nagu kolleegid juba ütlesid, täielikult äriprobleemist.
Täname oma sponsoreid, kes meid palju aitasid:
- IT konverentsiruum «» konverentsi saidi jaoks.
- IT-ürituste kalender ja väljaanne"» teabetoe ja uudiste saamiseks.
- «"kingituste eest.
- ühisloomeks.
- "Elektroonilise Side Assotsiatsioon" teie osaluse ja kogemuste eest.
- Peasponsor - kõigi jaoks!
Allikas: www.habr.com