Inde i ByteDances Monolit: Motoren der driver smartere, hurtigere indholdsstrømme

Forfattere: 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) RESUMÉ Opbygning af et skalerbart og real-time anbefalingssystem er afgørende for mange virksomheder drevet af tidssensitive kundeanmeldelser, såsom rangering af kortvideoer eller onlineannoncer. På trods af den allestedsnærværende adoption af produktionsskala deep learning-frameworks som Ten-sorFlow eller PyTorch, lever disse generelle frameworks ikke op til forretningskravene i anbefalingsscenarier af forskellige årsager: på den ene side er justering af systemer baseret på statiske parametre og tætte beregninger til anbefaling med dynamiske og sparsomme funktioner skadeligt for modelkvaliteten; på den anden side er sådanne frameworks designet med batchtræningsfasen og servingfasen fuldstændig adskilt, hvilket forhindrer modellen i at interagere med kundeanmeldelser i realtid. Disse problemer førte os til at genoverveje traditionelle tilgange og udforske radikalt anderledes designvalg. I denne artikel præsenterer vi 1, et system skræddersyet til onlinetræning. Vores design er drevet af observationer af vores applikationsarbejdsbelastninger og produktionsmiljø, der afspejler en markant afvigelse fra andre anbefalingssystemer. Vores bidrag er mangefacetterede: for det første har vi skabt en kollisionsfri embedding-tabel med optimeringer såsom udløbende embeddings og frekvensfiltrering for at reducere dens hukommelsesfodaftryk; for det andet leverer vi en produktionsklar onlinetræningsarkitektur med høj fejltolerance; endelig har vi bevist, at systemets pålidelighed kan handles for realtidslæring. Monolith er med succes blevet implementeret i BytePlus Recommend2-produktet. Monolith 1 INTRODUKTION Det seneste årti har været vidne til en eksplosion af forretninger drevet af anbefalingsteknikker. I jagten på en bedre kundeoplevelse er levering af personligt indhold til hver enkelt bruger som realtidssvar et fælles mål for disse forretningsapplikationer. Til dette formål bruges information fra en brugers seneste interaktion ofte som primær input til træning af en model, da den bedst afspejler en brugers portræt og forudsiger brugerens interesse og fremtidige adfærd. Deep learning har domineret anbefalingsmodeller [ , , , , , ], da den gigantiske mængde brugerdata passer naturligt til massivt datadrevne neurale modeller. Bestræbelser på at udnytte deep learnings kraft i anbefalingssystemer på industrielt niveau støder dog konstant på problemer, der opstår fra de unikke karakteristika ved data afledt af reel brugeradfærd. Disse data adskiller sig drastisk fra dem, der bruges i konventionelle deep learning-problemer som sprogmodellering eller computervision på to måder: 5 6 10 12 20 21 (1) Funktionerne er for det meste sparsomme, kategoriske og dynamisk skiftende; (2) > Den underliggende fordeling af træningsdata er ikke-stationær, også kendt som konceptdrift . Sådanne forskelle har udgjort unikke udfordringer for forskere og ingeniører, der arbejder med anbefalingssystemer. 1.1 Sparsomhed og dynamik Data til anbefalinger indeholder for det meste sparsomme kategoriske træk, hvoraf nogle forekommer med lav frekvens. Den almindelige praksis med at mappe dem til et højdimensionelt embedding-rum ville give anledning til en række problemer: • I modsætning til sprogmodeller, hvor antallet af orddele er begrænset, er antallet af brugere og rangerede emner mange størrelsesordener større. En så enorm embedding-tabel kan knap nok passe ind i hukommelsen på en enkelt vært; • > Endnu værre er det forventet, at størrelsen på embedding-tabellen vil vokse over tid, efterhånden som flere brugere og emner tilføjes, mens frameworks som [ , ] bruger faste tætte variabler til at repræsentere embedding-tabellen. 1 17 I praksis anvender mange systemer hashing med lav kollision [ , ] som en måde at reducere hukommelsesforbruget og tillade ID-vækst. Dette hviler på en overidealistisk antagelse om, at ID'erne i embedding-tabellen er jævnt fordelt i frekvens, og at kollisioner er uskadelige for modelkvaliteten. Desværre er dette sjældent sandt for et anbefalingssystem i den virkelige verden, hvor en lille gruppe af brugere eller emner har markant flere forekomster. Med den organiske vækst af embedding-tabellens størrelse øges chancerne for hash-kollision og fører til forringelse af modelkvaliteten 3 6 . Derfor er det en naturlig efterspørgsel for anbefalingssystemer i produktionsskala at have kapaciteten til at indfange så mange træk som muligt i sine parametre, og desuden have evnen til elastisk at justere antallet af brugere og emner, det forsøger at holde styr på. 1.2 Ikke-stationær fordeling Visuelle og sproglige mønstre udvikler sig knap nok på en tidsskala af århundreder, mens den samme bruger, der er interesseret i et emne, kan skifte sin iver hvert næste minut. Som følge heraf er den underliggende fordeling af brugerdata ikke-stationær, et fænomen, der almindeligvis henvises til som konceptdrift . Intuitivt kan information fra en mere nylig historie bidrage mere effektivt til at forudsige ændringen i en brugers adfærd. For at afbøde effekten af konceptdrift skal serving-modeller opdateres fra ny kundeanmeldelse så tæt på realtid som muligt for at afspejle brugerens seneste interesse. I lyset af disse forskelle og i observation af problemer, der opstår fra vores produktion, designede vi , et storskalarekommanderingssystem til at adressere disse smertepunkter. Vi udførte omfattende eksperimenter for at verificere og iterere vores design i produktionsmiljøet. Monolith er i stand til: Monolith (1) > At give fuld udtrykskraft for sparsomme træk ved at designe en kollisionsfri hashtabel og en dynamisk mekanisme til fjernelse af træk; (2) > At loop'e serving-anmeldelser tilbage til træning i realtid med onlinetræning. Med disse arkitektoniske kapaciteter overgår Monolith konsekvent systemer, der anvender hash-tricks med kollisioner, med omtrent lignende hukommelsesforbrug og opnår state-of-the-art online serving AUC uden overdrevent at belaste vores serveres beregningskraft. Resten af artiklen er organiseret som følger. Vi uddyber først design detaljer om, hvordan Monolith tackler eksisterende udfordringer med kollisionsfri hashtabel og realtids træning i afsnit 2. Eksperimenter og resultater vil blive præsenteret i afsnit 3, sammen med produktions-testede konklusioner og en diskussion af kompromiser mellem tidssensitivitet, pålidelighed og modelkvalitet. Afsnit 4 opsummerer relateret arbejde og sammenligner dem med Monolith. Afsnit 5 konkluderer dette arbejde. 2 DESIGN Monoliths overordnede arkitektur følger generelt TensorFlows distribuerede Worker- arameter erver-opsætning (Figur I en Worker-PS arkitektur tildeles maskiner forskellige roller; Worker-maskiner er ansvarlige for at udføre beregninger som defineret af grafen, og PS-maskiner lagrer parametre og opdaterer dem i henhold til gradienter beregnet af Workers. P S 2). I anbefalingsmodeller kategoriseres parametre i to sæt: tætte og sparsomme. Tætte parametre er vægte/variable i et dybt neuralt netværk, og sparsomme parametre refererer til embedding-tabeller, der svarer til sparsomme træk. I vores design er både tætte og sparsomme parametre en del af TensorFlow Graph og gemmes på parameter servere. Ligesom TensorFlows Variabel til tætte parametre har vi designet et sæt højeffektive, kollisionsfri og fleksible HashTable-operationer til sparsomme parametre. Som et supplement til Tensor-Flows begrænsning, der opstår fra separationen af træning og inferens, er Monoliths elastisk skalerbare onlinetræning designet til effektivt at synkronisere parametre fra træning-PS til online serving-PS inden for korte intervaller, med modelrobusthedsgaranti leveret af fejltolerance-mekanismen. 2.1 Hashtabel Et grundlæggende princip i vores design af sparsom parameterrepræsentation er at undgå at proppe information fra forskellige ID'er ind i den samme faste embedding. Simulering af en dynamisk størrelse embedding-tabel med en out-of-the-box TensorFlow Variabel fører uundgåeligt til ID-kollision, som forværres, efterhånden som nye ID'er ankommer og tabellen vokser. Derfor har vi, i stedet for at bygge videre på Variabel, udviklet en ny nøgle-værdi HashTable til vores sparsomme parametre. Vores HashTable bruger Cuckoo Hashmap [ ] internt, som understøtter indsættelse af nye nøgler uden at kollidere med eksisterende. Cuckoo Hashing opnår worst-case 𝑂 (1) tidskompleksitet for opslag og sletninger, og en forventet amortiseret 𝑂 (1) tid for indsættelser. Som illustreret i Figur opretholder den to tabeller 𝑇0, 𝑇1 med forskellige hashfunktioner ℎ0 (𝑥), ℎ1 (𝑥), og et element vil blive gemt i en af dem. Ved forsøg på at indsætte et element 16 3 𝐴 i 𝑇0, forsøger den først at placere 𝐴 ved ℎ0 (𝐴); Hvis ℎ0 (𝐴) er optaget af et andet element 𝐵, vil den fjerne 𝐵 fra 𝑇0 og forsøge at indsætte 𝐵 i 𝑇1 med samme logik. Denne proces vil blive gentaget, indtil alle elementer stabiliserer sig, eller en rehash finder sted, når indsættelsen løber ind i en cyklus. Reduktion af hukommelsesforbruget er også en vigtig overvejelse i vores design. En naiv tilgang til at indsætte hvert nyt ID i HashTable vil hurtigt tømme hukommelsen. Observation af reelle produktionsmodeller fører til to konklusioner: (1) > ID'er, der forekommer kun et par gange, har begrænset bidrag til at forbedre modelkvaliteten. En vigtig observation er, at ID'er er langhalefordelte, hvor populære ID'er kan forekomme millioner af gange, mens de upopulære forekommer højst ti gange. Embeddings, der svarer til disse sjældne ID'er, er underfittet på grund af manglende træningsdata, og modellen vil ikke være i stand til at lave en god estimering baseret på dem. I sidste ende er det usandsynligt, at disse ID'er vil påvirke resultatet, så modelkvaliteten vil ikke lide under fjernelse af disse ID'er med lave forekomster; (2) > Forældede ID'er fra en fjern fortid bidrager sjældent til den aktuelle model, da mange af dem aldrig besøges. Dette kan skyldes en bruger, der ikke længere er aktiv, eller en kortvideo, der er forældet. Lagring af embeddings for disse ID'er kan ikke hjælpe modellen på nogen måde, bortset fra at tømme vores PS-hukommelse forgæves. Baseret på disse observationer designede vi flere heuristikker til filtrering af træk-ID'er for en mere hukommelseseffektiv implementering af HashTable: (1) > ID'er filtreres, før de optages i embedding-tabeller. Vi har to filtreringsmetoder: Først filtrerer vi efter deres forekomster, før de indsættes som nøgler, hvor tærsklen for forekomster er en justerbar hyperparameter, der varierer for hver model; Derudover bruger vi et probabilistisk filter, der hjælper med yderligere at reducere hukommelsesforbruget; ![#Figur 4: Streaming Engine. Informationsfeedback-loopet fra [Bruger → Model Server → Træningsarbejder → Model Server → Bruger] ville tage lang tid, når man fulgte Batch Training-stien, mens Onlinetræning lukker loop'et mere øjeblikkeligt.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) > ID'er tidsstemples og sættes til at udløbe efter at have været inaktive i en foruddefineret periode. Udløbstiden kan også justeres for hver embedding-tabel for at muliggøre skelnen mellem træk med forskellig følsomhed over for historisk information. I vores implementering implementeres HashTable som en Tensor-Flow ressourceoperation. Ligesom Variabel implementeres opslag og opdateringer også som native TensorFlow-operationer for nemmere integration og bedre kompatibilitet. 2.2 Onlinetræning I Monolith er træning opdelt i to faser (Figur 1): (1) > Batch træningsfase. Denne fase fungerer som en almindelig TensorFlow træningsloop: I hvert træningstrin læser en træningsarbejder en mini-batch af træningseksempler fra lageret, anmoder om parametre fra PS, beregner et fremadgående og et bagudgående pass, og skubber endelig opdaterede parametre til træning-PS. Lidt anderledes end andre almindelige deep learning-opgaver, træner vi kun vores datasæt for et enkelt pass. Batchtræning er nyttig til træning af historiske data, når vi ændrer vores modelarkitektur og gen træner modellen; (2) > Online træningsfase. Efter at en model er implementeret til online serving, stopper træningen ikke, men går ind i onlinetræningsfasen. I stedet for at læse mini-batch eksempler fra lageret, forbruger en træningsarbejder realtidsdata on-the-fly og opdaterer træning-PS. Træning-PS synkroniserer periodisk sine parametre til serving-PS, hvilket vil træde i kraft på brugersiden med det samme. Dette gør det muligt for vores model at tilpasse sig interaktivt efter en brugers feedback i realtid. Monolith er bygget med evnen til problemfrit at skifte mellem batchtræning og onlinetræning. Dette muliggøres af vores design af streaming-motoren som illustreret i Figur 2.2.1 Streaming Engine. 4. I vores design bruger vi en Kafka [ ] kø til at logge brugerhandlinger (f.eks. Klik på et element eller like et element osv.) og en anden Kafka kø til funktioner. Kernen i motoren er et Flink [ ] streamingjob for online feature Joiner. Online joiner'en sammenkæder funktioner med etiketter fra brugerhandlinger og producerer træningseksempler, som derefter skrives til en Kafka kø. Køen for træningseksempler forbruges af både onlinetræning og batchtræning: 13 4 For onlinetræning læser træningsarbejderen direkte data fra Kafka-køen; For batchtræning vil et data dump job først dumpe data til HDFS [ ]; Efter at data i HDFS er akkumuleret til et vist niveau, vil træningsarbejderen hente data fra HDFS og udføre batchtræning. 18 Opdaterede parametre i træning-PS vil blive skubbet til serving-PS i henhold til parameter synkroniseringsplanen. I virkelige applikationer strømmer brugerhandlingslogfiler og funktioner ind i online joiner'en (Figur uden garanti for tidsrækkefølge. Derfor bruger vi en unik nøgle for hver anmodning, så brugerhandlingen og funktionerne kan parres korrekt. 2.2.2 Online Joiner. 5) Forsinkelsen af brugerhandlinger kan også være et problem. For eksempel kan en bruger tage et par dage, før de beslutter sig for at købe et element, de blev præsenteret for dage siden. Dette er en udfordring for joiner'en, fordi hvis alle funktioner holdes i cache, passer de simpelthen ikke ind i hukommelsen. I vores system bruges en on-disk nøgle-værdi lager til at gemme funktioner, der venter i over en vis tidsperiode. Når en brugerhandlingslogfil ankommer, ser den først i hukommelsescachen og derefter i nøgle-værdi lageret i tilfælde af en manglende cache. Et andet problem, der opstår i virkelige applikationer, er, at fordelingen af negative og positive eksempler er meget ujævn, hvor antallet af de tidligere kan være mange størrelsesordener højere end de sidstnævnte. For at forhindre positive eksempler i at blive overvældet af negative, er en almindelig strategi at lave negativ sampling. Dette vil helt sikkert ændre den underliggende fordeling af den trænede model og finjustere den mod en højere sandsynlighed for at lave positive forudsigelser. Som en afhjælpning anvender vi log odds-korrektion [ ] under serving, hvilket sikrer, at online-modellen er en upartisk estimator af den oprindelige fordeling. 19 Under onlinetræning modtager Monolith træningsklyngen kontinuerligt data fra online serving-modulet og opdaterer parametre på trænings-PS. Et afgørende trin for at gøre online serving-PS i stand til at drage fordel af disse nytrænede parametre er synkroniseringen af opdaterede modelparametre. I produktionsmiljøet står vi over for flere udfordringer: 2.2.3 Parameter Synkronisering. Modeller på online serving-PS må ikke stoppe med at serve under opdatering. Vores modeller i produktion er normalt flere terabytes i størrelse, og som følge heraf tager det et stykke tid at erstatte alle parametre. Det ville være utåleligt at stoppe en online PS fra at serve modellen under udskiftningsprocessen, og opdateringer skal foretages on-the-fly; Overførsel af en multi-terabyte model i sin helhed fra træning-PS til online serving-PS vil lægge et enormt pres på både netværksbåndbredden og hukommelsen på PS, da det kræver fordoblet modelstørrelse af hukommelse for at acceptere den nyankomne model. For at onlinetræning kan skalere til størrelsen af vores forretningsscenario, har vi designet en inkrementel on-the-fly periodisk parameter synkroniseringsmekanisme i Monolith baseret på flere bemærkelsesværdige karakteristika ved vores modeller: (1) > Sparsomme parametre dominerer størrelsen af anbefalingsmodeller; (2) > Givet et kort tidsvindue bliver kun en lille delmængde af ID'er trænet, og deres embeddings opdateres; (3) > Tætte variable bevæger sig meget langsommere end sparsomme embeddings. Dette skyldes, at i momentum-baserede optimeringsprogrammer akkumuleres momentum for tætte variable af den gigantiske størrelse af anbefalingstræningsdata, mens kun få sparsomme embeddings modtager opdateringer i en enkelt databatchen. (1) og (2) giver os mulighed for at udnytte de sparsomme opdateringer på tværs af alle træk-ID'er. I Monolith opretholder vi et hash-sæt af berørte nøgler, der repræsenterer ID'er, hvis embeddings blev trænet siden den sidste parameter synkronisering. Vi skubber delmængden af sparsomme parametre, hvis nøgler er i det berørte nøglesæt, med et minut-niveau tidsinterval fra træning-PS til online serving-PS. Denne relativt lille pakke af inkrementelle parameteropdateringer er letvægts for netværksoverførsel og vil ikke forårsage en skarp hukommelsesstigning under synkroniseringen. Vi udnytter også (3) til yderligere at reducere netværks I/O og hukommelsesforbrug ved at sætte en mere aggressiv synkroniseringsplan for sparsomme parametre, mens tætte parametre opdateres mindre hyppigt. Dette kan give os en situation, hvor de tætte parametre, vi serverer, er en relativt forældet version sammenlignet med den sparsomme del. Sådan uoverensstemmelse kan dog tolereres på grund af årsagen nævnt i (3), da intet tydeligt tab er observeret. 2.3 Fejltolerance Som et system i produktion er Monolith designet med evnen til at gendanne en PS i tilfælde af fejl. Et almindeligt valg for fejltolerance er at tage et snapshot af modellens tilstand periodisk og gendanne fra det seneste snapshot, når PS-fejl opdages. Valget af snapshot-frekvens har to store konsekvenser: (1) > Modelkvalitet. Intuitivt lider modelkvaliteten mindre af tab af nylig historie med øget snapshot-frekvens. (2) > Beregningsmæssig overhead. At tage et snapshot af en multi-terabyte model er ikke gratis. Det medfører store mængder hukommelses kopiering og disk I/O. Som en afvejning mellem modelkvalitet og beregningsmæssig overhead tager Monolith snapshots af alle trænings-PS dagligt. Selvom en PS vil miste en dags opdateringer i tilfælde af en fejl, opdagede vi, at ydelsesnedgangen er acceptabel gennem vores eksperimenter. Vi vil analysere effekten af PS-pålidelighed i det næste afsnit. 3 EVALUERING For en bedre forståelse af fordelene og kompromiserne forårsaget af vores foreslåede design, udførte vi flere eksperimenter i produktionsskala og A/B-test med live serving traffic for at evaluere og verificere Monolith fra forskellige aspekter. Vi sigter mod at besvare følgende spørgsmål med vores eksperimenter: (1) > Hvor meget kan vi drage fordel af en kollisionsfri HashTable? (2) > Hvor vigtigt er realtids onlinetræning? (3) > Er Monoliths design af parameter synkronisering robust nok i et storskalaproduktionsscenario? I dette afsnit præsenterer vi først vores eksperimentelle opsætning og diskuterer derefter resultater og vores fund i detaljer. 3.1 Eksperimentel opsætning Som beskrevet i afsnit er embedding-tabeller i Monolith implementeret som kollisionsfri HashTables. For at bevise nødvendigheden af at undgå kollisioner i embedding-tabeller og kvantificere gevinster fra vores kollisionsfri implementering, udførte vi to grupper af eksperimenter på Movielens datasæt og på vores interne produktionsdatasæt henholdsvis: 3.1.1 Embedding Tabel. 2.1 (1) > ml-25m datasæt [ ]. Dette er et standard offentligt datasæt til filmanmeldelser, der indeholder 25 millioner anmeldelser, der involverer cirka 162.000 brugere og 62.000 film. MovieLens 11 • . De oprindelige etiketter er anmeldelser fra Forbehandling af etiketter 0.5 til 5.0, mens vi i produktion primært modtager binære signaler fra brugere. For bedre at simulere vores produktionsmodeller konverterer vi skalaetiketter til binære etiketter ved at behandle scorer ≥ 3.5 som positive eksempler og resten som negative eksempler. • Model og metrikker. Vi implementerede en standard DeepFM-model, en almindeligt anvendt modelarkitektur til anbefalingsproblemer. Den består af en FM-komponent og en tæt komponent (Figur 6). Forudsigelser evalueres ved AUC, da dette er den primære måling for reelle modeller. • Embedding kollisioner. Dette datasæt indeholder cirka 160K bruger-ID'er og 60K film-ID'er. For at sammenligne med den kollisionsfri version af embedding-tabelimplementeringen udførte vi en anden gruppe eksperimenter, hvor ID'er blev forbehandlet med MD5-hashing og derefter mappet til et mindre ID-rum. Som resultat vil nogle ID'er dele deres embedding med andre. Tabel 1 viser detaljerede statistikker over bruger- og film-ID'er før og efter hashing. (2) . Internt anbefalingsdatasæt Vi udførte også eksperimenter på en anbefalingsmodel i produktionsmiljøet. Denne model følger generelt en multi-tower arkitektur, hvor hvert tårn er ansvarligt for at lære at forudsige en specialiseret type brugeradfærd. Hver model har omkring 1000 embedding-tabeller, og fordelingen af embedding-tabellernes størrelse er meget ujævn; Det oprindelige ID-rum for embedding-tabellen var 248. I vores baseline anvendte vi en hashing-trick ved at dekomponere for at begrænse størrelsen af embedding-tabellen. Mere specifikt bruger vi to mindre embedding-tabeller i stedet for en gigantisk til at generere en unik embedding for hvert ID ved vektor-kombination: hvor 𝐸𝑟 , 𝐸𝑞 er embeddings, der svarer til 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Dette reducerer effektivt embedding-tabelstørrelserne fra 248 til 225; • Denne model serverer i reel produktion, og ydelsen af dette eksperiment måles ved online AUC med reel serving-trafik. Under onlinetræning opdaterer vi vores onlinse serving-PS med det seneste sæt af parametre med minut-niveau intervaller. Vi designede to grupper af eksperimenter for at verificere modelkvalitet og systemrobusthed. 3.1.2 Onlinetræning. (1) > . For at undersøge nødvendigheden af minut-niveau opdateringsfrekvens, udførte vi eksperimenter, der synkroniserer parametre fra træningsmodel til forudsigelsesmodel med forskellige intervaller. Opdateringsfrekvens Datasættet, vi bruger, er Criteo Display Ads Challenge dataset3, et storskalastandard datasæt til benchmarking af CTR-modeller. Det indeholder 7 dages kronologisk ordnede data, der registrerer træk og klikhandlinger. Til dette eksperiment bruger vi en standard DeepFM-model som beskrevet i 6.. For at simulere onlinetræning udførte vi følgende forbehandling af