La Habr-konferenco ne estas debutrakonto. Antaŭe ni okazigis sufiĉe grandajn Toaster-aranĝojn por 300-400 homoj, sed nun ni decidis, ke trafaj estus malgrandaj temaj kunvenoj, kies direkton vi povas agordi, ekzemple, en la komentoj. La unua konferenco de ĉi tiu formato estis okazigita en julio kaj estis dediĉita al backend evoluado. Partoprenantoj aŭskultis raportojn pri la trajtoj de la transiro de la backend al ML kaj pri la dezajno de la Quadrupel-servo en la portalo de Ŝtataj Servoj, kaj ankaŭ partoprenis en ronda tablo dediĉita al Serverless. Por tiuj, kiuj ne povis ĉeesti la eventon persone, en ĉi tiu afiŝo ni rakontas al vi la plej interesajn aferojn.
De backend evoluado ĝis maŝina lernado
Kion faras datumaj inĝenieroj en ML? Kiel la taskoj de backend-programisto kaj ML-inĝeniero similas kaj malsamajn? Kian vojon vi devas preni por ŝanĝi vian unuan profesion al via dua? Ĉi tion rakontis Alexander Parinov, kiu eniris maŝinlernadon post 10 jaroj da backend-laboro.
Aleksandro Parinov
Hodiaŭ Aleksandro laboras kiel komputilvida sistemo-arkitekto ĉe X5 Retail Group kaj kontribuas al Open Source-projektoj rilataj al komputila vizio kaj profunda lernado (github.com/creafz). Liaj kapabloj estas konfirmitaj de lia partopreno en la supraj 100 de la monda rangotabelo de Kaggle Master (kaggle.com/creafz), la plej populara platformo por maŝinlernado-konkuradoj.
Kial ŝanĝi al maŝinlernado
Antaŭ unu jaro kaj duono, Jeff Dean, estro de Google Brain, la esplorprojekto pri artefarita inteligenteco bazita en profunda lernado de Guglo, priskribis kiel duonmiliono da linioj de kodo en Google Translate estis anstataŭigitaj per Tensor Flow neŭrala reto konsistanta el nur 500 linioj. Post trejnado de la reto, la kvalito de la datumoj pliiĝis kaj la infrastrukturo iĝis pli simpla. Ŝajnus, ke ĉi tio estas nia brila estonteco: ni ne plu devas skribi kodon, sufiĉas fari neŭronojn kaj plenigi ilin per datumoj. Sed en la praktiko ĉio estas multe pli komplika.
ML-infrastrukturo ĉe Google
Neŭralaj retoj estas nur malgranda parto de la infrastrukturo (la malgranda nigra kvadrato en la supra bildo). Multaj pli da helpaj sistemoj estas postulataj por ricevi datumojn, prilabori ĝin, stoki ĝin, kontroli kvaliton, ktp., ni bezonas infrastrukturon por trejnado, deplojado de maŝinlernado-kodo en produktado kaj testado de ĉi tiu kodo. Ĉiuj ĉi tiuj taskoj estas ĝuste similaj al tio, kion faras programistoj de backend.
Maŝinlernado procezo
Kio estas la diferenco inter ML kaj backend?
En klasika programado, ni skribas kodon kaj ĉi tio diktas la konduton de la programo. En ML, ni havas malgrandan modelkodon kaj multajn datumojn, kiujn ni ĵetas al la modelo. Datumoj en ML estas tre grava: la sama modelo trejnita sur malsamaj datumoj povas montri tute malsamajn rezultojn. La problemo estas, ke la datumoj preskaŭ ĉiam estas disigitaj kaj stokitaj en malsamaj sistemoj (rilataj datumbazoj, NoSQL-datumbazoj, protokoloj, dosieroj).
Datuma versio
ML postulas versioni ne nur la kodon, kiel en klasika evoluo, sed ankaŭ la datumojn: necesas klare kompreni, pri kio la modelo estis trejnita. Por fari tion, vi povas uzi la popularan bibliotekon de Data Science Version Control (dvc.org).
Markado de datumoj
La sekva tasko estas datumetikedado. Ekzemple, marku ĉiujn objektojn en la bildo aŭ diru al kiu klaso ĝi apartenas. Ĉi tio estas farita de specialaj servoj kiel Yandex.Toloka, kies laboro estas tre simpligita per la ĉeesto de API. Malfacilaĵoj aperas pro la "homa faktoro": vi povas plibonigi la kvaliton de datumoj kaj redukti erarojn al minimumo konfidante la saman taskon al pluraj prezentistoj.
Bildigo en Tensor Board
Registrado de eksperimentoj estas necesa por kompari rezultojn kaj elekti la plej bonan modelon bazitan sur iuj metrikoj. Estas granda aro da iloj por bildigo - ekzemple Tensor Board. Sed ne ekzistas idealaj manieroj konservi eksperimentojn. Malgrandaj kompanioj ofte kontentiĝas kun Excel-kalkultabelo, dum grandaj uzas specialajn platformojn por konservi rezultojn en datumbazo.
Estas multaj platformoj por maŝinlernado, sed neniu el ili kovras 70% de la bezonoj
La unua problemo, kiun oni devas alfronti kiam oni metas trejnitan modelon en produktadon, rilatas al la plej ŝatata ilo de datumsciencistoj - Jupyter Notebook. Ne estas modulareco en ĝi, tio estas, la eligo estas tia "piedtuko" de kodo, kiu ne estas dividita en logikaj pecoj - moduloj. Ĉio estas miksita: klasoj, funkcioj, agordoj, ktp. Ĉi tiu kodo estas malfacile versionebla kaj testita.
Kiel trakti ĉi tion? Vi povas rezigni vin, kiel Netflix, kaj krei vian propran platformon, kiu ebligas al vi lanĉi ĉi tiujn tekkomputilojn rekte en produktado, transdoni datumojn al ili kiel enigo kaj akiri rezultojn. Vi povas devigi la programistojn, kiuj enkondukas la modelon en produktadon, reverki la kodon normale, rompante ĝin en modulojn. Sed kun ĉi tiu aliro estas facile erari, kaj la modelo ne funkcios kiel celite. Tial, la ideala opcio estas malpermesi la uzon de Jupyter Notebook por modelkodo. Se, kompreneble, la datumaj sciencistoj konsentas pri tio.
Modelo kiel nigra skatolo
La plej facila maniero por produkti modelon estas uzi ĝin kiel nigran skatolon. Vi havas ian modelklason, vi ricevis la pezojn de la modelo (parametroj de la neŭronoj de la trejnita reto), kaj se vi pravigigas ĉi tiun klason (voku la prognozan metodon, nutru al ĝi bildon), vi ricevos certan. prognozo kiel eligo. Kio okazas interne ne gravas.
Aparta servila procezo kun modelo
Vi ankaŭ povas levi certan apartan procezon kaj sendi ĝin per RPC-vico (kun bildoj aŭ aliaj fontaj datumoj. Ĉe la eligo ni ricevos prognozojn.
Ekzemplo de uzado de modelo en Flask:
@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)
La problemo kun ĉi tiu aliro estas la agado-limigo. Ni diru, ke ni havas Phyton-kodon skribitan de datumsciencistoj, kiu estas malrapida, kaj ni volas elpremi maksimuman rendimenton. Por fari tion, vi povas uzi ilojn, kiuj konvertas la kodon en indiĝenan aŭ konverti ĝin en alian kadron adaptitan por produktado. Estas tiaj iloj por ĉiu kadro, sed ne ekzistas idealaj; vi devos aldoni ilin mem.
La infrastrukturo en ML estas la sama kiel en regula backend. Estas Docker kaj Kubernetes, nur por Docker vi devas instali rultempon de NVIDIA, kio permesas al procezoj ene de la ujo aliri videokartojn en la gastiganto. Kubernetes bezonas kromprogramon por ke ĝi povu administri servilojn per vidkartoj.
Male al klasika programado, en la kazo de ML ekzistas multaj malsamaj movaj elementoj en la infrastrukturo kiuj devas esti kontrolitaj kaj provitaj - ekzemple, datumtraktadkodo, modeltrejnaddukto kaj produktado (vidu diagramon supre). Gravas testi la kodon, kiu ligas malsamajn pecojn de duktoj: estas multaj pecoj, kaj problemoj tre ofte aperas ĉe modullimoj.
Kiel funkcias AutoML
AutoML-servoj promesas elekti la optimuman modelon por viaj celoj kaj trejni ĝin. Sed vi devas kompreni: datumoj estas tre gravaj en ML, la rezulto dependas de ĝia preparado. Markado estas farita de homoj, kiu estas plena de eraroj. Sen strikta kontrolo, la rezulto povas esti rubo, kaj ankoraŭ ne eblas aŭtomatigi la procezon; kontrolado de specialistoj - datumsciencistoj - necesas. Jen kie AutoML rompiĝas. Sed ĝi povas esti utila por elekti arkitekturon - kiam vi jam preparis la datumojn kaj volas fari serion da eksperimentoj por trovi la plej bonan modelon.
Kiel eniri maŝinlernadon
La plej facila maniero eniri ML estas se vi disvolviĝas en Python, kiu estas uzata en ĉiuj profundaj lernaj kadroj (kaj regulaj kadroj). Tiu ĉi lingvo estas praktike deviga por ĉi tiu agadkampo. C++ estas uzata por kelkaj komputilvidaj taskoj, ekzemple, en kontrolsistemoj por memveturantaj aŭtoj. JavaScript kaj Ŝelo - por bildigo kaj tiaj strangaĵoj kiel ruli neŭronon en la retumilo. Java kaj Scala estas uzataj kiam oni laboras kun Big Data kaj por maŝinlernado. R kaj Julia estas ŝatataj de homoj, kiuj studas matematikajn statistikojn.
La plej oportuna maniero akiri praktikan sperton por komenci estas sur Kaggle; partopreno en unu el la konkursoj de la platformo donas pli ol jaron da studado de teorio. Sur ĉi tiu platformo vi povas preni la afiŝitan kaj komentitan kodon de iu alia kaj provi plibonigi ĝin, optimumigi ĝin por viaj celoj. Gratifiko - via Kaggle-rango influas vian salajron.
Alia eblo estas aliĝi al la ML-teamo kiel backend-programisto. Estas multaj maŝinlernado-komencoj, kie vi povas akiri sperton helpante viajn kolegojn solvi iliajn problemojn. Fine, vi povas aliĝi al unu el la datumscienckomunumoj - Open Data Science (ods.ai) kaj aliaj.
La preleganto afiŝis pliajn informojn pri la temo ĉe la ligilo
"Kvadrupelo" - servo de celitaj sciigoj de la portalo "Ŝtataj Servoj"
Evgenij Smirnov
La sekva preleganto estis la estro de la departemento pri infrastruktura evoluigo de e-registaro, Evgeny Smirnov, kiu parolis pri Kvaropo. Ĉi tio estas celita sciiga servo por la portalo Gosuslugi (gosuslugi.ru), la plej vizitata registara rimedo sur la Runet. La ĉiutaga publiko estas 2,6 milionoj, entute estas 90 milionoj da registritaj uzantoj en la retejo, el kiuj 60 milionoj estas konfirmitaj. La ŝarĝo sur la portalo API estas 30 mil RPS.
Teknologioj uzataj en la backend de Ŝtataj Servoj
"Quadrupel" estas celita sciiga servo, per kiu la uzanto ricevas oferton por servo en la plej taŭga momento por li starigante specialajn sciigajn regulojn. La ĉefaj postuloj dum evoluigado de la servo estis flekseblaj agordoj kaj taŭga tempo por dissendoj.
Kiel funkcias Quadrupel?
La supra diagramo montras unu el la reguloj de funkciado de la Kvadrupelo uzante la ekzemplon de situacio kun la bezono anstataŭigi stirpermesilon. Unue, la servo serĉas uzantojn, kies limdato eksvalidiĝas post monato. Oni montras al ili standardon kun oferto ricevi la taŭgan servon kaj mesaĝo estas sendita retpoŝte. Por tiuj uzantoj, kies limdato jam eksvalidiĝis, la standardo kaj retpoŝto ŝanĝiĝas. Post sukcesa interŝanĝo de rajtoj, la uzanto ricevas aliajn sciigojn - kun propono ĝisdatigi la datumojn en la identeco.
De teknika vidpunkto, ĉi tiuj estas groovaj skriptoj en kiuj la kodo estas skribita. La enigo estas datumoj, la eligo estas vera/malvera, kongrua/ne kongrua. Estas pli ol 50 reguloj entute - de determini la naskiĝtagon de la uzanto (la nuna dato egalas al la naskiĝdato de la uzanto) ĝis kompleksaj situacioj. Ĉiutage, ĉi tiuj reguloj identigas ĉirkaŭ milionon da matĉoj—homoj, kiuj bezonas esti sciigitaj.
Kvadrupelaj sciigaj kanaloj
Sub la kapuĉo de Quadrupel estas datumbazo en kiu uzantdatenoj estas stokitaj, kaj tri aplikoj:
- Laboristo destinita por ĝisdatigi datumojn.
- Rest API prenas kaj liveras la standardojn mem al la portalo kaj poŝtelefona aplikaĵo.
- Planisto lanĉas laboron pri rekalkulado de rubandoj aŭ amasaj dissendoj.
Por ĝisdatigi datumojn, la backend estas okazigita. Du interfacoj - ripozo aŭ JMS. Estas multaj eventoj; antaŭ konservado kaj prilaborado, ili estas kunigitaj por ne fari nenecesajn petojn. La datumbazo mem, la tabelo en kiu la datumoj estas konservitaj, aspektas kiel ŝlosila valorbutiko - la ŝlosilo de la uzanto kaj la valoro mem: flagoj indikante la ĉeeston aŭ foreston de koncernaj dokumentoj, ilian validecperiodon, kunigitaj statistikoj pri la ordo de servoj per ĉi tiu uzanto, kaj tiel plu.
Post konservado de la datumoj, tasko estas agordita en JMS por ke la standardoj estu tuj rekalkulitaj - tio devas esti tuj montrata en la reto. La sistemo komenciĝas nokte: taskoj estas ĵetitaj en JMS je uzantintervaloj, laŭ kiuj la reguloj devas esti rekalkulitaj. Ĉi tio estas reprenita de la procesoroj implikitaj en la rekalkulo. Poste, la prilaboraj rezultoj iras al la sekva vico, kiu aŭ konservas la standardojn en la datumbazo aŭ sendas uzantajn sciigajn taskojn al la servo. La procezo daŭras 5-7 horojn, ĝi estas facile skalebla pro la fakto, ke vi ĉiam povas aŭ aldoni prizorgantojn aŭ levi kazojn kun novaj prizorgantoj.
La servo funkcias sufiĉe bone. Sed la volumo de datumoj kreskas ĉar estas pli da uzantoj. Ĉi tio kondukas al pliigo de la ŝarĝo sur la datumbazo - eĉ konsiderante la fakton, ke la Rest-API rigardas la kopion. La dua punkto estas JMS, kiu, kiel montriĝis, ne tre taŭgas pro sia alta memorkonsumo. Estas alta risko de vostosuperfluo kaŭzante JMS kraŝi kaj pretigado ĉesigi. Estas neeble levi JMS post ĉi tio sen malplenigi la protokolojn.
Estas planite solvi la problemojn uzante sharding, kiu permesos ekvilibrigi la ŝarĝon sur la datumbazo. Estas ankaŭ planoj ŝanĝi la datuman stokadoskemon, kaj ŝanĝi JMS al Kafka - pli tolerema solvo, kiu solvos memorproblemojn.
Backend-kiel-servo Vs. Senservilo
De maldekstre dekstren: Aleksandro Borgart, Andreo Tomilenko, Nikolao Markov, Ara Israelano
Backend kiel servo aŭ senservila solvo? Partoprenantoj en la diskuto pri ĉi tiu urĝa temo ĉe la ronda tablo estis:
- Ara Israelyan, CTO CTO kaj fondinto de Scorocode.
- Nikolay Markov, Senior Data Engineer ĉe Aligned Research Group.
- Andrey Tomilenko, estro de la disvolva fako de RUVDS.
La konversacio estis moderigita de altranga programisto Alexander Borgart. Ni prezentas la debatojn en kiuj la aŭskultantoj ankaŭ partoprenis en mallongigita versio.
— Kio estas Serverless laŭ via kompreno?
Andrei: Ĉi tio estas komputika modelo - Lambda funkcio kiu devas prilabori datumojn tiel ke la rezulto dependas nur de la datumoj. La termino venis aŭ de Google aŭ de Amazon kaj ĝia AWS Lambda servo. Estas pli facile por provizanto manipuli tian funkcion asignante aron da kapacito por ĝi. Malsamaj uzantoj povas esti sendepende kalkulitaj sur la samaj serviloj.
Nikolao: Por diri simple, ni transdonas parton de nia IT-infrastrukturo kaj komerca logiko al la nubo, al subkontraktado.
Arao: De la programistoj - bona provo ŝpari rimedojn, de la merkatistoj - por gajni pli da mono.
— Ĉu Senservilo estas sama kiel mikroservoj?
Nikolao: Ne, Serverless estas pli de arkitektura organizo. Mikroservo estas atomunuo de iu logiko. Senservilo estas aliro, ne "aparta ento".
Arao: Senservila funkcio povas esti enpakita en mikroservon, sed ĉi tio ne plu estos Senservila, ĝi ĉesos esti Lambda funkcio. En Serverless, funkcio ekfunkcias nur en la momento, kiam ĝi estas petita.
Andrei: Ili malsamas en sia vivo. Ni lanĉis la funkcion Lambda kaj forgesis ĝin. Ĝi funkciis dum kelkaj sekundoj, kaj la sekva kliento povas procesi sian peton sur alia fizika maŝino.
— Kiu skvamas pli bone?
Arao: Dum skalado horizontale, Lambda funkcioj kondutas ekzakte same kiel mikroservoj.
Nikolao: Kia ajn nombro da kopioj vi starigis, estos tiom da ili; Senservilo ne havas problemojn pri skalo. Mi faris kopion fiksitan en Kubernetes, lanĉis 20 ekzemplojn "ie", kaj 20 anonimaj ligiloj estis resenditaj al vi. Antaŭen!
— Ĉu eblas skribi backend sur Serverless?
Andrei: Teorie, sed ĝi ne havas sencon. Lambda funkcioj dependos de ununura deponejo - ni devas certigi garantion. Ekzemple, se uzanto faris certan transakcion, tiam la venontan fojon kiam li kontaktos li devus vidi: la transakcio estis farita, la fundoj estis kredititaj. Ĉiuj Lambda funkcioj blokiĝos ĉe ĉi tiu voko. Fakte, amaso da Senservilaj funkcioj transformiĝos en ununuran servon kun unu botela alirpunkto al la datumbazo.
— En kiuj situacioj havas sencon uzi senservila arkitekturo?
Andrei: Taskoj kiuj ne postulas komunan stokadon - la sama minado, blokĉeno. Kie vi devas fari multe da kalkulado. Se vi havas multe da komputika potenco, tiam vi povas difini funkcion kiel "kalkuli la haŝon de io tie..." Sed vi povas solvi la problemon kun datumstokado prenante, ekzemple, Lambda funkcioj de Amazon kaj ilia distribuita stokado. . Kaj rezultas, ke vi skribas regulan servon. Lambda funkcioj aliros la stokadon kaj provizos ian respondon al la uzanto.
Nikolao: Ujoj kiuj funkcias en Serverless estas ekstreme limigitaj en rimedoj. Estas malmulte da memoro kaj ĉio alia. Sed se via tuta infrastrukturo estas deplojita tute sur iu nubo - Google, Amazon - kaj vi havas konstantan kontrakton kun ili, ekzistas buĝeto por ĉio ĉi, tiam por iuj taskoj vi povas uzi Senservilajn ujojn. Necesas esti ene de ĉi tiu infrastrukturo, ĉar ĉio estas adaptita por uzo en specifa medio. Tio estas, se vi pretas ligi ĉion al la nuba infrastrukturo, vi povas eksperimenti. La avantaĝo estas, ke vi ne devas administri ĉi tiun infrastrukturon.
Arao: La fakto, ke Serverless ne postulas, ke vi administru Kubernetes, Docker, instalu Kafka, kaj tiel plu estas memtrompo. La sama Amazon kaj Google instalas ĉi tion. Alia afero estas, ke vi havas SLA. Vi ankaŭ povus subkontrakti ĉion anstataŭ kodi ĝin mem.
Andrei: Senservilo mem estas malmultekosta, sed vi devas pagi multe por aliaj Amazon-servoj - ekzemple, la datumbazo. Homoj jam jurpersekutis ilin ĉar ili ŝargis frenezajn monsumojn por la API-pordego.
Arao: Se ni parolas pri mono, tiam vi devas konsideri ĉi tiun punkton: vi devos turni la tutan disvolvan metodaron en la kompanio 180 gradojn por transdoni la tutan kodon al Serverless. Ĉi tio prenos multan tempon kaj monon.
— Ĉu ekzistas indaj alternativoj al pagita Serverless de Amazon kaj Google?
Nikolao: En Kubernetes, vi lanĉas ian laboron, ĝi funkcias kaj mortas - ĉi tio estas sufiĉe Senservila el arkitektura vidpunkto. Se vi volas krei vere interesan komercan logikon kun vicoj kaj datumbazoj, tiam vi devas pensi iom pli pri ĝi. Ĉio ĉi povas esti solvita sen forlasi Kubernetes. Mi ne ĝenus treni plian efektivigon.
— Kiom gravas kontroli tion, kio okazas en Serverless?
Arao: Dependas de sistema arkitekturo kaj komercaj postuloj. Esence, la provizanto devas provizi raportojn, kiuj helpos la devops-teamo kompreni eblajn problemojn.
Nikolao: Amazon havas CloudWatch, kie ĉiuj protokoloj estas elsenditaj, inkluzive de tiuj de Lambda. Integri protokolan plusendon kaj uzu apartan ilon por vidi, atentigi ktp. Vi povas ŝtopi agentojn en la ujojn, kiujn vi komencas.
- Ni resumu ĝin.
Andrei: Pensi pri Lambda funkcioj estas utila. Se vi mem kreas servon - ne mikroservon, sed unu kiu skribas peton, aliras la datumbazon kaj sendas respondon - la Lambda funkcio solvas kelkajn problemojn: kun multfadenado, skaleblo ktp. Se via logiko estas konstruita tiamaniere, tiam en la estonteco vi povos transdoni ĉi tiujn Lambdas al mikroservoj aŭ uzi triajn servojn kiel Amazon. La teknologio estas utila, la ideo estas interesa. Kiom pravigita ĝi estas por komerco estas ankoraŭ malfermita demando.
Nikolay: Senservilo estas pli bone uzata por operaciaj taskoj ol por kalkulado de iu komerca logiko. Mi ĉiam pensas pri ĝi kiel prilaboro de evento. Se vi havas ĝin en Amazon, se vi estas en Kubernetes, jes. Alie, vi devos multe klopodi por ekfunkciigi Serverless memstare. Necesas rigardi specifan komercan kazon. Ekzemple, unu el miaj taskoj nun estas: kiam dosieroj aperas sur disko en certa formato, mi devas alŝuti ilin al Kafka. Mi povas uzi WatchDog aŭ Lambda. El logika vidpunkto, ambaŭ opcioj taŭgas, sed laŭ efektivigo, Serverless estas pli komplika, kaj mi preferas la pli simplan manieron, sen Lambda.
Arao: Senservilo estas interesa, aplikebla, kaj tre teknike bela ideo. Pli aŭ malpli frue, teknologio atingos la punkton kie ajna funkcio estos lanĉita en malpli ol 100 milisekundoj. Tiam, principe, ne estos demando, ĉu la atendotempo estas kritika por la uzanto. Samtempe, la aplikebleco de Serverless, kiel kolegoj jam diris, tute dependas de la komerca problemo.
Ni dankas niajn sponsorojn, kiuj multe helpis nin:
- IT-konferenca spaco «» por la kongresejo.
- Kalendaro de IT-okazaĵoj kaj publikigo"» por informa subteno kaj novaĵoj.
- «"por donacoj.
- por kunkreado.
- "Asocio por Elektronikaj Komunikadoj" por engaĝiĝo kaj sperto.
- Ĉefa sponsoro - por ĉiuj!
fonto: www.habr.com