Konferencija u Habru 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 biti relevantni mali tematski sastanci čiji smjer možete postaviti, na primjer, u komentarima. Prva konferencija ovog formata održana je u julu i bila je posvećena backend razvoju. Učesnici su slušali izvještaje o karakteristikama prelaska sa backend-a na ML i dizajnu Quadrupel servisa na portalu Državnih službi, a učestvovali su i na okruglom stolu posvećenom Serverless-u. Za one koji nisu bili u mogućnosti da prisustvuju događaju lično, u ovom postu ćemo vam reći najzanimljivije stvari.
Od razvoja pozadine do mašinskog učenja
Šta rade inženjeri podataka u ML-u? Po čemu su zadaci backend programera i ML inženjera slični i različiti? Koji put trebate ići da biste promijenili svoju prvu profesiju u drugu? Ovo je ispričao Aleksandar Parinov, koji je nakon 10 godina rada na pozadini krenuo u mašinsko učenje.
Alexander Parinov
Danas Alexander radi kao arhitekta sistema kompjuterskog vida u X5 Retail Group i doprinosi projektima otvorenog koda koji se odnose na kompjutersku viziju i duboko učenje (github.com/creafz). Njegove vještine potvrđuje i učešće u top 100 svjetske rang liste Kaggle Master (kaggle.com/creafz), najpopularnije platforme za takmičenja u mašinskom učenju.
Zašto preći na mašinsko učenje
Prije godinu i po, Jeff Dean, šef Google Brain, Google-ovog istraživačkog projekta umjetne inteligencije zasnovanog na dubokom učenju, opisao je kako je pola miliona linija koda u Google Translateu zamijenjeno neuronskom mrežom Tensor Flow koja se sastoji od samo 500 linija. Nakon obuke mreže, kvalitet podataka se povećao, a infrastruktura je postala jednostavnija. Čini se da je ovo 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 komplikovanije.
ML infrastruktura u Googleu
Neuronske mreže su samo mali dio infrastrukture (mali crni kvadrat na gornjoj slici). Mnogo više pomoćnih sistema je potrebno za primanje podataka, njihovu obradu, skladištenje, proveru kvaliteta itd., potrebna nam je infrastruktura za obuku, implementaciju koda za mašinsko učenje u proizvodnji i testiranje ovog koda. Svi ovi zadaci su potpuno slični onome što rade backend programeri.
Proces mašinskog učenja
Koja je razlika između ML-a i backenda?
U klasičnom programiranju mi pišemo kod i to diktira ponašanje programa. U ML-u imamo mali kod modela i puno podataka koje bacamo na model. Podaci u ML-u su vrlo 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 sistemima (relacijske baze podataka, NoSQL baze podataka, evidencije, datoteke).
Verzija podataka
ML zahtijeva verzioniranje ne samo koda, kao u klasičnom razvoju, već i podataka: potrebno je jasno razumjeti na čemu je model obučen. 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čite sve objekte na slici ili recite kojoj klasi pripada. To rade posebne usluge kao što je Yandex.Toloka, rad s kojima je uvelike pojednostavljen prisustvom API-ja. Poteškoće nastaju zbog „ljudskog faktora“: možete poboljšati kvalitet podataka i svesti greške na minimum tako što ćete isti zadatak povjeriti nekoliko izvođača.
Vizualizacija u Tensor Board-u
Evidentiranje eksperimenata je neophodno za upoređivanje rezultata i odabir najboljeg modela na osnovu nekih metrika. Postoji veliki skup alata za vizualizaciju - na primjer, Tensor Board. Ali ne postoje idealni načini za pohranjivanje eksperimenata. Male kompanije se često snalaze sa Excel tabelom, dok velike koriste posebne platforme za pohranjivanje rezultata u bazu podataka.
Postoji mnogo platformi za mašinsko učenje, ali nijedna od njih ne pokriva 70% potreba
Prvi problem sa kojim se mora suočiti prilikom puštanja obučenog modela u proizvodnju vezan je za omiljeni alat naučnika podataka - Jupyter Notebook. U njemu nema modularnosti, odnosno, izlaz je takva „papuča“ koda koja nije podijeljena na logičke dijelove - module. Sve je pomešano: klase, funkcije, konfiguracije, itd. Ovaj kod je teško verzirati i testirati.
Kako se nositi s ovim? Možete sami dati otkaz, poput Netflixa, i kreirati vlastitu platformu koja vam omogućava da pokrenete ove laptope direktno u proizvodnji, prenesete im podatke kao ulaz i dobijete rezultate. Možete natjerati programere koji uvode model u proizvodnju da normalno prepišu kod, razbijajući ga na module. Ali s ovim pristupom lako je pogriješiti, a model neće raditi kako je predviđeno. Stoga je idealna opcija da se zabrani korištenje Jupyter Notebook-a za kod modela. Ako, naravno, naučnici podataka pristanu na ovo.
Model kao crna kutija
Najlakši način da se model uvede u proizvodnju je da ga koristite kao crnu kutiju. Imate nekakvu klasu modela, date su vam težine modela (parametri neurona obučene mreže), a ako inicijalizirate ovu klasu (pozovite metodu predviđanja, ubacite je u sliku), dobićete određenu predviđanje kao izlaz. Šta se dešava unutra nije važno.
Odvojite serverski proces sa modelom
Također možete pokrenuti određeni poseban 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 naučnici podataka koji je spor i želimo da izvučemo maksimalne performanse. Da biste to učinili, možete koristiti alate koji pretvaraju kod u izvorni ili ga pretvaraju u drugi okvir prilagođen za proizvodnju. Postoje takvi alati za svaki okvir, ali ne postoje idealni; morat ćete ih sami dodati.
Infrastruktura u ML-u je ista kao u običnom backendu. Postoje Docker i Kubernetes, samo za Docker morate instalirati runtime od NVIDIA-e, što omogućava procesima unutar kontejnera da pristupe video karticama u hostu. Kubernetesu je potreban dodatak kako bi mogao upravljati serverima sa video karticama.
Za razliku od klasičnog programiranja, u slučaju ML postoji mnogo različitih pokretnih elemenata u infrastrukturi koje treba provjeriti i testirati – na primjer, kod za obradu podataka, cevovod za obuku modela i proizvodnja (vidi dijagram iznad). Važno je testirati kod koji povezuje različite dijelove cjevovoda: ima ih mnogo, a problemi se vrlo često javljaju na granicama modula.
Kako AutoML radi
AutoML usluge obećavaju odabir optimalnog modela za vaše potrebe i obuku. 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 proces još nije moguće automatizirati; potrebna je provjera stručnjaka - naučnika podataka. Ovdje se AutoML kvari. Ali može biti korisno za odabir arhitekture - kada ste već pripremili podatke i želite da pokrenete seriju eksperimenata kako biste pronašli najbolji model.
Kako ući u mašinsko učenje
Najlakši način da uđete u ML je ako razvijate u Pythonu, koji se koristi u svim okvirima dubokog učenja (i redovnim okvirima). Ovaj jezik je praktično obavezan za ovu oblast delovanja. C++ se koristi za neke zadatke kompjuterskog vida, na primjer, u kontrolnim sistemima za samovozeće automobile. JavaScript i Shell - za vizualizaciju i takve čudne stvari kao što je pokretanje neurona u pretraživaču. Java i Scala se koriste za rad sa velikim podacima i za mašinsko učenje. R i Julia vole ljudi koji proučavaju matematičku statistiku.
Najprikladniji način za stjecanje praktičnog iskustva za početak je na Kaggleu; učešće na jednom od takmičenja platforme daje više od godinu dana učenja teorije. Na ovoj platformi možete uzeti tuđi objavljen i komentiran kod i pokušati ga poboljšati, optimizirati za svoje potrebe. Bonus - vaš Kaggle rang utiče na vašu platu.
Druga opcija je da se pridružite ML timu kao backend programer. Postoji mnogo startupa za mašinsko učenje u kojima možete steći iskustvo pomažući svojim kolegama da riješe svoje probleme. Konačno, možete se pridružiti jednoj od zajednica naučnika podataka - Open Data Science (ods.ai) i drugima.
Govornik je postavio dodatne informacije o ovoj temi na linku
"Quadrupel" - usluga ciljanih obavještenja portala "Državne službe"
Evgenij Smirnov
Sljedeći govornik bio je šef odjela za razvoj infrastrukture e-uprave, Evgeny Smirnov, koji je govorio o Quadruple-u. Ovo je ciljana usluga obavještavanja za portal Gosuslugi (gosuslugi.ru), najposjećeniji vladin resurs na Runetu. Dnevna publika je 2,6 miliona, ukupno je na sajtu registrovano 90 miliona korisnika, od kojih je 60 miliona potvrđeno. Opterećenje API-ja portala je 30 hiljada RPS.
Tehnologije koje se koriste u pozadini državnih službi
“Quadrupel” je ciljana usluga obavještavanja, uz pomoć koje korisnik dobiva ponudu za uslugu u najpogodnijem trenutku za njega postavljanjem posebnih pravila obavještavanja. Glavni zahtjevi prilikom razvoja usluge bili su fleksibilna podešavanja i adekvatno vrijeme za slanje pošte.
Kako Quadrupel radi?
Gornji dijagram prikazuje jedno od pravila rada Quadrupela na primjeru situacije s potrebom zamjene vozačke dozvole. Prvo, usluga traži korisnike čiji rok trajanja ističe za mjesec dana. Pokazuje im se baner sa ponudom za primanje odgovarajuće usluge i šalje se poruka e-poštom. Za one korisnike kojima je rok već istekao, baner i email se mijenjaju. Nakon uspješne razmjene prava, korisnik dobija i druga obavještenja - sa prijedlogom ažuriranja podataka u identitetu.
Sa tehničke tačke gledišta, ovo su groovy skripte u kojima je napisan kod. Ulaz je podatak, izlaz je istinit/netačan, podudaran/nepodudaran. Ukupno postoji više od 50 pravila - od određivanja datuma rođenja korisnika (trenutni datum je jednak datumu rođenja korisnika) do složenih situacija. Svakog dana ova pravila identifikuju oko milion poklapanja – ljudi koje treba obavijestiti.
Quadrupel kanali za obavještavanje
Ispod haube Quadrupela nalazi se baza podataka u kojoj se pohranjuju korisnički podaci i tri aplikacije:
- radnik namijenjen za ažuriranje podataka.
- API za odmor preuzima i dostavlja same banere na portal i mobilnu aplikaciju.
- Planer pokreće rad na preračunavanju banera ili masovnih slanja pošte.
Za ažuriranje podataka, backend je vođen događajima. Dva interfejsa - odmor ili JMS. Događaja je puno, prije spremanja i obrade oni se agregiraju kako ne bi pravili nepotrebne zahtjeve. Sama baza podataka, tabela u kojoj se pohranjuju podaci, izgleda kao skladište vrijednosti ključa - ključ korisnika i sama vrijednost: zastavice koje ukazuju na prisustvo ili odsustvo relevantnih dokumenata, njihov rok važenja, zbirnu statistiku o redoslijedu usluga prema ovog korisnika i tako dalje.
Nakon pohranjivanja podataka, u JMS-u se postavlja zadatak tako da se baneri odmah preračunavaju - to se mora odmah prikazati na webu. Sistem se pokreće noću: zadaci se ubacuju u JMS u korisničkim intervalima, prema kojima pravila treba ponovo izračunati. To preuzimaju procesori uključeni u ponovno izračunavanje. Zatim, rezultati obrade idu u sljedeći red čekanja, koji ili sprema banere u bazu podataka ili šalje korisničku obavijest servisu. Proces traje 5-7 sati, lako je skalabilan zbog činjenice da uvijek možete dodati rukovaoce ili podići instance s novim rukovaocima.
Usluga radi dosta dobro. Ali obim 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 u repliku. Druga stvar je JMS, koji, kako se ispostavilo, nije baš prikladan zbog velike potrošnje memorije. Postoji veliki rizik od prekoračenja reda čekanja koji uzrokuje pad JMS-a i zaustavljanje obrade. Nemoguće je podići JMS nakon ovoga bez brisanja dnevnika.
Planirano je rješavanje problema korištenjem shardinga, što će omogućiti balansiranje opterećenja baze podataka. Postoje i planovi za promjenu šeme skladištenja podataka i promjenu JMS-a u Kafka - rješenje otpornije na greške koje će riješiti probleme s memorijom.
Backend-as-a-Service vs. Bez servera
S lijeva na desno: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend kao usluga ili rješenje bez servera? U raspravi o ovom hitnom pitanju na okruglom stolu učestvovali su:
- Ara Israelyan, CTO CTO i osnivač Scorocodea.
- Nikolay Markov, viši inženjer podataka u Aligned Research Group.
- Andrey Tomilenko, šef odjela za razvoj RUVDS-a.
Razgovor je moderirao stariji programer Alexander Borgart. Tribine u kojima su učestvovali i slušaoci prenosimo u skraćenoj verziji.
— Šta je po vašem mišljenju bez servera?
Andrei: Ovo je računski model - Lambda funkcija koja mora obraditi podatke tako da rezultat ovisi samo o podacima. Termin je došao ili od Googlea ili od Amazona i njegove AWS Lambda usluge. Provajderu je lakše rukovati takvom funkcijom dodjeljivanjem skupa kapaciteta za nju. Različiti korisnici mogu se nezavisno obračunati na istim serverima.
Nikolai: Jednostavnije rečeno, prenosimo dio naše IT infrastrukture i poslovne logike u oblak, na outsourcing.
Ara: Od strane programera - dobar pokušaj da se uštede resursi, od strane marketera - da zarade više novca.
— Da li je bez servera isto što i mikroservis?
Nikolai: Ne, Serverless je više organizacija arhitekture. Mikroservis je atomska jedinica neke logike. Bez servera je pristup, a ne “zaseban entitet”.
Ara: Funkcija bez servera može se upakovati u mikroservis, ali ovo više neće biti bez servera, već će prestati biti Lambda funkcija. U slučaju bez servera, funkcija počinje raditi tek u trenutku kada je zatražena.
Andrei: Razlikuju se u životu. Pokrenuli smo Lambda funkciju i zaboravili je. Radilo je nekoliko sekundi, a sljedeći klijent može obraditi svoj zahtjev na drugoj fizičkoj mašini.
— Koja vaga je bolja?
Ara: Prilikom horizontalnog skaliranja, Lambda funkcije se ponašaju potpuno isto kao i mikroservis.
Nikolai: Koji god broj replika da postavite, bit će ih isto toliko; Serverless nema problema sa skaliranjem. Napravio sam repliku u Kubernetesu, pokrenuo 20 instanci “negdje” i 20 anonimnih linkova vam je vraćeno. Naprijed!
— Da li je moguće napisati backend na serverless?
Andrei: Teoretski, ali nema smisla. Lambda funkcije će se oslanjati na jedno spremište - moramo osigurati garanciju. Na primjer, ako je korisnik izvršio određenu transakciju, onda bi sljedeći put kada kontaktira trebao vidjeti: transakcija je obavljena, sredstva su kreditirana. Sve Lambda funkcije će blokirati ovaj poziv. U stvari, gomila funkcija bez servera će se pretvoriti u jednu uslugu sa jednom uskom grlom pristupne tačke bazi podataka.
— U kojim situacijama ima smisla koristiti arhitekturu bez servera?
Andrei: Zadaci koji ne zahtijevaju zajedničku pohranu - isto rudarenje, blockchain. Gdje treba puno brojati. Ako imate veliku računarsku snagu, onda možete definirati funkciju kao što je "izračunajte hash nečega tamo..." Ali možete riješiti problem sa pohranom podataka uzimajući, na primjer, Lambda funkcije iz Amazona i njihovu distribuiranu pohranu . I ispostavilo se da pišete običnu uslugu. Lambda funkcije će pristupiti memoriji i pružiti neku vrstu odgovora korisniku.
Nikolai: Kontejneri koji rade bez servera su izuzetno ograničeni u resursima. Malo je pamćenja i svega ostalog. Ali ako je vaša cijela infrastruktura u potpunosti raspoređena na nekom oblaku - Google, Amazon - i imate trajni ugovor s njima, postoji budžet za sve to, onda za neke zadatke možete koristiti kontejnere bez servera. Neophodno je biti unutar ove infrastrukture, jer je sve skrojeno za upotrebu u specifičnom okruženju. Odnosno, ako ste spremni da sve povežete sa infrastrukturom oblaka, možete eksperimentisati. Prednost je što ne morate upravljati ovom infrastrukturom.
Ara: Činjenica da Serverless ne zahtijeva od vas da upravljate Kubernetesom, Dockerom, instalirate Kafku i tako dalje je samoobmana. Isti Amazon i Google instaliraju ovo. Druga stvar je da imate SLA. Možete i outsourcing sve umjesto da sami kodirate.
Andrei: Bez servera je sam po sebi jeftin, ali morate puno platiti za druge Amazonove usluge - na primjer, bazu podataka. Ljudi su ih već tužili jer su naplaćivali lude svote novca za API kapiju.
Ara: Ako govorimo o novcu, onda morate uzeti u obzir ovu tačku: morat ćete cijelu razvojnu metodologiju u kompaniji okrenuti za 180 stupnjeva kako biste sav kod prebacili na Serverless. Ovo će oduzeti mnogo vremena i novca.
— Postoje li dostojne alternative plaćenom bez servera od Amazona i Googlea?
Nikolai: U Kubernetesu pokrenete neku vrstu posla, on se pokrene i umire - ovo je prilično bez servera sa arhitektonske tačke gledišta. Ako želite da kreirate zaista zanimljivu poslovnu logiku sa redovima i bazama podataka, onda morate malo više razmisliti o tome. Ovo se sve može riješiti bez napuštanja Kubernetesa. Ne bih se trudio da odugovlačim sa dodatnom implementacijom.
— Koliko je važno pratiti šta se dešava u Serverless-u?
Ara: Zavisi od arhitekture sistema i poslovnih zahtjeva. U suštini, provajder mora da obezbedi izveštaje koji će pomoći devops timu da razume moguće probleme.
Nikolai: Amazon ima CloudWatch, gdje se strimuju svi zapisi, uključujući i one iz Lambde. Integrirajte prosljeđivanje dnevnika i koristite poseban alat za pregled, upozorenje i tako dalje. Možete strpati agente u kontejnere koje pokrenete.
- Hajde da sumiramo.
Andrei: Razmišljanje o Lambda funkcijama je korisno. Ako sami kreirate servis - ne mikroservis, već onaj koji piše zahtjev, pristupa bazi podataka i šalje odgovor - Lambda funkcija rješava brojne probleme: s višenitnošću, skalabilnosti itd. 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š uvijek je otvoreno pitanje.
Nikolaj: Bez servera se bolje koristi za operativne zadatke nego za izračunavanje neke poslovne logike. Uvek o tome razmišljam kao o obradi događaja. Ako ga imate na Amazonu, ako ste u Kubernetesu, da. U suprotnom, morat ćete 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. Sa logičke tačke gledišta, obe opcije su prikladne, ali u smislu implementacije, Serverless je komplikovaniji, a ja više volim jednostavniji način, bez Lambde.
Ara: Serverless je zanimljiva, primjenjiva i tehnički vrlo lijepa ideja. Prije ili kasnije, tehnologija će doći do tačke u kojoj će se bilo koja funkcija pokrenuti za manje od 100 milisekundi. Tada, u principu, neće biti pitanja da li je vrijeme čekanja kritično za korisnika. Istovremeno, primenljivost Serverless-a, kako su kolege već rekli, u potpunosti zavisi od poslovnog problema.
Zahvaljujemo se našim sponzorima koji su nam puno pomogli:
- IT konferencijski prostor «» za stranicu konferencije.
- Kalendar IT događaja i objavljivanje"» za informativnu podršku i vijesti.
- «"za poklone.
- za zajedničko stvaranje.
- "Udruženje za elektronske komunikacije" za učešće i iskustvo.
- Glavni sponzor - za sve!
izvor: www.habr.com