ByteDance monolīts: Dzinējs, kas darbina viedākas, ātrākas satura plūsmas

```html Autori: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Fudan University Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKTS Izveidošana mērogojama un reāllaika ieteikumu sistēma ir būtiska daudziem uzņēmumiem, ko vada laikjutīgi klientu atsauksmes, piemēram, īso video rangu vai tiešsaistes reklāmas. Neskatoties uz plašo ražošanas līmeņa dziļās mācīšanās sistēmu pieņemšanu, piemēram, Ten-sorFlow vai PyTorch, šīs vispārējās sistēmas dažādu iemeslu dēļ nepietiekami atbilst biznesa prasībām ieteikumu scenārijos: no vienas puses, sistēmu pielāgošana, pamatojoties uz statiskiem parametriem un blīviem aprēķiniem ieteikumiem ar dinamiskiem un reti datiem, ir kaitīga modeļa kvalitātei; no otras puses, šādas sistēmas ir izstrādātas ar pilnīgi atdalītu partiju apmācības un apkalpošanas posmu, kas neļauj modelim reāllaikā mijiedarboties ar klientu atsauksmēm. Šīs problēmas lika mums no jauna izvērtēt tradicionālās pieejas un izpētīt radikāli atšķirīgas dizaina izvēles. Šajā rakstā mēs iepazīstinām ar 1, sistēmu, kas paredzēta tiešsaistes apmācībai. Mūsu dizains ir balstīts uz mūsu lietojumprogrammu darba slodžu un ražošanas vides novērojumiem, kas atspoguļo ievērojamu atšķirību no citām ieteikumu sistēmām. Mūsu ieguldījums ir daudzpusīgs: pirmkārt, mēs izveidojām sadursmes nesaturošu iegulšanas tabulu ar optimizācijām, piemēram, izdzēšamām iegulšanām un frekvenču filtrēšanu, lai samazinātu tās atmiņas nospiedumu; otrkārt, mēs nodrošinām ražošanai gatavu tiešsaistes apmācības arhitektūru ar augstu kļūdu toleranci; visbeidzot, mēs pierādījām, ka sistēmas uzticamību var apmainīt pret reāllaika apguvi. Monolith ir veiksmīgi ieviests BytePlus Recommend2 produktā. Monolith 1 IEVADS Pēdējā desmitgadē ir novērots ieteikumu metožu virzītu uzņēmumu uzplaukums. Lai uzlabotu klientu pieredzi, personalizēta satura nodrošināšana katram individuālajam lietotājam kā reāllaika atbilde ir kopīgs mērķis šīm biznesa lietojumprogrammām. Lai to panāktu, informācija no lietotāja jaunākās mijiedarbības bieži tiek izmantota kā galvenais ieguldījums modeļa apmācībai, jo tā vislabāk attēlo lietotāja profilu un paredz lietotāja intereses un turpmāko uzvedību. Dziļā mācīšanās ir dominējusi ieteikumu modeļos [ , , , , , ], jo milzīgs lietotāju datu apjoms ir dabiski piemērots masīvi datu vadītiem neironu modeļiem. Tomēr centieni izmantot dziļās mācīšanās jaudu industriālā līmeņa ieteikumu sistēmās pastāvīgi saskaras ar problēmām, kas rodas no reālās pasaules lietotāju uzvedības datu unikālajām īpašībām. Šie dati divos aspektos ievērojami atšķiras no datiem, kas tiek izmantoti tradicionālajās dziļās mācīšanās problēmās, piemēram, valodu modelēšanā vai datorredzēšanā: 5 6 10 12 20 21 (1) Iezīmes galvenokārt ir reti, kategoriskas un dinamiskas; (2) Treniņu datu pamatā esošā sadalījuma ir nestacionāra, saukta arī par konceptu novirzi [8]. Šādas atšķirības ir radījušas unikālas problēmas pētniekiem un inženieriem, kas strādā pie ieteikumu sistēmām. 1.1 Retums un dinamika Ieteikumu dati galvenokārt satur retas kategoriskas iezīmes, no kurām dažas parādās reti. Izplatītā prakse tās kartēt uz augstas dimensijas iegulšanas telpu radītu virkni problēmu: • Atšķirībā no valodu modeļiem, kur vārdu daļiņu skaits ir ierobežots, lietotāju un rangu elementu skaits ir par vairākām pakāpēm lielāks. Šāda milzīga iegulšanas tabula grūti ietilptu vienā resursdatorā; • Vēl ļaunāk, iegulšanas tabulas lielumam ir paredzēts pieaugt laika gaitā, pievienojot vairāk lietotāju un elementu, savukārt tādas sistēmas kā [ , ] izmanto fiksēta izmēra blīvus mainīgos, lai attēlotu iegulšanas tabulu. 1 17 Praksē daudzas sistēmas izmanto zemu sadursmju jaucējujteksni [ , ] kā veidu, kā samazināt atmiņas nospiedumu un atļaut ID pieaugumu. Tas balstās uz pārāk idealizētu pieņēmumu, ka ID iegulšanas tabulā ir vienmērīgi sadalīti pēc frekvences, un sadursmes ir nekaitīgas modeļa kvalitātei. Diemžēl tas reti notiek reālās pasaules ieteikumu sistēmā, kur neliela grupa lietotāju vai elementu ir ievērojami biežāk. Ar iegulšanas tabulas lieluma organisku pieaugumu palielinās jaucējujteksnes sadursmju iespējas un pasliktinās modeļa kvalitāte 3 6 [3]. Tāpēc ražošanas līmeņa ieteikumu sistēmām ir dabiska prasība spēt uztvert pēc iespējas vairāk iezīmju savos parametros, kā arī spēt elastīgi pielāgot lietotāju un elementu skaitu, ko tās cenšas uzskaitīt. 1.2 Nestacionāra izplatība Vizuālie un lingvistiskie modeļi tik tikko attīstās gadsimtu laikā, savukārt lietotājs, kurš interesējas par vienu tēmu, var mainīt savu entuziasmu ik pēc minūtes. Tā rezultātā lietotāju datu pamatā esošā izplatība ir nestacionāra, parādība, ko parasti dēvē par Konceptu Novirzi [8]. Intuitīvi, informācija no nesenākas vēstures var efektīvāk palīdzēt prognozēt lietotāja uzvedības izmaiņas. Lai mazinātu Konceptu Novirzes ietekmi, apkalpojošiem modeļiem ir jābūt atjauninātiem no jaunām lietotāju atsauksmēm pēc iespējas tuvāk reāllaikam, lai atspoguļotu lietotāja jaunākās intereses. Ņemot vērā šīs atšķirības un novērojot problēmas, kas rodas no mūsu ražošanas, mēs izstrādājām , liela mēroga ieteikumu sistēmu, lai risinātu šīs problēmas. Mēs veicām plašus eksperimentus, lai pārbaudītu un iterētu mūsu dizainu ražošanas vidē. Monolith spēj Monolith (1) Nodrošināt pilnu izteiksmes spēku reti datiem, izstrādājot sadursmes nesaturošu jaucējujteksni un dinamiskas iezīmju izslēgšanas mehānismu; (2) Nodrošināt reāllaika apmācību, atgriežot apkalpošanas atsauksmes uz apmācību. Ar šīm arhitektūras spējām Monolith konsekventi pārsniedz sistēmas, kas izmanto jaucējujteksnes ar sadursmēm, ar aptuveni līdzīgu atmiņas lietojumu, un sasniedz vismodernāko tiešsaistes apkalpošanas AUC, nepārslogojot mūsu serveru aprēķinu jaudu. Atlikusī daļa no raksta ir organizēta šādi. Mēs vispirms izklāstīsim dizaina detaļas par to, kā Monolith risina esošās problēmas ar sadursmes nesaturošu jaucējujteksni un reāllaika apmācību 2. sadaļā. Eksperimenti un rezultāti tiks prezentēti 3. sadaļā, kopā ar ražošanā pārbaudītiem secinājumiem un dažiem apspriedumiem par kompromisiem starp laika jutīgumu, uzticamību un modeļa kvalitāti. 4. sadaļa apkopo saistīto darbu un salīdzina tos ar Monolith. 5. sadaļa noslēdz šo darbu. 2 DIZAINTS Monolith kopējā arhitektūra parasti seko TensorFlow sadalītajai Worker- arameter erver iestatījumam (4. attēls Worker-PS arhitektūrā mašīnām tiek piešķirtas dažādas lomas; Worker mašīnas ir atbildīgas par aprēķinu veikšanu, kā definēts grafā, un PS mašīnas glabā parametrus un atjaunina tos saskaņā ar Workeru aprēķinātajiem gradientiem. P S ). Ieteikumu modeļos parametri tiek iedalīti divās grupās: blīvi un reti. Blīvie parametri ir svari/mainīgie dziļā neironu tīklā, un reti parametri attiecas uz iegulšanas tabulām, kas atbilst retiem iezīmēm. Mūsu dizainā gan blīvie, gan reti parametri ir daļa no TensorFlow grafika un tiek glabāti parametru serveros. Līdzīgi kā TensorFlow mainīgajam blīvajiem parametriem, mēs izstrādājām virkni ļoti efektīvu, sadursmes nesaturošu un elastīgu HashTable operāciju reti parametriem. Kā papildinājums TensorFlow ierobežojumam, kas rodas no apmācības un izvietošanas atdalīšanas, Monolith elastīgi mērogojamā tiešsaistes apmācība ir izstrādāta, lai efektīvi sinhronizētu parametrus no apmācības-PS uz tiešsaistes apkalpošanas-PS īsos intervālos, ar modeļa robustuma garantiju, ko nodrošina kļūdu tolerences mehānisms. 2.1 Jaucējujteksne Pirmais princips mūsu retu parametru attēlojuma dizainā ir izvairīties no informācijas grupēšanas no dažādiem ID vienā fiksēta izmēra iegulšanas. Dinamiska izmēra iegulšanas tabulas simulēšana ar standarta TensorFlow mainīgo neizbēgami noved pie ID sadursmes, kas pasliktinās, ienākot jauniem ID un tabulai pieaugot. Tāpēc, nevis balstoties uz mainīgo, mēs izstrādājām jaunu atslēgu-vērtību HashTable mūsu reti parametriem. Mūsu HashTable izmanto Cuckoo Hashmap [ ] pamatā, kas atbalsta jaunu atslēgu ievietošanu, nesaslēdzoties ar esošajām. Cuckoo Hashing nodrošina 𝑂 (1) laika sarežģītību meklējumiem un dzēšanai sliktākajā gadījumā, un paredzamo amortizēto 𝑂 (1) laiku ievietošanai. Kā parādīts 3. attēlā tā uztur divas tabulas 𝑇0, 𝑇1 ar dažādām jaucējujteksnes funkcijām ℎ0 (𝑥), ℎ1 (𝑥), un elements tiks glabāts vienā no tām. Mēģinot ievietot elementu 16 , 𝐴 𝑇0, tas vispirms mēģina novietot 𝐴 pie ℎ0 (𝐴); Ja ℎ0 (𝐴) ir aizņemts ar citu elementu 𝐵, tas izstumj 𝐵 no 𝑇0 un mēģina ievietot 𝐵 𝑇1 ar tādu pašu loģiku. Šis process tiks atkārtots, līdz visi elementi stabilizēsies, vai notiks pārejaukšana, ja ievietošana nonāks ciklā. Atmiņas nospieduma samazināšana ir arī svarīgs mūsu dizaina apsvērums. Naiva pieeja, ievietojot katru jauno ID HashTable, ātri izsmels atmiņu. Novērojumi par reāliem ražošanas modeļiem noved pie diviem secinājumiem: (1) ID, kas parādās tikai dažas reizes, sniedz ierobežotu ieguldījumu modeļa kvalitātes uzlabošanā. Svarīgs novērojums ir tas, ka ID ir sadalīti garajā astē, kur populārie ID var parādīties miljoniem reižu, kamēr nepopulārie parādās ne vairāk kā desmit reizes. Ieguldījumi, kas atbilst šiem reti sastopamajiem ID, ir nepietiekami apmācīti, jo trūkst apmācības datu, un modelis nevarēs veikt labu novērtējumu, pamatojoties uz tiem. Galu galā šiem ID, kas nav bieži sastopami, visticamāk, neietekmēs rezultātu, tāpēc modeļa kvalitāte necietīs no šo ID ar zemu sastopamības biežumu izņemšanas; (2) Veci ID no tālas vēstures reti sniedz ieguldījumu pašreizējam modelim, jo daudzi no tiem nekad netiek apmeklēti. Tas varētu būt saistīts ar lietotāju, kurš vairs nav aktīvs, vai īsu video, kas ir novecojis. Šo ID ieguldījumu glabāšana nekādi nepalīdzēs modelim, izņemot mūsu PS atmiņas izšķērdēšanu. Pamatojoties uz šiem novērojumiem, mēs izstrādājām vairākas iezīmju ID filtrēšanas heuristikas efektīvākai HashTable ieviešanai: (1) ID tiek filtrēti pirms to pieņemšanas iegulšanas tabulās. Mums ir divas filtrēšanas metodes: Pirmkārt, mēs filtrējam pēc to sastopamības biežuma pirms to ievietošanas kā atslēgām, kur sastopamības slieksnis ir regulējams hiperpārāms, kas atšķiras katram modelim; Papildus mēs izmantojam probabilistisku filtru, kas palīdz vēl vairāk samazināt atmiņas lietojumu; ![#4. attēls: Streaming Engine. Informācijas atgriezeniskā saite no [Lietotājs → Modeļa serveris → Apmācības darbinieks → Modeļa serveris → Lietotājs] pavadītu ilgu laiku, veicot partiju apmācības ceļu, savukārt tiešsaistes apmācība aizvērs ciklu ātrāk.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID tiek laicīgi un iestatīti izbeigties pēc noteikta laika perioda neaktivitātes. Izbeigšanās laiks ir arī regulējams katrai iegulšanas tabulai, lai ļautu atšķirt iezīmes ar atšķirīgu jutīgumu pret vēsturisko informāciju. Mūsu ieviešanā HashTable ir ieviesta kā Tensor-Flow resursu operācija. Līdzīgi kā mainīgajiem, meklējumi un atjauninājumi ir ieviesti kā vietējas TensorFlow operācijas, lai atvieglotu integrāciju un uzlabotu saderību. 2.2 Tiešsaistes apmācība Monolith apmācība ir sadalīta divos posmos (1. attēls ): (1) Partiju apmācības posms. Šis posms darbojas kā parasta Tensor-Flow apmācības cilpa: katrā apmācības solī apmācības darbinieks nolasa vienu mini-partiju apmācības piemēru no krātuves, pieprasa parametrus no PS, veic priekšējo un aizmugurējo pāreju, un visbeidzot nosūta atjauninātos parametrus uz apmācības PS. Nedaudz atšķirīgi no citiem parastajiem dziļās mācīšanās uzdevumiem, mēs apmācām savu datu kopumu tikai vienai pārejai. Partiju apmācība ir noderīga vēsturisko datu apmācībai, kad mēs modificējam mūsu modeļa arhitektūru un atkārtoti apmācām modeli; (2) Tiešsaistes apmācības posms. Pēc modeļa izvietošanas tiešsaistes apkalpošanā apmācība nebeidzas, bet pāriet tiešsaistes apmācības posmā. Tā vietā, lai nolasītu mini-partiju piemērus no krātuves, apmācības darbinieks apstrādā reāllaika datus straumē un atjaunina apmācības PS. Apmācības PS periodiski sinhronizē savus parametrus ar apkalpošanas PS, kas nekavējoties stāsies spēkā lietotāja pusē. Tas ļauj mūsu modelim interaktīvi pielāgoties atbilstoši lietotāja atsauksmēm reāllaikā. Monolith ir veidota ar spēju nemanāmi pārslēgties starp partiju un tiešsaistes apmācību. Tas ir iespējams, pateicoties mūsu straumēšanas dzinēja dizainam, kā parādīts 1. attēlā 2.2.1 Streaming Engine. . Mūsu dizainā mēs izmantojam vienu Kafka [ ] rindu, lai reģistrētu lietotāju darbības (piemēram, klikšķis uz vienuma vai patīk vienumam utt.) un citu Kafka rindu iezīmēm. Dzinēja centrā ir Flink [ ] straumēšanas uzdevums tiešsaistes iezīmju pievienošanai. Tiešsaistes pievienotājs savieno iezīmes ar etiķetēm no lietotāju darbībām un rada apmācības piemērus, kas pēc tam tiek rakstīti Kafka rindā. Apmācības piemēru rindu patērē gan tiešsaistes, gan partiju apmācība: 13 4 Tiešsaistes apmācībai apmācības darbinieks tieši nolasa datus no Kafka rindas; Partiju apmācībai datu izgāšanas uzdevums vispirms izgāzīs datus uz HDFS [ ]; Pēc tam, kad HDFS dati būs sakrājušies noteiktā daudzumā, apmācības darbinieks izgūs datus no HDFS un veiks partiju apmācību. 18 Atjauninātie parametri apmācības PS tiks nosūtīti uz apkalpošanas PS saskaņā ar parametru sinhronizācijas grafiku. Reālās pasaules lietojumprogrammās lietotāju darbību žurnāli un iezīmes tiek straumētas tiešsaistes savienotājā (5. attēls bez garantijas laika secībā. Tāpēc mēs izmantojam unikālu atslēgu katram pieprasījumam, lai lietotāja darbība un iezīmes varētu pareizi savienoties. 2.2.2 Tiešsaistes savienotājs. ) Lietotāja darbības aizkave var būt arī problēma. Piemēram, lietotājs var pavadīt dažas dienas, pirms viņš nolemj iegādāties vienumu, kas viņam tika parādīts pirms dienām. Tas ir izaicinājums savienotājam, jo, ja visas iezīmes tiek turētas kešatmiņā, tās vienkārši neiederas atmiņā. Mūsu sistēmā tiek izmantota uz diska balstīta atslēgu-vērtību krātuve, lai saglabātu iezīmes, kas gaida ilgāku laika periodu. Kad pienāk lietotāja darbības žurnāls, tas vispirms meklē atmiņas kešatmiņā, un pēc tam meklē atslēgu-vērtību krātuvi, ja kešatmiņa trūkst. Vēl viena problēma, kas rodas reālās pasaules lietojumprogrammās, ir tā, ka negatīvo un pozitīvo piemēru sadalījums ir ļoti nevienmērīgs, kur pirmo skaits var būt par vairākām pakāpēm lielāks nekā otrais. Lai neļautu pozitīvajiem piemēriem tikt pārslogotiem ar negatīvajiem, izplatīta stratēģija ir negatīva paraugu ņemšana. Tas noteikti mainīs apmācītā modeļa pamatā esošo sadalījumu, pielāgojot to augstākai pozitīvu prognožu varbūtībai. Kā līdzeklis, mēs izmantojam log-odds korekciju [ ] apkalpošanas laikā, nodrošinot, ka tiešsaistes modelis ir neobjektīvs oriģinālā sadalījuma novērtētājs. 19 Tiešsaistes apmācības laikā Monolith apmācības klasteris turpina saņemt datus no tiešsaistes apkalpošanas moduļa un atjaunina parametrus uz apmācības PS. Būtisks solis, lai tiešsaistes apkalpošanas PS varētu gūt labumu no šiem jaunajiem apmācītajiem parametriem, ir atjaunināto modeļa parametru sinhronizācija. Ražošanas vidē mēs saskaramies ar vairākām problēmām: 2.2.3 Parametru sinhronizācija. Modeļiem tiešsaistes apkalpošanas PS nedrīkst pārtraukt apkalpošanu atjaunināšanas laikā. Mūsu modeļi ražošanā parasti ir vairāki terabaiti, un rezultātā visu parametru nomaiņa prasa laiku. Būtu nepieņemami apturēt tiešsaistes PS no modeļa apkalpošanas atjaunināšanas procesa laikā, un atjauninājumi jāveic straumē; Daudz terabaitu modeļa pilnīgas nodošanas no apmācības PS uz tiešsaistes apkalpošanas PS radītu milzīgu spiedienu gan tīkla joslas platumam, gan PS atmiņai, jo tas prasa dubultu modeļa izmēra atmiņu, lai pieņemtu ienākošo modeli. Lai tiešsaistes apmācība varētu mērogoties līdz mūsu biznesa scenārija izmēram, mēs izstrādājām inkrementālu, straumējošu, periodisku parametru sinhronizācijas mehānismu Monolith, pamatojoties uz vairākām mūsu modeļu ievērojamām īpašībām: (1) Retie parametri dominē ieteikumu modeļu lielumā; (2) Ņemot vērā īsu laika logu, tikai neliela ID apakškopa tiek apmācīta un to ieguldījumi tiek atjaunināti; (3) Blīvie mainīgie pārvietojas daudz lēnāk nekā reti ieguldījumi. Tas ir tāpēc, ka momentum balstītos optimizatoros momentum uzkrāšanos blīvajiem mainīgiem palielina milzīgs ieteikumu apmācības datu apjoms, kamēr vienā datu partijā tiek saņemti tikai daži reti ieguldījumi. (1) un (2) ļauj mums izmantot retās atjauninājumus visos iezīmju ID. Monolith mēs uzturam pieskarto atslēgu jaucējujteksnes kopu, kas attēlo ID, kuru ieguldījumi tika apmācīti kopš pēdējās parametru sinhronizācijas. Mēs nosūtam reto parametru apakškopu, kuru atslēgas ir pieskarto atslēgu kopā ar minūšu līmeņa laika intervālu no apmācības PS uz tiešsaistes apkalpošanas PS. Šis relatīvi mazais inkrementālo parametru atjauninājumu komplekts ir viegls tīkla pārraidei un neizraisīs asas atmiņas pieaugumu sinhronizācijas laikā. Mēs arī izmantojam (3) lai vēl vairāk samazinātu tīkla I/O un atmiņas lietojumu, iestatot agresīvāku sinhronizācijas grafiku reti parametriem, vienlaikus retāk atjauninot blīvos parametrus. Tas var radīt situāciju, kurā apkalpotie blīvie parametri ir salīdzinoši veca versija salīdzinājumā ar reto daļu. Tomēr šāda neatbilstība varētu tikt pieņemta, ņemot vērā iepriekš minēto (3) iemeslu, jo nav novērota acīmredzama zuduma. 2.3 Kļūdu tolerance Kā ražošanas sistēma Monolith ir izstrādāta ar spēju atjaunot PS, ja tā sabrūk. Izplatīta izvēle kļūdu tolerancei ir periodiski uzņemt modeļa stāvokļa momentuzņēmumu un atjaunoties no jaunākā momentuzņēmuma, kad tiek konstatēta PS kļūme. Momentuzņēmuma frekvences izvēlei ir divas galvenās ietekmes: (1) Modeļa kvalitāte. Intuitīvi, modeļa kvalitāte mazāk cieš no nesenās vēstures zuduma ar palielinātu momentuzņēmuma frekvenci. (2) Aprēķinu izmaksas. Daudzu terabaitu modeļa momentuzņēmuma uzņemšana nav bezmaksas. Tas rada lielas atmiņas kopijas un diska I/O. Kā kompromiss starp modeļa kvalitāti un aprēķinu izmaksām, Monolith katru dienu uzņem momentuzņēmumu visiem apmācības PS. Lai gan PS zaudēs vienas dienas atjauninājumu kļūmes gadījumā, mēs eksperimentu gaitā atklājām, ka veiktspējas degradācija ir pieņemama. Mēs analizēsim PS uzticamības ietekmi nākamajā sadaļā. 3 NOVĒRTĒJUMS Lai labāk izprastu mūsu piedāvātā dizaina sniegtās priekšrocības un kompromisus, mēs veicām vairākus eksperimentus ražošanas mērogā un A/B testus ar tiešraides apkalpošanas datplūsmu, lai novērtētu un pārbaudītu Monolith dažādos aspektos. Mēs cenšamies atbildēt uz šādiem jautājumiem ar mūsu eksperimentiem