Inside ByteDance’s Monolith: Dzinis, 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 Meklējamas ieteikumu sistēmas izveide ir būtiska daudziem uzņēmumiem, kas balstīti uz laika ziņā jutīgu klientu atsauksmēm, piemēram, īso video rangu vai tiešsaistes reklāmu. Neskatoties uz visuresošo ražošanas mēroga dziļās mācīšanās sistēmu, piemēram, Ten-sorFlow vai PyTorch, izmantošanu, šīs vispārējās sistēmas dažādu iemeslu dēļ neatbilst uzņēmējdarbības prasībām ieteikumu scenārijos: no vienas puses, sistēmu pielāgošana, pamatojoties uz statiskiem parametriem un blīvām aprēķinām, lai ieteiktu dinamiskas un retas iezīmes, 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 atkārtoti izvērtēt tradicionālās pieejas un izpētīt radikāli atšķirīgas dizaina izvēles. Šajā darbā mēs iepazīstinām ar 1, sistēmu, kas pielāgota 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 daudzveidīgs: pirmkārt, mēs izveidojām sadursmes neizraisošu iegulšanas tabulu ar optimizācijām, piemēram, izdzēšamiem ieguldījumiem un biežuma filtrēšanu, lai samazinātu tās atmiņas nospiedumu; otrkārt, m 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 Pagājušajā desmitgadē tika novērots uz ieteikumu tehnikām balstītu uzņēmumu uzplaukums. Lai uzlabotu klientu pieredzi, bieži vien ir kopīgs mērķis nodrošināt personalizētu saturu katram individuālajam lietotājam, reaģējot reāllaikā. Šim nolūkam informācija no lietotāja jaunākās mijiedarbības bieži tiek izmantota kā galvenā ievade modeļa apmācībai, jo tā vislabāk attēlo lietotāja portretu un prognozē lietotāja intereses un nākotnes 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 unikālajām reālās pasaules lietotāju uzvedības datu īpašībām. Šie dati divos aspektos krasi atšķiras no datiem, kas tiek izmantoti tradicionālajos dziļās mācīšanās uzdevumos, piemēram, valodu modelēšanā vai datorredzēšanā: 5 6 10 12 20 21 (1) Iezīmes galvenokārt ir retas, kategoriskas un dinamiskas; (2) Treniņu datu pamatā esošais sadalījums ir nestacionārs, pazīstams arī kā koncepta novirze [8]. Šādas atšķirības ir radījušas unikālus izaicinājumus ieteikumu sistēmu pētniekiem un inženieriem. 1.1 Retums un dinamika Ieteikumu dati galvenokārt satur retas kategoriskās iezīmes, no kurām dažas parādās ar zemu biežumu. Parastā prakse, tās kartējot uz augstas dimensijas iegulšanas telpu, rada virkni problēmu: • Atšķirībā no valodu modeļiem, kur vārdu daļiņu skaits ir ierobežots, lietotāju un rangu vienumu skaits ir par vairākām pakāpēm lielāks. Šāda milzīga iegulšanas tabula gandrīz neiederas vienā saimniekdatorā; • Vēl sliktāk, iegulšanas tabulas izmērs laika gaitā pieaugs, pievienojoties vairāk lietotāju un vienumu, savukārt sistēmas, piemēram, [ , ], 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ēju [ , ] kā veidu, kā samazināt atmiņas nospiedumu un atļaut ID pieaugumu. Tas balstās uz pārmērīgi idealistisku pieņēmumu, ka ID iegulšanas tabulā ir vienmērīgi sadalīti pēc biežuma un sadursmes nav kaitīgas modeļa kvalitātei. Diemžēl tas reti notiek reālās pasaules ieteikumu sistēmā, kur neliela lietotāju vai vienumu grupa ir ievērojami biežāk sastopama. Palielinoties iegulšanas tabulas izmēram, palielinās jaucēju atslēgu sadursmju iespējas un pasliktinās modeļa kvalitāte 3 6 [3]. Tāpēc ražošanas mēroga ieteikumu sistēmām ir dabiska vajadzī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 vienumu skaitu, ko tās cenšas uzskaitīt. 1.2 Nestacionāra izplatība Vizuālie un lingvistiskie modeļi attīstās ļoti lēni gadsimtu laikā, savukārt lietotājs, kas 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 sauc par koncepta 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 koncepta novirzes ietekmi, apkalpošanas modeļiem jābūt atjauninātiem ar 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 mūsu ražošanas problēmas, mēs izstrādājām , liela mēroga ieteikumu sistēmu, lai novērstu šīs problēmas. Mēs veicām plašus eksperimentus, lai pārbaudītu un atkārtotu savu dizainu ražošanas vidē. Monolith spēj Monolith (1) Nodrošināt pilnu izteiksmes spēku retām iezīmēm, izstrādājot sadursmes neizraisošu jaucēju tabulu un dinamisku iezīmju izslēgšanas mehānismu; (2) Cikla apkalpošanas atsauksmes atpakaļ uz apmācību reāllaikā ar tiešsaistes apmācību. Šīs arhitektūras iespējas ļauj Monolith konsekventi pārspēt sistēmas, kas izmanto jaucēju trikus ar sadursmēm, ar aptuveni līdzīgu atmiņas izmantošanu, un sasniedz vismodernāko tiešsaistes apkalpošanas AUC, nepārslogojot mūsu serveru aprēķina jaudu. Pārējā daļa šajā darbā ir organizēta šādi. Mēs vispirms detalizēti aprakstām dizaina detaļas par to, kā Monolith risina esošās problēmas ar sadursmes neizraisošu jaucēju tabulu un reāllaika apmācību 2. nodaļā. Eksperimenti un rezultāti tiks prezentēti 3. nodaļā, kopā ar ražošanā pārbaudītiem secinājumiem un dažām diskusijām par kompromisiem starp laika jutīgumu, uzticamību un modeļa kvalitāti. 4. nodaļā apkopots saistītais darbs un salīdzināts ar Monolith. 5. nodaļā tiek apkopots šis darbs. 2 DIZAINS Monolith kopējā arhitektūra parasti seko TensorFlow sadalītajai Worker- arameter erver iestatījumam (2. attēls). Darbinieka-PS arhitektūrā mašīnām tiek piešķirtas dažādas lomas; Worker mašīnas ir atbildīgas par aprēķinu veikšanu, ko definē grafiks, un PS mašīnas glabā parametrus un atjaunina tos atbilstoši 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 dziļā neironu tīkla svari/mainīgie, bet retie parametri attiecas uz iegulšanas tabulām, kas atbilst reti sastopamām iezīmēm. Mūsu dizainā gan blīvie, gan retie 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 neizraisošu un elastīgu HashTable operāciju reti sastopamiem parametriem. Kā papildinājums TensorFlow ierobežojumiem, kas rodas no apmācības un secināšanas atdalīšanas, Monolith elastīgi mērogojama tiešsaistes apmācība ir paredzēta efektīvai parametru sinhronizācijai no apmācības-PS uz tiešsaistes apkalpošanas-PS īsos intervālos, ar modeļa robustuma garantiju, ko nodrošina kļūdu panesamības mehānisms. 2.1 Jaucēju tabula Pirmais princips mūsu retās parametru reprezentācijas dizainā ir izvairīties no informācijas no dažādiem ID apkopošanas vienā fiksēta izmēra ieguldījumā. Dinamiska izmēra iegulšanas tabulas simulēšana ar gatavu 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 sastopamiem parametriem. Mūsu HashTable pamatā izmanto Cuckoo Hashmap [ ], kas atbalsta jaunu atslēgu ievietošanu, nesaduroties ar esošajām. Cuckoo Hashing nodrošina 𝑂 (1) laika sarežģītību meklējumiem un dzēšanai sliktākajā gadījumā, un paredzamu amortizētu 𝑂 (1) laiku ievietošanai. Kā parādīts 3. attēlā, tas uztur divas tabulas 𝑇0, 𝑇1 ar dažādām jaucēju funkcijām ℎ0 (𝑥), ℎ1 (𝑥), un elements tiktu saglabāts vienā no tām. Mēģinot ievietot elementu 16 𝐴 tabulā 𝑇0, tas vispirms mēģina ievietot 𝐴 pie ℎ0 (𝐴); Ja ℎ0 (𝐴) ir aizņemts ar citu elementu 𝐵, tas izstumj 𝐵 no 𝑇0 un mēģina ievietot 𝐵 tabulā 𝑇1 ar tādu pašu loģiku. Šis process tiks atkārtots, līdz visi elementi stabilizēsies, vai notiks pārmērīgs jaucējs, kad ievietošana nonāk ciklā. Atmiņas nospieduma samazināšana ir arī svarīgs apsvērums mūsu dizainā. Vienkārša pieeja, katru jauno ID ievietojot HashTable, ātri iztērēs 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, maz ietekmē modeļa kvalitātes uzlabošanu. Svarīgs novērojums ir tas, ka ID tiek sadalīti garā astē, kur populāri 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 sastopamiem ID, ir nepietiekami apmācīti, trūkstot apmācības datiem, un modelis nevarēs sniegt labu novērtējumu, pamatojoties uz tiem. Galu galā šiem ID nav iespējams ietekmēt rezultātu, tāpēc modeļa kvalitāte nemazināsies, noņemot šos ID ar zemām sastopamības reizēm; (2) Novecojuši ID no tālā pagātnes reti sniedz ieguldījumu pašreizējam modelim, jo daudzi no tiem 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 modelim, izņemot PS atmiņas izšķērdēšanu. Pamatojoties uz šiem novērojumiem, mēs izstrādājām vairākus iezīmju ID filtrēšanas heuristikas, lai efektīvāk izmantotu atmiņu HashTable implementācijā: (1) ID tiek filtrēti pirms to pievienošanas iegulšanas tabulām. Mums ir divas filtrēšanas metodes: vispirms mēs filtrējam pēc to sastopamības pirms to pievienošanas kā atslēgām, kur sastopamības slieksnis ir regulējams hipetrapametrs, kas atšķiras katram modelim; Turklāt mēs izmantojam probabilistisku filtru, kas palīdz vēl vairāk samazināt atmiņas lietojumu; ![#Figure 4: Streaming Engine. Informācijas atsauces cilpa no [Lietotājs → Modeļa serveris → Apmācības darbinieks → Modeļa serveris → Lietotājs] aizņem ilgu laiku, izmantojot partiju apmācības ceļu, savukārt tiešsaistes apmācība noslēdz cilpu ātrāk.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID tiek laika zīmogoti un iestatīti izbeigties pēc iepriekš noteikta laika perioda bezdarbības. 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 implementācijā HashTable tiek ieviesta kā TensorFlow resursu operācija. Līdzīgi kā mainīgajam, meklēšanas un atjaunināšanas operācijas ir ieviestas kā vietējās TensorFlow operācijas, lai atvieglotu integrāciju un uzlabotu saderību. 2.2 Tiešsaistes apmācība Monolith apmācība tiek sadalīta divos posmos (1. attēls): (1) Partiju apmācības posms. Šis posms darbojas kā parasta TensorFlow 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 atpakaļejošu pāreju un visbeidzot nosūta atjauninātos parametrus uz apmācības PS. Nedaudz atšķirībā no citiem parastajiem dziļās mācīšanās uzdevumiem, mēs apmācām savu datu kopu tikai vienā reizē. Partiju apmācība ir noderīga vēsturisko datu apmācībai, kad mēs mainām savu 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 neapstājas, bet pāriet tiešsaistes apmācības posmā. Tā vietā, lai lasītu mini-partijas piemērus no krātuves, apmācības darbinieks patērē reāllaika datus lidojumā 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 reāllaikā interaktīvi pielāgoties lietotāja atsauksmēm. Monolith ir izveidots ar spēju nevainojami pārslēgties starp partiju apmācību un tiešsaistes apmācību. To nodrošina mūsu straumēšanas dzinēja dizains, kā parādīts 1. attēlā. 2.2.1 Straumēšanas dzinējs. Mūsu dizainā mēs izmantojam vienu Kafka [ ] rindu, lai reģistrētu lietotāju darbības (piemēram, noklikšķiniet uz vienuma vai patīk vienumam utt.) un citu Kafka rindu iezīmēm. Dzinēja kodols ir Flink [ ] straumēšanas uzdevums tiešsaistes iezīmju savienotājam. Tiešsaistes savienotājs apvieno 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ā. Apvienojuma piemēru rindu patērē gan tiešsaistes apmācība, 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 nolaišanas uzdevums vispirms nolaidīs datus uz HDFS [ ]; Pēc tam, kad HDFS dati uzkrāsies noteiktā daudzumā, apmācības darbinieks nolasī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 laika secības garantijas. 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. Arī lietotāja darbības kavēšanās var būt problēma. Piemēram, lietotājs var pavadīt dažas dienas, pirms viņš izlemj iegādāties preci, kas viņam tika piedāvāta pirms dienām. Tas ir izaicinājums savienotājam, jo, ja visas iezīmes tiktu 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 glabātu iezīmes, kas gaida noteiktu laika periodu. Kad ienā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āda, ka negatīvo un pozitīvo piemēru sadalījums ir ļoti nevienmērīgs, kur pirmo skaits var būt daudzas reizes lielāks nekā pēdējo. Lai novērstu pozitīvo piemēru pārplūšanu ar negatīviem, parasta stratēģija ir veikt negatīvu paraugu ņemšanu. Tas noteikti mainīs apmācītā modeļa pamatā esošo sadalījumu, pielāgojot to uz augstāku pozitīvu prognožu varbūtību. Kā līdzekli mēs izmantojam log-odds korekciju [ ] apkalpošanas laikā, nodrošinot, ka tiešsaistes modelis ir neitrāls sākotnējās 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 apmācības PS. Būtisks solis, lai apkalpošanas PS varētu gūt labumu no šiem jauniegūtajiem parametriem, ir atjaunināto modeļa parametru sinhronizācija. Ražošanas vidē mēs saskaramies ar vairākiem izaicinājumiem: 2.2.3 Parametru sinhronizācija. Modeļiem apkalpošanas PS jāstrādā bez pārtraukuma atjaunināšanas laikā. Mūsu modeļi ražošanā parasti ir vairāku terabaitu izmērā, un rezultātā visu parametru nomaiņa aizņem laiku. Būtu nepieļaujami apturēt tiešsaistes PS modeļa apkalpošanu atjaunināšanas laikā, un atjauninājumi jāveic lidojumā; Daudzu terabaitu modeļa pārsūtīšana no apmācības PS uz tiešsaistes apkalpošanas PS radītu milzīgu spiedienu gan uz tīkla joslas platumu, gan uz PS atmiņu, jo tas prasa dubultu modeļa izmēru, lai pieņemtu ienākošo modeli. Lai tiešsaistes apmācība varētu mērogoties mūsu uzņēmējdarbības scenārija izmēram, mēs Monolith izstrādājām pakāpenisku, lidojuma laika, periodisku parametru sinhronizācijas mehānismu, pamatojoties uz vairākām mūsu modeļu raksturīgām iezīmēm: (1) Retie parametri dominē ieteikumu modeļu izmērā; (2) Ņemot vērā īsu laika logu, tikai neliela daļa ID tiek apmācīta un to ieguldījumi tiek atjaunināti; (3) Blīvie mainīgie pārvietojas daudz lēnāk nekā retie ieguldījumi. Tas ir tāpēc, ka momentuma balstītos optimizētājos momentuma uzkrāšanos blīvajiem mainīgajiem pastiprina milzīgs ieteikumu apmācības datu apjoms, savukārt vienā datu partijā tiek atjaunināti tikai daži retie ieguldījumi. (1) un (2) ļauj mums izmantot retās atjaunināšanas visās iezīmju ID. Monolith mēs uzturam pieskarto atslēgu jaucēju 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ūtes līmeņa laika intervālu no apmācības PS uz tiešsaistes apkalpošanas PS. Šī salīdzinoši nelielā pakete ar pakāpenisku parametru atjaunināšanu ir viegla tīkla pārraidei un neradīs strauju 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 retajiem parametriem, savukārt blīvos parametrus atjauninot retāk. Tas var radīt situāciju, kurā apkalpotie blīvie parametri ir salīdzinoši novecojuša versija salīdzinumā ar reto daļu. Tomēr šāda neatbilstība ir pieņemama, jo, kā minēts (3), nav novērota acīmredzama zuduma. 2.3 Kļūdu panesamība Kā ražošanas sistēma Monolith ir izstrādāta ar spēju atgūt PS, ja tā neizdodas. Parasta kļūdu panesamības izvēle ir periodiski uzņemt modeļa stāvokli un atjaunot no jaunākā momenta, ja tiek konstatēta PS kļūda. Momenta uzņemšanas biežuma 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, palielinot momenta uzņemšanas biežumu. (2) Aprēķina pārslodze. Daudzu terabaitu modeļa momenta uzņemšana nav bez maksas. Tā rada lielas atmiņas kopēšanas un diska I/O. Kā kompromiss starp modeļa kvalitāti un aprēķina pārslodzi, Monolith katru dienu uzņem visus apmācības PS. Lai gan PS zaudēs vienas dienas atjauninājumus PS kļūmes gadījumā, mēs eksperimentos atklājām, ka veiktspējas pasliktināšanās 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 testu ar tiešraides apkalpošanas datplūsmu, lai novērtētu un pārbaudītu Monolith dažādos aspektos. Ar mūsu eksperimentiem mēs cenšamies atbildēt uz šādiem jautājumiem: (1) Cik daudz mēs varam gūt labumu no sadursmes neizraisošas HashTable? (2) Cik svarīga ir reāllaika tiešsaistes apmā