Konferencija Habr nije debitantska priča. Ranije smo održavali prilično velike Toster događaje za 300-400 ljudi, ali sada smo odlučili da će mali tematski sastanci biti relevantni, čiji smjer možete postaviti, na primjer, u komentarima. Prva konferencija ovog formata održana je u srpnju i bila je posvećena backend razvoju. Sudionici su poslušali izvješća o značajkama prijelaza s backenda na ML i o dizajnu usluge Quadrupel na portalu Državnih usluga, a također su sudjelovali na okruglom stolu posvećenom Serverless. Za one koji nisu mogli osobno prisustvovati događaju, u ovom postu donosimo najzanimljivije stvari.
Od backend razvoja do strojnog učenja
Što inženjeri podataka rade u ML-u? Koliko su zadaci backend developera i ML inženjera slični, a koliko različiti? Kojim putem trebate proći da svoju prvu profesiju promijenite u drugu? To je rekao Alexander Parinov, koji je krenuo u strojno učenje nakon 10 godina rada u pozadini.
Aleksandar Parinov
Danas Alexander radi kao arhitekt sustava računalnog vida u X5 Retail Group i pridonosi Open Source projektima koji se odnose na računalni vid i dubinsko učenje (github.com/creafz). Njegove vještine potvrđuje sudjelovanje u top 100 svjetske ljestvice Kaggle Mastera (kaggle.com/creafz), najpopularnije platforme za natjecanja u strojnom učenju.
Zašto prijeći na strojno učenje
Prije godinu i pol Jeff Dean, voditelj Google Braina, Googleovog istraživačkog projekta umjetne inteligencije temeljenog na dubokom učenju, opisao je kako je pola milijuna redaka koda u Google Translateu zamijenjeno neuronskom mrežom Tensor Flow koja se sastoji od samo 500 redaka. Nakon osposobljavanja mreže, kvaliteta podataka je porasla, a infrastruktura je postala jednostavnija. Čini se da je to naša svijetla budućnost: više ne moramo pisati kod, dovoljno je napraviti neurone i napuniti ih podacima. Ali u praksi je sve mnogo kompliciranije.
ML infrastruktura u Googleu
Neuronske mreže su samo mali dio infrastrukture (mali crni kvadrat na gornjoj slici). Potrebno je mnogo više pomoćnih sustava za primanje podataka, njihovu obradu, pohranjivanje, provjeru kvalitete itd., potrebna nam je infrastruktura za obuku, implementaciju koda za strojno učenje u proizvodnji i testiranje tog koda. Svi ovi zadaci potpuno su slični onome što rade pozadinski programeri.
Proces strojnog učenja
Koja je razlika između ML-a i backend-a?
U klasičnom programiranju mi pišemo kod i on diktira ponašanje programa. U ML-u imamo mali kod modela i puno podataka koje bacamo na model. Podaci u ML-u vrlo su važni: isti model obučen na različitim podacima može pokazati potpuno različite rezultate. Problem je u tome što su podaci gotovo uvijek raštrkani i pohranjeni u različitim sustavima (relacijske baze podataka, NoSQL baze podataka, zapisnici, datoteke).
Verzija podataka
ML zahtijeva izradu verzija ne samo koda, kao u klasičnom razvoju, već i podataka: potrebno je jasno razumjeti na čemu je model treniran. Da biste to učinili, možete koristiti popularnu biblioteku Data Science Version Control (dvc.org).
Označavanje podataka
Sljedeći zadatak je označavanje podataka. Na primjer, označi sve predmete na slici ili reci kojem razredu pripada. To rade posebne usluge kao što je Yandex.Toloka, rad s kojim je uvelike pojednostavljen prisutnošću API-ja. Poteškoće nastaju zbog “ljudskog faktora”: možete poboljšati kvalitetu podataka i svesti pogreške na minimum ako isti zadatak povjerite nekoliko izvođača.
Vizualizacija u Tensor Boardu
Zapisivanje eksperimenata potrebno je za usporedbu rezultata i odabir najboljeg modela na temelju nekih metrika. Postoji veliki skup alata za vizualizaciju - na primjer, Tensor Board. Ali ne postoje idealni načini pohranjivanja eksperimenata. Male tvrtke često se snalaze s proračunskom tablicom u Excelu, dok velike koriste posebne platforme za pohranu rezultata u bazu podataka.
Postoje mnoge platforme za strojno učenje, ali niti jedna ne pokriva 70% potreba
Prvi problem s kojim se treba suočiti prilikom stavljanja obučenog modela u proizvodnju vezan je za omiljeni alat podatkovnih znanstvenika – Jupyter Notebook. U njemu nema modularnosti, odnosno izlaz je takva "krpa" koda koji nije podijeljen na logičke dijelove - module. Sve je pomiješano: klase, funkcije, konfiguracije itd. Ovaj kod je teško verzirati i testirati.
Kako se nositi s ovim? Možete se povući, poput Netflixa, i stvoriti vlastitu platformu koja vam omogućuje pokretanje ovih prijenosnih računala izravno u proizvodnji, prijenos podataka na njih kao ulaz i postizanje rezultata. Možete prisiliti programere koji uvode model u proizvodnju da normalno prepišu kod, razlažući ga na module. Ali s ovim pristupom lako je pogriješiti i model neće raditi kako je predviđeno. Stoga je idealna opcija zabraniti korištenje Jupyter Notebooka za kod modela. Ako, naravno, znanstvenici podataka pristanu na to.
Model kao crna kutija
Najlakši način da se model pusti u proizvodnju je da se koristi kao crna kutija. Imate neku vrstu klase modela, dobili ste težine modela (parametri neurona obučene mreže), a ako inicijalizirate ovu klasu (pozovete metodu predviđanja, ubacite joj sliku), dobit ćete određenu predviđanje kao izlaz. Ono što se događa unutra nije važno.
Odvojeni proces poslužitelja s modelom
Također možete pokrenuti određeni zasebni proces i poslati ga kroz RPC red (sa slikama ili drugim izvornim podacima. Na izlazu ćemo dobiti predviđanja.
Primjer korištenja modela u Flasku:
@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)
Problem s ovim pristupom je ograničenje performansi. Recimo da imamo Phyton kod koji su napisali znanstvenici za podatke koji je spor i želimo izvući maksimalnu izvedbu. Da biste to učinili, možete koristiti alate koji pretvaraju kod u nativni ili ga pretvaraju u drugi okvir prilagođen za proizvodnju. Za svaki framework postoje takvi alati, ali nema idealnih; morat ćete ih sami dodati.
Infrastruktura u ML-u ista je kao i u običnoj pozadini. Postoje Docker i Kubernetes, samo za Docker morate instalirati runtime iz NVIDIA-e, koji procesima unutar spremnika omogućuje pristup video karticama u hostu. Kubernetes treba dodatak kako bi mogao upravljati poslužiteljima s video karticama.
Za razliku od klasičnog programiranja, u slučaju ML-a postoji mnogo različitih pokretnih elemenata u infrastrukturi koje je potrebno provjeriti i testirati - na primjer, kod za obradu podataka, cjevovod za obuku modela i proizvodnja (vidi gornji dijagram). Važno je testirati kod koji povezuje različite dijelove cjevovoda: ima mnogo dijelova, a problemi vrlo često nastaju na granicama modula.
Kako AutoML radi
AutoML usluge obećavaju da će odabrati optimalan model za vaše potrebe i osposobiti ga. Ali morate razumjeti: podaci su vrlo važni u ML-u, rezultat ovisi o njihovoj pripremi. Označavanje rade ljudi, što je prepuno grešaka. Bez stroge kontrole, rezultat može biti smeće, a još nije moguće automatizirati proces; potrebna je provjera stručnjaka - znanstvenika podataka. Ovdje se AutoML kvari. Ali može biti korisno za odabir arhitekture - kada ste već pripremili podatke i želite pokrenuti niz eksperimenata kako biste pronašli najbolji model.
Kako ući u strojno učenje
Najlakši način da uđete u ML je ako razvijate u Pythonu, koji se koristi u svim okvirima za duboko učenje (i regularnim okvirima). Ovaj jezik je praktički obavezan za ovo područje djelovanja. C++ se koristi za neke zadatke računalnog vida, na primjer, u kontrolnim sustavima za samovozeće automobile. JavaScript i Shell - za vizualizaciju i takve čudne stvari kao što je pokretanje neurona u pregledniku. Java i Scala koriste se pri radu s velikim podacima i za strojno učenje. R i Juliju vole ljudi koji proučavaju matematičku statistiku.
Najprikladniji način stjecanja praktičnog iskustva za početak je na Kaggleu; sudjelovanje u jednom od natjecanja platforme daje više od godinu dana učenja teorije. Na ovoj platformi možete uzeti tuđi objavljeni i komentirani kod i pokušati ga poboljšati, optimizirati za svoje potrebe. Bonus - vaš Kaggle rang utječe na vašu plaću.
Druga je mogućnost pridružiti se ML timu kao backend developer. Postoji mnogo startupa za strojno učenje u kojima možete steći iskustvo pomažući svojim kolegama u rješavanju njihovih problema. Konačno, možete se pridružiti nekoj od data scientist zajednica - Open Data Science (ods.ai) i drugima.
Dodatne informacije o temi govornik je objavio na poveznici
"Kvadrupel" - usluga ciljanih obavijesti portala "Državne službe"
Evgenij Smirnov
Sljedeći govornik bio je voditelj odjela za razvoj infrastrukture e-uprave, Evgeny Smirnov, koji je govorio o Quadrupleu. Ovo je ciljana usluga obavijesti za portal Gosuslugi (gosuslugi.ru), najposjećeniji državni resurs na Runetu. Dnevna publika je 2,6 milijuna, ukupno je 90 milijuna registriranih korisnika na stranici, od čega je 60 milijuna potvrđenih. Opterećenje API portala je 30 tisuća RPS.
Tehnologije koje se koriste u pozadini državnih službi
“Quadrupel” je usluga ciljanog obavješćivanja, uz pomoć koje korisnik dobiva ponudu za uslugu u trenutku koji mu najviše odgovara postavljanjem posebnih pravila obavješćivanja. Glavni zahtjevi pri razvoju usluge bile su fleksibilne postavke i dovoljno vremena za slanje pošte.
Kako radi Quadrupel?
Gornji dijagram prikazuje jedno od pravila rada Quadrupela na primjeru situacije s potrebom zamjene vozačke dozvole. Prvo, usluga traži korisnike kojima rok valjanosti ističe za mjesec dana. Prikazuje im se banner s ponudom za primanje odgovarajuće usluge i šalje im se poruka e-poštom. Za one korisnike kojima je rok već istekao mijenja se banner i email. Nakon uspješne razmjene prava, korisnik dobiva ostale obavijesti – s prijedlogom ažuriranja podataka u identitetu.
Tehnički gledano, radi se o groovy skriptama u kojima je napisan kod. Ulaz su podaci, izlaz je točno/netočno, odgovara/ne podudara se. Ukupno postoji više od 50 pravila - od određivanja rođendana korisnika (trenutni datum je jednak datumu rođenja korisnika) do složenih situacija. Svaki dan ova pravila identificiraju oko milijun podudaranja—ljudi koje treba obavijestiti.
Quadrupel kanali obavijesti
Ispod haube Quadrupela nalazi se baza podataka u kojoj se pohranjuju korisnički podaci te tri aplikacije:
- Radnik namijenjen za ažuriranje podataka.
- API odmora sami preuzimaju i dostavljaju bannere na portal i mobilnu aplikaciju.
- Raspored pokreće rad na preračunavanju bannera ili masovne pošte.
Za ažuriranje podataka, pozadina je vođena događajima. Dva sučelja - rest ili JMS. Ima puno događaja, prije spremanja i obrade, oni se agregiraju kako ne bi bili nepotrebni zahtjevi. Sama baza podataka, tablica u kojoj su pohranjeni podaci, izgleda kao pohrana ključnih vrijednosti - korisnički ključ i sama vrijednost: zastavice koje označavaju prisutnost ili odsutnost relevantnih dokumenata, njihov rok valjanosti, agregirana statistika o redoslijedu usluga po nalogu ovaj korisnik, i tako dalje.
Nakon spremanja podataka, u JMS-u se postavlja zadatak da se banneri odmah preračunaju - to se mora odmah prikazati na webu. Sustav se pokreće noću: zadaci se ubacuju u JMS u korisničkim intervalima, prema kojima je potrebno ponovno izračunati pravila. To preuzimaju procesori uključeni u ponovni izračun. Zatim, rezultati obrade idu u sljedeći red čekanja, koji ili sprema bannere u bazu podataka ili šalje korisničke zadatke obavijesti servisu. Proces traje 5-7 sati, lako je skalabilan zbog činjenice da uvijek možete dodati rukovatelje ili podići instance s novim rukovateljima.
Usluga radi prilično dobro. Ali količina podataka raste kako je sve više korisnika. To dovodi do povećanja opterećenja baze podataka - čak i uzimajući u obzir činjenicu da Rest API gleda repliku. Druga točka je JMS, koji, kako se pokazalo, nije baš prikladan zbog velike potrošnje memorije. Postoji visok rizik od prekoračenja reda čekanja što uzrokuje pad JMS-a i zaustavljanje obrade. Nemoguće je podići JMS nakon ovoga bez brisanja zapisa.
Probleme se planira riješiti korištenjem šardinga, što će omogućiti uravnoteženje opterećenja baze podataka. Također postoje planovi za promjenu sheme pohrane podataka i promjenu JMS-a u Kafku - rješenje otpornije na pogreške koje će riješiti probleme s memorijom.
Backend-as-a-Service vs. Bez poslužitelja
S lijeva na desno: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend kao usluga ili rješenje bez poslužitelja? U raspravi o ovom gorućem problemu na okruglom stolu sudjelovali su:
- Ara Israelyan, CTO CTO i osnivač Scorocode-a.
- Nikolay Markov, viši inženjer podataka u Aligned Research Group.
- Andrey Tomilenko, voditelj odjela za razvoj RUVDS-a.
Razgovor je moderirao stariji programer Alexander Borgart. Tribine u kojima su sudjelovali i slušatelji donosimo u skraćenoj verziji.
— Što je po vašem mišljenju bez poslužitelja?
Andrija: Ovo je računalni model - Lambda funkcija koja mora obraditi podatke tako da rezultat ovisi samo o podacima. Izraz je došao ili od Googlea ili od Amazona i njegove usluge AWS Lambda. Davatelju je lakše rukovati takvom funkcijom dodjeljivanjem skupa kapaciteta za nju. Različiti korisnici mogu se neovisno voditi na istim poslužiteljima.
Nicholas: Pojednostavljeno rečeno, dio IT infrastrukture i poslovne logike prenosimo u oblak, u outsourcing.
ara: Od strane programera - dobar pokušaj da se uštede resursi, od strane trgovaca - da se zaradi više novca.
— Je li Serverless isto što i mikrousluge?
Nicholas: Ne, Serverless je više organizacija arhitekture. Mikroservis je atomska jedinica neke logike. Bez poslužitelja je pristup, a ne "zaseban entitet".
ara: Funkcija bez poslužitelja može se upakirati u mikroservis, ali to više neće biti bez poslužitelja, prestat će biti Lambda funkcija. U Serverless, funkcija počinje raditi tek u trenutku kada se zatraži.
Andrija: Razlikuju se po životnom vijeku. Pokrenuli smo Lambda funkciju i zaboravili je. Radilo je nekoliko sekundi, a sljedeći klijent može obraditi svoj zahtjev na drugom fizičkom računalu.
— Koja vaga je bolja?
ara: Pri vodoravnom skaliranju Lambda funkcije ponašaju se potpuno isto kao mikroservisi.
Nicholas: Koliko god replika postavili, toliko će ih i biti; Bez poslužitelja nema problema sa skaliranjem. Napravio sam repliku u Kubernetesu, pokrenuo 20 instanci “negdje” i vraćeno vam je 20 anonimnih poveznica. Naprijed!
— Je li moguće napisati backend na Serverless?
Andrija: Teoretski, ali nema smisla. Lambda funkcije oslanjat će se na jedno spremište - moramo osigurati jamstvo. Na primjer, ako je korisnik izvršio određenu transakciju, tada bi sljedeći put kada kontaktira trebao vidjeti: transakcija je izvršena, sredstva su odobrena. Sve Lambda funkcije blokirat će se u ovom pozivu. Zapravo, hrpa funkcija bez poslužitelja pretvorit će se u jednu uslugu s jednom uskom grlu pristupne točke bazi podataka.
— U kojim situacijama ima smisla koristiti arhitekturu bez poslužitelja?
Andrija: Zadaci koji ne zahtijevaju zajedničku pohranu - isto rudarenje, blockchain. Gdje morate puno brojati. Ako imate puno računalne snage, onda možete definirati funkciju kao što je “izračunaj hash nečega tamo...” Ali problem s pohranom podataka možete riješiti preuzimanjem npr. Lambda funkcija iz Amazona i njihove distribuirane pohrane . I ispada da pišete redovnu uslugu. Lambda funkcije pristupit će pohrani i dati neku vrstu odgovora korisniku.
Nicholas: Spremnici koji se pokreću bez poslužitelja iznimno su ograničeni u resursima. Malo je memorije i svega ostalog. Ali ako je vaša cijela infrastruktura u cijelosti postavljena na nekom oblaku - Google, Amazon - i imate trajni ugovor s njima, postoji budžet za sve to, onda za neke zadatke možete koristiti Serverless kontejnere. Nužno je biti unutar te infrastrukture, jer je sve skrojeno za korištenje u specifičnom okruženju. Odnosno, ako ste spremni sve povezati s infrastrukturom oblaka, možete eksperimentirati. Prednost je što ne morate upravljati ovom infrastrukturom.
ara: Činjenica da Serverless ne zahtijeva da upravljate Kubernetesom, Dockerom, instalirate Kafku i tako dalje je samozavaravanje. Isti Amazon i Google ovo instaliraju. Druga stvar je da imate SLA. Možete sve prepustiti vanjskim suradnicima umjesto da sami kodirate.
Andrija: Bez poslužitelja sam po sebi nije skup, ali morate puno platiti za druge Amazonove usluge - na primjer, bazu podataka. Ljudi su ih već tužili jer su naplatili lude svote novca za API gate.
ara: Ako govorimo o novcu, onda morate uzeti u obzir ovu točku: morat ćete okrenuti cjelokupnu metodologiju razvoja u tvrtki za 180 stupnjeva kako biste sav kod prenijeli na Serverless. Ovo će oduzeti puno vremena i novca.
— Postoje li dostojne alternative plaćenom bez poslužitelja od Amazona i Googlea?
Nicholas: U Kubernetesu, pokrenete neku vrstu posla, on se pokrene i umre - ovo je prilično bez poslužitelja s arhitektonskog gledišta. Ako želite stvoriti stvarno zanimljivu poslovnu logiku s redovima čekanja i bazama podataka, onda trebate malo više razmisliti o tome. Sve se to može riješiti bez napuštanja Kubernetesa. Ne bih se zamarao razvlačenjem dodatne implementacije.
— Koliko je važno pratiti što se događa u Serverless?
ara: Ovisi o arhitekturi sustava i poslovnim zahtjevima. U suštini, pružatelj usluga mora pružiti izvješća koja će pomoći devops timu da razumije moguće probleme.
Nicholas: Amazon ima CloudWatch, gdje se strimuju svi zapisnici, uključujući i one iz Lambde. Integrirajte prosljeđivanje dnevnika i koristite zaseban alat za pregled, upozoravanje i tako dalje. Agente možete trpati u spremnike koje pokrenete.
- Sažmimo.
Andrija: Razmišljanje o Lambda funkcijama je korisno. Ako sami kreirate uslugu - ne mikroservis, već onaj koji piše zahtjev, pristupa bazi i šalje odgovor - Lambda funkcija rješava niz problema: s multithreadingom, skalabilnošću i tako dalje. Ako je vaša logika izgrađena na ovaj način, tada ćete u budućnosti moći prenijeti ove Lambde na mikroservise ili koristiti usluge trećih strana poput Amazona. Tehnologija je korisna, ideja zanimljiva. Koliko je to opravdano za poslovanje još je otvoreno pitanje.
Nikolay: Bez poslužitelja je bolje koristiti za operativne zadatke nego za izračunavanje neke poslovne logike. Uvijek o tome razmišljam kao o obradi događaja. Ako ga imate u Amazonu, ako ste u Kubernetesu, da. Inače ćete morati uložiti dosta truda da sami pokrenete i pokrenete Serverless. Potrebno je sagledati konkretan poslovni slučaj. Na primjer, jedan od mojih zadataka sada je: kada se datoteke pojave na disku u određenom formatu, moram ih učitati u Kafku. Mogu koristiti WatchDog ili Lambda. S logične točke gledišta, obje su opcije prikladne, ali u smislu implementacije, Serverless je kompliciraniji, a ja preferiram jednostavniji način, bez Lambde.
ara: Serverless je zanimljiva, primjenjiva i tehnički vrlo lijepa ideja. Prije ili kasnije, tehnologija će doći do točke u kojoj će se bilo koja funkcija pokretati za manje od 100 milisekundi. Tada, u načelu, neće biti pitanja je li vrijeme čekanja kritično za korisnika. Pritom, primjenjivost Serverlessa, kako su kolege već rekli, u potpunosti ovisi o poslovnom problemu.
Zahvaljujemo našim sponzorima koji su nam puno pomogli:
- IT konferencijski prostor «» za mjesto konferencije.
- Kalendar IT događanja i objava"» za informacijsku podršku i novosti.
- «"za darove.
- za zajedničko stvaranje.
- "Udruga za elektroničke komunikacije" za angažman i iskustvo.
- Glavni sponzor - za sve!
Izvor: www.habr.com