ByteDancen monoliitin sisällä: Älykkäämpiä, nopeampia sisältövirtoja vauhdittava moottori

Tekijät: 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) TIIVISTELMÄ Skaalautuvan ja reaaliaikaisen suositusjärjestelmän rakentaminen on elintärkeää monille yrityksille, jotka toimivat aikakriittisen asiakaspalautteen varassa, kuten lyhytvideoiden paremmuusjärjestyksen tai verkkomainosten kohdalla. Huolimatta tuotantomittakaavaisten syväoppimiskehysten, kuten TensorFlow'n tai PyTorchin, yleisestä käyttöönotosta, nämä yleiskäyttöiset kehykset eivät vastaa suositus-skenaarioiden liiketoimintavaatimuksia useista syistä: toisaalta staattisiin parametreihin ja tiheisiin laskelmiin perustuvien järjestelmien säätäminen dynaamisilla ja harvoilla ominaisuuksilla on haitallista mallin laadulle; toisaalta tällaiset kehykset on suunniteltu siten, että eräharjoitusvaihe ja palveluvaihe ovat täysin erillisiä, mikä estää mallia vuorovaikutuksesta asiakaspalautteen kanssa reaaliajassa. Nämä ongelmat saivat meidät tarkastelemaan uudelleen perinteisiä lähestymistapoja ja tutkimaan radikaalisti erilaisia suunnitteluratkaisuja. Tässä artikkelissa esittelemme 1:n, verkko-oppimiseen räätälöidyn järjestelmän. Suunnittelumme perustuu sovelluskuormitustemme ja tuotantoympäristömme havaintoihin, jotka heijastavat merkittävää poikkeamaa muista suositusjärjestelmistä. Kontribuutiomme ovat moninaiset: ensinnäkin loimme törmäysvapaan upotustaulun optimoinneilla, kuten vanhenevilla upotuksilla ja tiheyssuodatuksella, sen muistijalanjäljen pienentämiseksi; toiseksi tarjoamme tuotantovalmiin verkko-oppimisarkkitehtuurin korkealla vikasietoisuudella; lopuksi todistimme, että järjestelmän luotettavuutta voidaan vaihtaa reaaliaikaista oppimista vastaan. Monolith on onnistuneesti integroitu BytePlus Recommend2-tuotteeseen. Monolith 1 JOHDANTO Viime vuosikymmen on todistanut suositustekniikoiden voiman avulla toimivien yritysten buumin. Paremman asiakaskokemuksen tavoittelussa personoidun sisällön toimittaminen jokaiselle yksittäiselle käyttäjälle reaaliaikaisena vastauksena on yhteinen tavoite näille liiketoimintasovelluksille. Tämän saavuttamiseksi käyttäjän viimeisintä vuorovaikutusta koskevaa tietoa käytetään usein ensisijaisena panoksena mallin harjoittamiseen, koska se kuvaa parhaiten käyttäjän profiilia ja ennustaa käyttäjän kiinnostuksen kohteita ja tulevia käyttäytymismalleja. Syväoppiminen on hallinnut suositusmalleja [ , , , , , ], koska valtava määrä käyttäjädataa sopii luonnostaan massiivisesti dataan perustuviin neuroverkkomalleihin. Pyrkimykset hyödyntää syväoppimisen tehoa teollisuustason suositusjärjestelmissä kohtaavat jatkuvasti ongelmia, jotka johtuvat todellisen maailman käyttäytymisdatan ainutlaatuisista ominaisuuksista. Nämä tiedot eroavat dramaattisesti perinteisistä syväoppimisongelmista, kuten kielimallinnuksesta tai konenäöstä, kahdella tavalla: 5 6 10 12 20 21 (1) Ominaisuudet ovat enimmäkseen harvoja, kategorisia ja dynaamisesti muuttuvia; (2) Harjoitusdatan taustalla oleva jakauma on epästationaarinen, eli käsite-ajautuminen (Concept Drift) . Tällaiset erot ovat asettaneet ainutlaatuisia haasteita suositusjärjestelmien parissa työskenteleville tutkijoille ja insinööreille. 1.1 Harvuus ja Dynamiikka Suositusdata sisältää enimmäkseen harvoja kategorisia ominaisuuksia, joista osa esiintyy harvoin. Yleinen käytäntö niiden yhdistämisestä korkeaulotteiseen upotusavaruuteen johtaa sarjaan ongelmia: • Toisin kuin kielimalleissa, joissa sanan osien määrä on rajallinen, käyttäjien ja paremmuusjärjestykseen asetettavien kohteiden määrä on kertaluokkia suurempi. Tällainen valtava upotustaulu tuskin mahtuu yhden isäntäkoneen muistiin; • Vielä pahempaa on, että upotustaulun koon odotetaan kasvavan ajan myötä, kun enemmän käyttäjiä ja kohteita lisätään, kun taas kehykset kuten [ , ] käyttävät kiinteän kokoisia tiheitä muuttujia upotustaulun esittämiseen. 1 17 Käytännössä monet järjestelmät käyttävät vähäisiä törmäyksiä aiheuttavaa hajautusta (low-collision hashing) [ , ] muistin käyttöä vähentääkseen ja tunnusten kasvun mahdollistamiseksi. Tämä perustuu yli-idealistiseen oletukseen, että tunnukset upotustaulussa jakautuvat tasaisesti tiheyden mukaan ja törmäykset ovat vaarattomia mallin laadulle. Valitettavasti tämä on harvoin totta todellisessa suositusjärjestelmässä, jossa pienellä käyttäjä- tai kohderyhmällä on merkittävästi enemmän esiintymiä. Upotustaulun koon orgaanisen kasvun myötä hajautusavainten törmäysten todennäköisyys kasvaa ja johtaa mallin laadun heikkenemiseen 3 6 . Siksi tuotantomittakaavaisten suositusjärjestelmien luonnollinen vaatimus on kyky tallentaa mahdollisimman monta ominaisuutta parametreihinsa ja kyky joustavasti säätää pidätettävien käyttäjien ja kohteiden määrää. 1.2 Epästationaarinen Jakauma Visuaaliset ja kielelliset kuviot kehittyvät tuskin vuosisatojen aikaskaalassa, kun taas sama käyttäjä, joka on kiinnostunut yhdestä aiheesta, voi vaihtaa intohimonsa seuraavassa minuutissa. Tämän seurauksena käyttäjädatan taustalla oleva jakauma on epästationaarinen, ilmiö, jota kutsutaan yleisesti käsite-ajautumiseksi (Concept Drift) . Intuitiivisesti tietoa lähimenneisyydestä voi tehokkaammin edistää käyttäjän käyttäytymisen muutoksen ennustamisessa. Käsite-ajautumisen vaikutuksen lieventämiseksi palvelumallit on päivitettävä uudella käyttäjäpalautteella mahdollisimman lähellä reaaliaikaa heijastamaan käyttäjän viimeisintä kiinnostusta. Näiden erojen valossa ja tuotantoympäristössämme esiintyvien ongelmien perusteella suunnittelimme in, suuren mittakaavan suositusjärjestelmän näiden kipupisteiden ratkaisemiseksi. Teimme laajoja kokeita suunnittelumme varmistamiseksi ja iteroimiseksi tuotantoympäristössä. Monolith pystyy Monolith (1) Tarjoamaan täyden ilmaisukyvyn harvoille ominaisuuksille suunnittelemalla törmäysvapaan hajautustaulun ja dynaamisen ominaisuuksien poistomekanismin; (2) Palauttamaan palvelupalautteen harjoitteluun reaaliajassa verkko-oppimisen avulla. Näiden arkkitehtuurin ominaisuuksien avulla Monolith ylittää johdonmukaisesti suorituskyvyltään järjestelmät, jotka käyttävät hajautustemppuja törmäyksillä, suunnilleen samanlaisella muistinkäytöllä, ja saavuttaa huippuluokan palvelun AUC:n ilman, että se kuormittaa liikaa palvelimiemme laskentatehoa. Loppuosa tästä artikkelista on organisoitu seuraavasti. Ensimmäiseksi selitämme suunnittelun yksityiskohdat siitä, miten Monolith käsittelee nykyisiä haasteita törmäysvapaan hajautustaulun ja reaaliaikaisen harjoittelun avulla, kohdassa 2. Kokeet ja tulokset esitellään kohdassa 3, yhdessä tuotantotestattujen johtopäätösten ja joidenkin aikakriittisyyden, luotettavuuden ja mallin laadun välisten kompromissien keskustelun kanssa. Kohdassa 4 summataan aiheeseen liittyvät työt ja verrataan niitä Monolithiin. Kohdassa 5 päätellään tämä työ. 2 SUUNNITTELU Monolithin yleinen arkkitehtuuri noudattaa yleensä TensorFlow'n hajautettua Worker- arameter erver-asetusta (Kuva Worker-PS-arkkitehtuurissa koneille on määritetty eri rooleja; Worker-koneet vastaavat grafiikan määrittelemien laskelmien suorittamisesta, ja PS-koneet tallentavat parametrit ja päivittävät niitä Workerien laskemien gradienttien mukaisesti. P S 2). Suositusmalleissa parametrit jaetaan kahteen ryhmään: tiheisiin ja harvoihin. Tiheät parametrit ovat syväneuroverkon painoja/muuttujia, ja harvat parametrit viittaavat upotustauluihin, jotka vastaavat harvoja ominaisuuksia. Suunnittelussamme sekä tiheät että harvat parametrit ovat osa TensorFlow-graafia ja ne tallennetaan parametripalvelimiin. Samoin kuin TensorFlow'n Variable tiheille parametreille, suunnittelimme joukon erittäin tehokkaita, törmäysvapaita ja joustavia HashTable-toimintoja harvoille parametreille. Komplementtina TensorFlow'n rajoituksiin, jotka johtuvat harjoittelun ja päättelyn erottamisesta, Monolithin joustavasti skaalautuva verkko-oppiminen on suunniteltu synkronoimaan tehokkaasti parametreja harjoitus-PS:stä verkko-palvelu-PS:ään lyhyin väliajoin, mallin kestävyys varmistettuna vikasietomekanismilla. 2.1 Hajautustaulu Ensimmäinen periaate harvan parametriesityksen suunnittelussamme on välttää eri tunnusten tietojen puristamista samaan kiinteän kokoiseen upotukseen. Dynaamisen kokoisen upotustaulun simulointi valmiilla TensorFlow Variablella johtaa väistämättä tunnusten törmäykseen, joka pahenee uusien tunnusten saapuessa ja taulun kasvaessa. Siksi sen sijaan, että rakentaisimme Variableen perustuen, kehitimme uuden avain-arvo-HashTable-rakenteen harvoille parametreille. HashTable-rakenteemme käyttää sisäisesti Cuckoo Hashmapia [ ], joka tukee uusien avainten lisäämistä törmäämättä olemassa oleviin. Cuckoo Hashing saavuttaa pahimmassa tapauksessa 𝑂 (1) aikakompleksisuuden hakemiselle ja poistamiselle, ja odotetun amortisoidun 𝑂 (1) aikakompleksisuuden lisäyksille. Kuten Kuvassa on esitetty, se ylläpitää kahta taulua 𝑇0, 𝑇1 eri hajautusfunktioilla ℎ0 (𝑥), ℎ1 (𝑥), ja elementti tallennetaan jompaankumpaan niistä. Kun yritetään lisätä elementtiä 16 3 𝐴 𝑇0:aan, se yrittää ensin sijoittaa 𝐴:n kohtaan ℎ0 (𝐴); Jos ℎ0 (𝐴) on varattu toisella elementillä 𝐵, se poistaa 𝐵:n 𝑇0:sta ja yrittää lisätä 𝐵:n 𝑇1:een samalla logiikalla. Tätä prosessia toistetaan, kunnes kaikki elementit ovat vakiintuneet, tai uudelleenhajautus tapahtuu, kun lisäys joutuu sykliin. Muistin käyttöasteen pienentäminen on myös tärkeä huomio suunnittelussamme. Naiivi lähestymistapa jokaisen uuden tunnuksen lisäämisestä HashTable-rakenteeseen tyhjentää muistin nopeasti. Havainnot todellisista tuotantomalleista johtavat kahteen johtopäätökseen: (1) Vain muutaman kerran esiintyvillä tunnuksilla on rajallinen vaikutus mallin laadun parantamiseen. Tärkeä havainto on, että tunnukset ovat pitkähäntäisesti jakautuneita, missä suositut tunnukset voivat esiintyä miljoonia kertoja, kun taas epäsuositut esiintyvät enintään kymmenen kertaa. Näihin harvoin esiintyviin tunnuksiin liittyvät upotukset ovat vajaavarustettuja harjoitusdatan puutteen vuoksi, eikä malli pysty tekemään hyvää arviota niistä. Loppujen lopuksi nämä tunnukset eivät todennäköisesti vaikuta tulokseen, joten mallin laatu ei kärsi näiden vähäisten esiintymien poistamisesta; (2) > Vanhentuneet tunnukset kaukaa menneisyydestä edistävät harvoin nykyistä mallia, koska niitä ei koskaan käydä läpi. Tämä voi johtua käyttäjästä, joka ei ole enää aktiivinen, tai lyhytvideosta, joka on vanhentunut. Näiden tunnusten upotusten tallentaminen ei auta mallia millään tavalla, vaan kuluttaa PS-muistiamme turhaan. Näiden havaintojen perusteella suunnittelimme useita ominaisuustunnusten suodatusheuristiikkaa muistitehokkaampaa HashTable-toteutusta varten: (1) Tunnukset suodatetaan ennen niiden hyväksymistä upotustauluihin. Meillä on kaksi suodatusmenetelmää: Ensinnäkin suodatamme esiintymiskertojen perusteella ennen kuin ne lisätään avaimina, missä esiintymiskynnys on säädettävä hyperparametri, joka vaihtelee mallikohtaisesti; Lisäksi käytämme todennäköisyyssuodatinta, joka auttaa vähentämään muistin käyttöä entisestään; ![#Kuva 4: Suoratoistomoottori. Tietojen palaute-silmukka [Käyttäjä → Mallipalvelin → Harjoittelutyöntekijä → Mallipalvelin → Käyttäjä] vie kauan aikaa eräharjoituspolulla, kun taas verkko-oppiminen sulkee silmukan välittömämmin.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Tunnukset ajastetaan ja asetetaan vanhenemaan tietyn ajanjakson passiivisuuden jälkeen. Vanhenemisaika on myös säädettävissä jokaiselle upotustaululle, jotta voidaan erottaa ominaisuudet, joilla on erilainen herkkyys historialliseen tietoon. Toteutuksessamme HashTable on toteutettu TensorFlow-resurssioperaationa. Samoin kuin Variable, haut ja päivitykset on myös toteutettu natiiveina TensorFlow-operaatioina helpompaa integraatiota ja parempaa yhteensopivuutta varten. 2.2 Verkko-oppiminen Monolithissa harjoittelu jaetaan kahteen vaiheeseen (Kuva 1): (1) Eräharjoitusvaihe. Tämä vaihe toimii tavallisena TensorFlow-harjoittelu-silmukkana: Jokaisessa harjoitusaskeleessa harjoittelutyöntekijä lukee yhden mini-erän harjoitusesimerkkejä tallennuspaikasta, pyytää parametreja PS:ltä, laskee eteen- ja taaksepäin ajon ja lopuksi siirtää päivitettyjä parametreja harjoitus-PS:lle. Hieman toisin kuin muissa yleisissä syväoppimistehtävissä, harjoitamme tietojoukkoa vain yhden kierroksen ajan. Eräharjoittelu on hyödyllistä historiallisten tietojen harjoittamiseen, kun muokkaamme malliarkkitehtuuriamme ja harjoitamme mallia uudelleen; (2) Verkko-oppimisvaihe. Kun malli on otettu käyttöön verkko-palvelussa, harjoittelu ei lopu, vaan siirtyy verkko-oppimisvaiheeseen. Sen sijaan, että luettaisiin mini-eräesimerkkejä tallennuspaikasta, harjoittelutyöntekijä käsittelee reaaliaikaista dataa lennossa ja päivittää harjoitus-PS:ää. Harjoitus-PS synkronoi parametrejaan säännöllisesti palvelu-PS:ään, mikä vaikuttaa välittömästi käyttäjän puolella. Tämä mahdollistaa mallimme vuorovaikutteisen mukautumisen käyttäjän palautteen mukaan reaaliajassa. Monolith on rakennettu kyvyllä vaihtaa saumattomasti eräharjoittelun ja verkko-oppimisen välillä. Tämän mahdollistaa suoratoistomoottorimme suunnittelu, kuten Kuvassa on esitetty. 2.2.1 Suoratoistomoottori. 4 Suunnittelussamme käytämme yhtä Kafka [ ] jonoa käyttäjien toimintojen (esim. kohteen klikkaus tai tykkäys) kirjaamiseen ja toista Kafka-jonoa ominaisuuksille. Moottorin ytimessä on Flink [ ] suoratoistotehtävä verkko-ominaisuusyhdistäjälle (online feature Joiner). Verkko-yhdistäjä yhdistää ominaisuudet käyttäjätoimintojen tunnisteisiin ja tuottaa harjoitusesimerkkejä, jotka kirjoitetaan sitten Kafka-jonoon. Harjoitusesimerkkien jonosta kuluttavat sekä verkko- että eräharjoittelu: 13 4 Verkko-oppimiselle harjoittelutyöntekijä lukee dataa suoraan Kafka-jonosta; Eräharjoittelulle datan dumppaustehtävä dumppaa datan ensin HDFS:ään [ ]; Kun HDFS:ään on kertynyt tietty määrä dataa, harjoittelutyöntekijä noutaa datan HDFS:stä ja suorittaa eräharjoittelun. 18 Päivitetyt parametrit harjoitus-PS:ssä siirretään palvelu-PS:ään parametrien synkronointiaikataulun mukaisesti. Todellisissa sovelluksissa käyttäjien toimintalokit ja ominaisuudet suoratoistetaan verkko-yhdistäjään (Kuva ilman aikajärjestystakuuta. Siksi käytämme kutakin pyyntöä varten yksilöllistä avainta, jotta käyttäjätoiminta ja ominaisuudet voidaan yhdistää oikein. 2.2.2 Verkko-yhdistäjä. 5) Käyttäjätoiminnan viive voi myös olla ongelma. Esimerkiksi käyttäjä voi viipyä muutaman päivän ennen kuin päättää ostaa esineen, jolle hänelle näytettiin esineitä päiviä sitten. Tämä on haaste yhdistäjälle, koska jos kaikki ominaisuudet pidetään välimuistissa, se ei yksinkertaisesti mahdu muistiin. Järjestelmässämme käytetään levypohjaista avain-arvo-tallennuspaikkaa ominaisuuksien tallentamiseen, jotka odottavat yli tietyn ajanjakson. Kun käyttäjätoimintaloki saapuu, se etsii ensin muistissa olevasta välimuistista ja sitten etsii avain-arvo-tallennuspaikasta, jos välimuistia ei löydy. Toinen todellisissa sovelluksissa esiintyvä ongelma on, että negatiivisten ja positiivisten esimerkkien jakauma on erittäin epätasainen, jossa edellisten määrä voi olla moninkertainen jälkimmäiseen verrattuna. Sen estämiseksi, että positiiviset esimerkit hukkuvat negatiivisten joukkoon, yleinen strategia on negatiivinen otanta. Tämä muuttaa varmasti harjoitetun mallin taustalla olevaa jakaumaa ja säätää sitä kohti suurempaa todennäköisyyttä tehdä positiivisia ennusteita. Korjauskeinona käytämme log-odds-korjausta [ ] palvelun aikana, varmistaen, että verkkomalli on puolueeton estimaattori alkuperäisestä jakaumasta. 19 Verkko-oppimisen aikana Monolith-harjoitteluklusteri vastaanottaa jatkuvasti tietoa verkko-palvelumoduulista ja päivittää parametreja harjoitus-PS:ssä. Ratkaiseva askel verkko-palvelu-PS:n hyödyntämiseksi näistä uusista harjoitetuista parametreista on päivitettyjen malliparametrien synkronointi. Tuotantoympäristössä kohtaamme useita haasteita: 2.2.3 Parametrien synkronointi. Verkko-palvelu-PS:n mallit eivät saa lopettaa palvelua päivityksen aikana. Tuotantomallimme ovat yleensä useita teratavuja kokoisia, ja kaikki parametrien korvaaminen vie aikaa. Olisi sietämätöntä pysäyttää verkko-PS mallin palvelusta päivitysprosessin aikana, ja päivitykset on tehtävä lennossa; Moniteratavun mallin siirtäminen kokonaisuudessaan harjoitus-PS:stä verkko-palvelu-PS:ään aiheuttaisi valtavaa painetta sekä verkon kaistanleveydelle että PS-muistille, koska se vaatisi kaksinkertaista mallikokoa muistia uusien mallien vastaanottamiseksi. Jotta verkko-oppiminen voisi skaalautua yritysskenaariomme kokoon, suunnittelimme Monolithiin kasvavan lennossa tapahtuvan säännöllisen parametrien synkronointimekanismin, joka perustuu useisiin huomattaviin ominaisuuksiimme: (1) Harvat parametrit dominoivat suositusmallien kokoa; (2) Lyhyellä aikavälillä vain pieni osa tunnuksista harjoitetaan ja niiden upotukset päivitetään; (3) Tiheät muuttujat liikkuvat paljon hitaammin kuin harvat upotukset. Tämä johtuu siitä, että momenttipohjaisissa optimoijissa tiheiden muuttujien momentin kertyminen voimistuu suositusharjoitusdatan valtavan koon vuoksi, kun taas vain harvat upotukset saavat päivityksiä yhdessä data-erässä. (1) ja (2) mahdollistavat harvojen päivitysten hyödyntämisen kaikissa ominaisuustunnuksissa. Monolithissa ylläpidämme kosketettujen avainten hajautusjoukkoa, joka edustaa tunnuksia, joiden upotuksia on harjoitettu viimeisimmän parametrien synkronoinnin jälkeen. Siirrämme pienen osan harvoista parametreista, joiden avaimet ovat kosketettujen avainten joukossa, minuutin välein harjoitus-PS:stä verkko-palvelu-PS:ään. Tämä suhteellisen pieni kasvittäisten parametripäivitysten paketti on kevyt verkkosiirrolle eikä aiheuta terävää muistipiikkiä synkronoinnin aikana. Hyödynnämme myös (3) vähentääksemme edelleen verkon I/O:ta ja muistin käyttöä asettamalla aggressiivisemman synkronointiaikataulun harvoille parametreille, samalla kun päivitämme tiheitä parametreja harvemmin. Tämä voi johtaa tilanteeseen, jossa palvelutut tiheät parametrit ovat suhteellisen vanhentunut versio verrattuna harvaan osaan. Tällainen epäjohdonmukaisuus voidaan kuitenkin hyväksyä syyn vuoksi, joka mainittiin kohdassa (3), koska havaittavaa menetystä ei ole havaittu. 2.3 Vikasietoisuus Tuotannossa olevana järjestelmänä Monolith on suunniteltu kyvyllä palauttaa PS vikaantumisen sattuessa. Yleinen valinta vikasietoisuuteen on mallin tilan säännöllinen kuvaaminen (snapshotting) ja palautuminen viimeisimmästä kuvasta, kun PS-vika havaitaan. Kuvaustiheyden valinnalla on kaksi merkittävää vaikutusta: (1) Mallin laatu. Intuitiivisesti mallin laatu kärsii vähemmän äskettäisen historian menetyksestä, kun kuvaustiheys kasvaa. (2) Laskentakustannus. Moniteratavun mallin kuvaaminen ei ole ilmaista. Se aiheuttaa suuria muistin kopiointeja ja levyn I/O:ta. Mallin laadun ja laskentakustannusten välisenä kompromissina Monolith ottaa kuvia kaikista harjoitus-PS:istä päivittäin. Vaikka PS menettää päivän päivitykset vikaantumisen sattuessa, havaitsemme, että suorituskyvyn heikkeneminen on siedettävää kokeidemme perusteella. Analysoimme PS-luotettavuuden vaikutusta seuraavassa osiossa. 3 ARVIOINTI Paremman ymmärryksen saamiseksi ehdottamamme suunnittelun tuomista hyödyistä ja kompromisseista suoritimme useita tuotantomittakaavaisia kokeita ja A/B-testejä live-palveluliikenteellä arvioidaksemme ja varmistaaksemme Monolithin eri näkökulmista. Pyrimme vastaamaan kokeillamme seuraaviin kysymyksiin: (1) Kuinka paljon voimme hyötyä törmäysvapaasta HashTable-rakenteesta? (2) Kuinka tärkeää reaaliaikainen verkko-oppiminen on? (3) Onko Monolithin parametrien synkronointisuunnittelu riittävän vankka suuressa tuotantoskenaariossa? Tässä osiossa esittelemme ensin kokeelliset asetuksemme ja keskustelemme sitten tuloksista ja havainnoistamme yksityiskohtaisesti. 3.1 Kokeelliset asetukset Kuten kohdassa kuvataan, Monolithin upotustaulut on toteutettu törmäysvapaina HashTable-rakenteina. Todistaaksemme tarpeen välttää törmäyksiä upotustauluissa ja kvantifioidaksemme törmäysvapaan toteutuksemme hyödyt, suoritimme kaksi kokeiluryhmää Movielens-tietojoukolla ja sisäisellä tuotantotietojoukolla: 3.1.1 Upotustaulu. 2.1 (1) ml-25m tietojoukko [ ]. Tämä on standardi julkinen elokuvaluokitustietojoukko, joka sisältää 25 miljoonaa luokitusta, johon liittyy noin 162 000 käyttäjää ja 62 000 elokuvaa. MovieLens 11 • . Alkuperäiset tunnisteet ovat luokituksia välillä Tunnisteiden esikäsittely 0,5–5,0, kun taas tuotannossa tehtävämme ovat enimmäkseen binääristen signaalien vastaanottamista käyttäjiltä. Simuloidaksemme paremmin tuotantomalle