Inuti ByteDance's monolit: Motorn som driver smartare, snabbare innehållsflöden

Författare: 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) SAMMANFATTNING Att bygga ett skalbart och realtidssystem för rekommendationer är avgörande för många företag som drivs av tidskänslig kundfeedback, såsom rankning av kortvideor eller onlineannonser. Trots den allestädes närvarande adoptionen av produktionsskaliga djupinlärningsramar som TensorFlow eller PyTorch, uppfyller dessa allmänna ramverk inte affärernas krav i rekommendationsscenarier av olika anledningar: å ena sidan är justering av system baserade på statiska parametrar och täta beräkningar för rekommendation med dynamiska och glesa funktioner skadligt för modellkvaliteten; å andra sidan är sådana ramverk utformade med separerade steg för batchträning och servering, vilket förhindrar modellen från att interagera med kundfeedback i realtid. Dessa problem ledde oss till att ompröva traditionella metoder och utforska radikalt annorlunda designval. I den här artikeln presenterar vi 1, ett system skräddarsytt för onlineträning. Vår design har drivits av observationer av våra applikationsarbetsbelastningar och produktionsmiljö som återspeglar en markant avvikelse från andra rekommendationssystem. Våra bidrag är mångfacetterade: för det första har vi skapat en kollisionsfri inbäddningstabell med optimeringar som expirerande inbäddningar och frekvensfiltrering för att minska dess minnesavtryck; för det andra tillhandahåller vi en produktionsklar arkitektur för onlineträning med hög feltolerans; slutligen har vi bevisat att systemtillförlitlighet kan bytas mot realtidsinlärning. Monolith har framgångsrikt implementerats i BytePlus Recommend2-produkten. Monolith 1 INTRODUKTION Det senaste decenniet har bevittnat en boom av företag som drivs av rekommendationstekniker. I strävan efter en bättre kundupplevelse är leverans av personligt anpassat innehåll för varje enskild användare som en realtidssvar ett gemensamt mål för dessa affärsapplikationer. För att uppnå detta används information från en användares senaste interaktion ofta som primär input för att träna en modell, eftersom den bäst skulle avbilda en användares porträtt och förutsäga användarens intresse och framtida beteenden. Djupinlärning har dominerat rekommendationsmodeller [ , , , , , ] eftersom den gigantiska mängden användardata är en naturlig passform för massivt datadrivna neurala modeller. Ansträngningar att utnyttja djupinlärningens kraft i industriella rekommendationssystem stöter dock ständigt på problem som uppstår från de unika egenskaperna hos data som härrör från verkligt användarbeteende. Dessa data skiljer sig drastiskt från de som används i konventionella djupinlärningsproblem som språkmodellering eller datorsyn på två sätt: 5 6 10 12 20 21 (1) Funktionerna är mestadels glesa, kategoriska och dynamiskt föränderliga; (2) Den underliggande fördelningen av träningsdata är icke-stationär, även känd som konceptdrift . Sådana skillnader har medfört unika utmaningar för forskare och ingenjörer som arbetar med rekommendationssystem. 1.1 Gleshet och dynamik Data för rekommendationer innehåller mestadels glesa kategoriska funktioner, varav vissa förekommer med låg frekvens. Den vanliga metoden att mappa dem till ett högdimensionellt inbäddningsutrymme skulle ge upphov till en serie problem: • Till skillnad från språkmodeller där antalet ordstycken är begränsat, är antalet användare och rankade objekt i storleksordningar större. En så enorm inbäddningstabell skulle knappast få plats i ett enskilt värdminne; • Ännu värre är att storleken på inbäddningstabellen förväntas växa över tid när fler användare och objekt tillkommer, medan ramverk som [ , ] använder fasta täta variabler för att representera inbäddningstabellen. 1 17 I praktiken använder många system hashning med låg kollision [ , ] som ett sätt att minska minnesavtrycket och tillåta ID-tillväxt. Detta bygger på en överidealistisk antagande att ID:n i inbäddningstabellen är jämnt fördelade i frekvens, och att kollisioner är ofarliga för modellkvaliteten. Tyvärr är detta sällan sant för ett verkligt rekommendationssystem, där en liten grupp användare eller objekt har betydligt fler förekomster. Med den organiska tillväxten av inbäddningstabellens storlek ökar chanserna för hashkollisioner och leder till försämring av modellkvaliteten 3 6 . Därför är det ett naturligt krav för produktionsskaliga rekommendationssystem att ha kapacitet att fånga så många funktioner som möjligt i sina parametrar, och även förmågan att elastiskt justera antalet användare och objekt de försöker bokföra. 1.2 Icke-stationär fördelning Visuella och språkliga mönster utvecklas knappast i en tidsskala av århundraden, medan samma användare som är intresserad av ett ämne kan ändra sin iver varje nästa minut. Som ett resultat är den underliggande fördelningen av användardata icke-stationär, ett fenomen som vanligtvis kallas konceptdrift . Intuitivt kan information från en mer nylig historik mer effektivt bidra till att förutsäga förändringar i en användares beteende. För att mildra effekten av konceptdrift måste serveringsmodeller uppdateras från ny användarfeedback så nära realtid som möjligt för att återspegla en användares senaste intresse. Med tanke på dessa skillnader och med observationer av problem som uppstår i vår produktion, designade vi , ett storskaligt rekommendationssystem för att hantera dessa smärtpunkter. Vi utförde omfattande experiment för att verifiera och iterera vår design i produktionsmiljön. Monolith kan: Monolith (1) Ge full uttrycksfull kraft för glesa funktioner genom att designa en kollisionsfri hash-tabell och en dynamisk mekanism för funktionsejektion; (2) Återkoppla serveringsfeedback till träning i realtid med onlineträning. Med dessa arkitektoniska kapaciteter överträffar Monolith konsekvent system som använder hash-tricks med kollisioner med ungefär liknande minnesanvändning, och uppnår toppmodern online-servering AUC utan att överbelasta våra servrars beräkningskraft. Resten av artikeln är organiserad enligt följande. Vi utarbetar först design-detaljer om hur Monolith hanterar befintliga utmaningar med kollisionsfri hash-tabell och realtidsträning i avsnitt 2. Experiment och resultat presenteras i avsnitt 3, tillsammans med produktionsprövade slutsatser och lite diskussion om avvägningar mellan tids-känslighet, tillförlitlighet och modellkvalitet. Avsnitt 4 sammanfattar relaterat arbete och jämför dem med Monolith. Avsnitt 5 sammanfattar detta arbete. 2 DESIGN I en Worker-PS-arkitektur tilldelas maskiner olika roller; Worker-maskiner ansvarar för att utföra beräkningar som definieras av grafen, och PS-maskiner lagrar parametrar och uppdaterar dem enligt gradienter som beräknats av Workers. Monoliths övergripande arkitektur följer generellt TensorFlows distribuerade Worker- arameter erver-inställning (Figur P S 2). I rekommendationsmodeller kategoriseras parametrar i två uppsättningar: täta och glesa. Täta parametrar är vikter/variabler i ett djupt neuralt nätverk, och glesa parametrar hänvisar till inbäddningstabeller som motsvarar glesa funktioner. I vår design är både täta och glesa parametrar en del av TensorFlow-grafen och lagras på parametrar-servrar. Liknande TensorFlows variabler för täta parametrar, designade vi en uppsättning högeffektiva, kollisionsfria och flexibla HashTable-operationer för glesa parametrar. Som ett komplement till TensorFlows begränsning som uppstår från separationen av träning och inferens, är Monoliths elastiskt skalbara onlineträning utformad för att effektivt synkronisera parametrar från tränings-PS till online-serverings-PS inom korta intervaller, med modellens robusthetsgaranti genom feltoleransmekanism. 2.1 Hash-tabell En grundläggande princip i vår design av representation av glesa parametrar är att undvika att pressa information från olika ID:n till samma fasta inbäddning. Simulering av en inbäddningstabell med dynamisk storlek med en färdig TensorFlow-variabel leder oundvikligen till ID-kollisioner, vilket förvärras när nya ID:n anländer och tabellen växer. Därför, istället för att bygga på variabler, utvecklade vi en ny nyckel-värde HashTable för våra glesa parametrar. Vår HashTable använder Cuckoo Hashmap [ ] internt, vilket stöder införande av nya nycklar utan att kollidera med befintliga. Cuckoo Hashing uppnår sämsta fall 𝑂 (1) tidskomplexitet för uppslag och raderingar, och förväntad amorterad 𝑂 (1) tid för införanden. Som illustrerat i Figur upprätthåller den två tabeller 𝑇0, 𝑇1 med olika hash-funktioner ℎ0 (𝑥), ℎ1 (𝑥), och ett element lagras i en av dem. När man försöker infoga ett element 16 3 𝐴 i 𝑇0, försöker den först placera 𝐴 vid ℎ0 (𝐴); Om ℎ0 (𝐴) är upptagen av ett annat element 𝐵, kommer den att utvisa 𝐵 från 𝑇0 och försöka infoga 𝐵 i 𝑇1 med samma logik. Denna process upprepas tills alla element stabiliseras, eller så sker en omhashning när infogningen hamnar i en cykel. Minskning av minnesavtrycket är också en viktig faktor i vår design. En naiv metod att infoga varje nytt ID i HashTable kommer snabbt att tömma minnet. Observationer av verkliga produktionsmodeller leder till två slutsatser: (1) ID:n som förekommer endast ett fåtal gånger har begränsat bidrag till att förbättra modellkvaliteten. En viktig observation är att ID:n är långsvansfördelade, där populära ID:n kan förekomma miljontals gånger medan de impopulära förekommer högst tio gånger. Inbäddningar som motsvarar dessa sällsynta ID:n är underanpassade på grund av brist på träningsdata och modellen kommer inte att kunna göra en bra uppskattning baserad på dem. I slutändan är det osannolikt att dessa ID:n påverkar resultatet, så modellkvaliteten kommer inte att lida av borttagning av dessa ID:n med låga förekomster; (2) Föråldrade ID:n från en avlägsen historik bidrar sällan till den aktuella modellen eftersom många av dem aldrig besöks. Detta kan möjligen bero på en användare som inte längre är aktiv, eller en kortvideo som är föråldrad. Att lagra inbäddningar för dessa ID:n kan inte hjälpa modellen på något sätt, förutom att tömma vårt PS-minne förgäves. Baserat på dessa observationer har vi designat flera heuristiker för filtrering av funktions-ID:n för en mer minneseffektiv implementation av HashTable: (1) ID:n filtreras innan de tillåts i inbäddningstabeller. Vi har två filtreringsmetoder: Först filtrerar vi efter deras förekomster innan de infogas som nycklar, där tröskeln för förekomster är en justerbar hyperparameter som varierar för varje modell; Dessutom använder vi ett probabilistiskt filter som ytterligare hjälper till att minska minnesanvändningen; ![#Figur 4: Streaming Engine. Informationsåterkopplingsloopen från [Användare → Modellserver → Träningsarbetare → Modellserver → Användare] skulle ta lång tid att ta Batch-träningsvägen, medan Onlineträning stänger loopen mer omedelbart.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID:n tidsbestäms och ställs in för att löpa ut efter att ha varit inaktiva under en fördefinierad tidsperiod. Utgångstiden är också justerbar för varje inbäddningstabell för att tillåta urskiljning av funktioner med olika känslighet för historisk information. I vår implementation implementeras HashTable som en TensorFlow-resursoperation. Liknande variabler är uppslag och uppdateringar också implementerade som inbyggda TensorFlow-operationer för enklare integration och bättre kompatibilitet. 2.2 Onlineträning I Monolith är träning uppdelad i två steg (Figur 1): (1) Batchträningssteg. Detta steg fungerar som en vanlig TensorFlow-träningsloop: I varje träningssteg läser en träningsarbetare en minibatch av träningsdata från lagringen, begär parametrar från PS, beräknar en framåt- och en bakåtpassning, och skickar slutligen uppdaterade parametrar till tränings-PS. Något annorlunda än andra vanliga djupinlärningsuppgifter, tränar vi bara vårt dataset för en passning. Batchträning är användbar för att träna historiska data när vi modifierar vår modellarkitektur och tränar om modellen; (2) Onlineträningssteg. Efter att en modell har driftsatts för onlineservering, upphör inte träningen utan går in i onlineträningssteget. Istället för att läsa minibatch-data från lagringen, konsumerar en träningsarbetare realtidsdata on-the-fly och uppdaterar tränings-PS. Tränings-PS synkroniserar periodiskt sina parametrar till serverings-PS, vilket omedelbart får effekt på användarsidan. Detta möjliggör för vår modell att interaktivt anpassa sig enligt en användares feedback i realtid. Monolith är byggt med kapacitet att sömlöst växla mellan batchträning och onlineträning. Detta möjliggörs av vår design av streaming engine som illustreras av Figur 2.2.1 Streaming Engine. 4. I vår design använder vi en Kafka [ ] kö för att logga användaråtgärder (t.ex. klick på ett objekt eller gillande av ett objekt etc.) och en annan Kafka kö för funktioner. Kärnan i motorn är ett Flink [ ] strömmande jobb för online-funktions-joiner. Online-joinern kombinerar funktioner med etiketter från användaråtgärder och producerar träningsdata, som sedan skrivs till en Kafka-kö. Köen för träningsdata konsumeras av både onlineträning och batchträning: 13 4 För onlineträning läser träningsarbetaren data direkt från Kafka-köen; För batchträning kommer ett datadumpningsjobb först att dumpa data till HDFS [ ]; Efter att data i HDFS har ackumulerats till en viss mängd, kommer träningsarbetaren att hämta data från HDFS och utföra batchträning. 18 Uppdaterade parametrar i tränings-PS skickas till serverings-PS enligt schemat för parametersynkronisering. I verkliga applikationer strömmas användaråtgärdsloggar och funktioner in i online-joinern (Figur utan garanti för tidsordning. Därför använder vi en unik nyckel för varje förfrågan så att användaråtgärd och funktioner kan paras ihop korrekt. 2.2.2 Online Joiner. 5) Fördröjningen av användaråtgärder kan också vara ett problem. Till exempel kan en användare ta några dagar innan de bestämmer sig för att köpa en vara som de presenterades för dagar sedan. Detta är en utmaning för joinern eftersom om alla funktioner hålls i cacheminnet, skulle det helt enkelt inte passa i minnet. I vårt system används ett lagringsutrymme för nyckel-värde på disk för att lagra funktioner som väntar under en viss tidsperiod. När en användaråtgärdslogg anländer, slår den först upp i cacheminnet, och sedan slår den upp i nyckel-värde-lagringen om det saknas i cacheminnet. Ett annat problem som uppstår i verkliga applikationer är att fördelningen av negativa och positiva exempel är mycket ojämn, där antalet av de förra kan vara magnituder högre än de senare. För att förhindra att positiva exempel översvämmas av negativa, är en vanlig strategi att göra negativ sampling. Detta kommer definitivt att förändra den underliggande fördelningen av den tränade modellen, och justera den mot en högre sannolikhet att göra positiva förutsägelser. Som en åtgärd tillämpar vi log odds-korrigering [ ] under servering, vilket säkerställer att online-modellen är en väntevärdeskorrekt estimator av den ursprungliga fördelningen. 19 Under onlineträning fortsätter Monolith-träningsklustret att ta emot data från online-serveringsmodulen och uppdaterar parametrar på tränings-PS. Ett avgörande steg för att online-serverings-PS ska dra nytta av dessa nyligen tränade parametrar är synkroniseringen av uppdaterade modellparametrar. I produktionsmiljön ställs vi inför flera utmaningar: 2.2.3 Parametersynkronisering. Modeller på online-serverings-PS får inte sluta servera vid uppdatering. Våra modeller i produktion är vanligtvis flera terabyte stora, och som ett resultat tar det tid att ersätta alla parametrar. Det skulle vara oacceptabelt att stoppa en online-PS från att servera modellen under ersättningsprocessen, och uppdateringar måste göras on-the-fly; Att överföra en multi-terabyte modell i sin helhet från tränings-PS till online-serverings-PS skulle innebära en enorm press på både nätverksbandbredden och minnet på PS, eftersom det kräver dubbelt modellstorlek i minnet för att ta emot den nyanlända modellen. För att onlineträning ska kunna skalas upp till storleken av vårt affärsscenario har vi designat en inkrementell on-the-fly periodisk parametersynkroniseringsmekanism i Monolith baserad på flera märkbara egenskaper hos våra modeller: (1) Glesa parametrar dominerar storleken på rekommendationsmodeller; (2) Givet ett kort tidsfönster tränas endast en liten delmängd av ID:n och deras inbäddningar uppdateras; (3) Täta variabler rör sig mycket långsammare än glesa inbäddningar. Detta beror på att i momentumbaserade optimerare ackumuleras momentum för täta variabler av den gigantiska storleken på rekommendationsträningsdata, medan endast ett fåtal glesa inbäddningar får uppdateringar i en enskild databatch. (1) och (2) tillåter oss att utnyttja de glesa uppdateringarna över alla funktions-ID. I Monolith upprätthåller vi en hash-uppsättning av berörda nycklar, vilket representerar ID:n vars inbäddningar har tränats sedan den senaste parametersynkroniseringen. Vi skickar delmängden av glesa parametrar vars nycklar finns i den berörda nyckelsatsen med ett intervall på en minut från tränings-PS till online-serverings-PS. Detta relativt lilla paket av inkrementella parameteruppdateringar är lättviktigt för nätverksöverföring och orsakar inte en skarp minnesökning under synkroniseringen. Vi utnyttjar också (3) för att ytterligare minska nätverkets I/O och minnesanvändning genom att ställa in ett mer aggressivt synkroniseringsschema för glesa parametrar, medan täta parametrar uppdateras mindre ofta. Detta kan ge oss en situation där de täta parametrarna vi serverar är en relativt föråldrad version jämfört med den glesa delen. Dock kan sådan inkonsekvens tolereras på grund av anledningen som nämns i (3) eftersom ingen uppenbar förlust har observerats. 2.3 Feltolerans Som ett system i produktion är Monolith designat med förmågan att återhämta en PS om den misslyckas. Ett vanligt val för feltolerans är att periodiskt ta en ögonblicksbild av modellens tillstånd och återhämta sig från den senaste ögonblicksbilden när PS-fel upptäcks. Valet av ögonblicksbildfrekvens har två stora effekter: (1) Modellkvalitet. Intuitivt lider modellkvaliteten mindre av förlust av nyligen historik med ökad ögonblicksbildfrekvens. (2) Beräkningsmässig overhead. Att ta en ögonblicksbild av en multi-terabyte modell är inte gratis. Det medför stora kopieringar av minne och disk-I/O. Som en avvägning mellan modellkvalitet och beräkningsmässig overhead, tar Monolith ögonblicksbilder av alla tränings-PS varje dag. Även om en PS kommer att förlora en dags uppdateringar i händelse av fel, upptäcker vi att prestandaförsämringen är tolererbar genom våra experiment. Vi kommer att analysera effekten av PS-tillförlitlighet i nästa avsnitt. 3 EVALUERING För en bättre förståelse av fördelarna och avvägningarna som vår föreslagna design medför, genomförde vi flera experiment i produktionsskala och A/B-test med live serveringstrafik för att utvärdera och verifiera Monolith från olika aspekter. Vi strävar efter att besvara följande frågor genom våra experiment: (1) Hur mycket kan vi dra nytta av en kollisionsfri HashTable? (2) Hur viktig är realtids-onlineträning? (3) Är Monoliths design av parametersynkronisering robust nog i ett storskaligt produktionsscenario? I detta avsnitt presenterar vi först våra experimentinställningar och diskuterar sedan resultat och våra fynd i detalj. 3.1 Experimentinställningar Som beskrivs i avsnitt implementeras inbäddningstabeller i Monolith som kollisionsfria HashTables. För att bevisa nödvändigheten av att undvika kollisioner i inbäddningstabeller och kvantifiera vinster från vår kollisionsfria implementation, utförde vi två grupper av experiment på Movielens dataset och på vårt interna produktionsdataset respektive: 3.1.1 Inbäddningstabell. 2.1, (1) ml-25m dataset [ ]. Detta är ett standard offentligt dataset för filmrecensioner, som innehåller 25 miljoner recensioner som involverar cirka 162 000 användare och 62 000 filmer. MovieLens 11 • . De ursprungliga etiketterna är betyg från Förbehandling av etiketter 0.5 till 5.0, medan vi i produktion oftast får binära signaler från användare. För att bättre simulera våra produktionsmodeller konverterar vi skaletiketter till binära etiketter genom att behandla poäng ≥ 3.5 som positiva exempel och resten som negativa exempel. • Modell och mått. Vi implementerade en standard DeepFM modell, en vanligt förekommande modellarkitektur för rekommendationsproblem. Den består av en FM-komponent och en tät komponent (Figur 6). Förutsägelser utvärderas av AUC eftersom detta är det huvudsakliga måttet för verkliga modeller. • Inbäddningskollisioner. Detta dataset innehåller cirka 160 000 användar-ID:n och 60 000 film-ID:n. För att jämföra med den kollisionsfria versionen av inbäddningstabellens implementation, utförde vi en annan grupp experiment där ID:n förbehandlades med MD5-hashning och sedan mappades till ett mindre ID-utrymme. Som ett resultat kommer vissa ID:n att dela sin inbäddning med andra. Tabell 1 visar detaljerad statistik över användar- och film-ID:n före och efter hashning. (2) . Internt rekommendationsdataset Vi utförde även experiment på en rekommendationsmodell i produktionsmiljö. Denna modell följer generellt en multi-tower-arkitektur, där varje tower ansvarar för att lära sig att förutsäga en specialiserad typ av användarbeteende. Varje modell har cirka 1000 inbäddningstabeller, och fördelningen av storleken på inbäddningstabellerna är mycket ojämn; Det ursprungliga ID-utrymmet för inbäddningstabellen var 248. I vår baslinje tillämpade vi en hashing-trick genom att dekomponera för att begränsa storleken på inbäddningstabellen. Mer specifikt använder vi två mindre inbäddningstabeller istället för en gigantisk för att generera en unik inbäddning för varje ID genom vektorkombination: där 𝐸𝑟 , 𝐸𝑞 är inbäddningar som motsvarar 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Detta minskar effektivt storleken på inbäddningstabellen från 248 till 225; • Denna modell serveras i verklig produktion, och prestandan för detta experiment mäts av online AUC med verklig serveringstrafik. Under onlineträning uppdaterar vi våra online-serverings-PS med den senaste uppsättningen parametrar med intervaller på en minut. Vi designade två grupper av experiment för att verifiera modellkvalitet och systemrobusthet. 3.1.2 Onlineträning. (1) . För att undersöka nödvändigheten av minut-nivå uppdateringsfrekvens, genomförde vi experiment som synkroniserar parametrar från träningsmodellen till prediktionsmodellen med olika intervaller. Uppdateringsfrekvens Datasetet vi använder är Criteo Display Ads Challenge dataset3, ett storskaligt standarddataset för benchmarking av CTR-modeller. Det innehåller 7 dagars kronologiskt ordnad data som registrerar funktioner och klickå