ByteDancen monoliitissa: Älykkäämpiä, nopeampia sisältösyötteitä tehostava 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 perustuvat aikakriittiseen asiakaspalautteeseen, kuten lyhytvideoiden paremmuusjärjestykseen tai verkkomainoksiin. Huolimatta tuotantomittakaavassa olevien syväoppimiskehysten, kuten TensorFlow'n tai PyTorchin, yleismaailmallisesta käyttöönotosta, nämä yleiskäyttöiset kehykset eivät vastaa yritysten vaatimuksia suositusskenaarioissa useista syistä: toisaalta staattisiin parametreihin ja tiheisiin laskelmiin perustuvien järjestelmien säätäminen dynaamisilla ja harvoilla ominaisuuksilla tapahtuvaan suositukseen heikentää mallin laatua; toisaalta tällaiset kehykset on suunniteltu niin, että eräharjoitusvaihe ja palveluvaihe ovat täysin erillisiä, mikä estää mallia vuorovaikuttamasta asiakaspalautteen kanssa reaaliaikaisesti. Nämä ongelmat saivat meidät tarkastelemaan uudelleen perinteisiä lähestymistapoja ja tutkimaan radikaalisti erilaisia suunnitteluvalintoja. Tässä artikkelissa esittelemme 1:n, järjestelmän, joka on räätälöity verkkoharjoitteluun. Suunnittelumme on perustunut sovellustyökuormiemme ja tuotantoympäristömme havaintoihin, jotka poikkeavat merkittävästi muista suositusjärjestelmistä. Panoksemme ovat moninaiset: ensinnäkin olemme luoneet törmäysvapaan upotustaulun optimoinneilla, kuten vanhenevilla upotuksilla ja taajuussuodatuksella, pienentääksemme sen muistijalanjälkeä; toiseksi tarjoamme tuotantovalmiin verkkoharjoitteluarkkitehtuurin, jolla on korkea vikasietoisuus; lopuksi olemme osoittaneet, että järjestelmän luotettavuutta voidaan vaihtaa reaaliaikaiseen oppimiseen. Monolith on otettu menestyksekkäästi käyttöön BytePlus Recommend2 -tuotteessa. Monolith 1 JOHDANTO Viime vuosikymmen on todistanut suositustekniikoiden voimaa hyödyntävien yritysten nousukauden. Paremman asiakaskokemuksen tavoittelussa personoidun sisällön toimittaminen jokaiselle yksittäiselle käyttäjälle reaaliaikaisena vastauksena on yleinen tavoite näille liiketoimintasovelluksille. Tämän saavuttamiseksi käyttäjän viimeisintä vuorovaikutusta koskevia tietoja käytetään usein mallin harjoittamisen ensisijaisena syötteenä, koska ne kuvaavat parhaiten käyttäjäprofiilia ja ennustavat käyttäjän kiinnostuksen kohteita ja tulevia käyttäytymismalleja. Syväoppiminen on hallinnut suositusmalleja [ , , , , , ], koska valtava määrä käyttäjätietoa sopii luonnostaan massiivisesti datalähtöisiin neuroverkkomalleihin. Kuitenkin pyrkimykset hyödyntää syväoppimisen tehoa teollisuustason suositusjärjestelmissä kohtaavat jatkuvasti ongelmia, jotka johtuvat todellisen maailman käyttäjäkäyttäytymisestä peräisin olevien tietojen ainutlaatuisista ominaisuuksista. Nämä tiedot eroavat dramaattisesti tavanomaisista syväoppimisongelmista, kuten kielimallinnuksesta tai konenäöstä, kahdella tavalla: 5 6 10 12 20 21 (1) Ominaisuudet ovat enimmäkseen harvoja, luokittelevia ja dynaamisesti muuttuvia; (2) Harjoitusdatan taustalla oleva jakauma on epästationaarinen, eli käsiteajautuminen . Tällaiset erot ovat aiheuttaneet ainutlaatuisia haasteita suositusjärjestelmien parissa työskenteleville tutkijoille ja insinööreille. 1.1 Harvuus ja dynamiikka Suositustiedot sisältävät enimmäkseen harvoja luokittelevia ominaisuuksia, joista osa esiintyy harvoin. Yleinen tapa mapata ne korkeaulotteiseen upotusavaruuteen johtaisi useisiin ongelmiin: • Toisin kuin kielimalleissa, joissa sananosien määrä on rajallinen, käyttäjien ja paremmuusjärjestyksen kohteiden määrä on kertaluokkia suurempi. Tällainen valtava upotustaulu tuskin mahtuu yhden isännän muistiin; • Vielä pahempaa, 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 edustamaan upotustaulua. 1 17 Käytännössä monet järjestelmät käyttävät matalan törmäyksen hajautusta [ , ] muistin koon pienentämiseksi ja tunnusten kasvun sallimiseksi. Tämä perustuu yli-ideaaliseen oletukseen, että tunnukset upotustaulussa ovat jakautuneet tasaisesti esiintymistiheyden suhteen ja törmäykset ovat vaarattomia mallin laadulle. Valitettavasti tämä harvoin pitää paikkansa todellisen maailman suositusjärjestelmässä, jossa pieni ryhmä käyttäjiä tai kohteita esiintyy merkittävästi useammin. Upotustaulun koon orgaanisen kasvun myötä hajautusavainten törmäysten mahdollisuudet kasvavat ja johtavat mallin laadun heikkenemiseen 3 6 . Siksi tuotantomittakaavan suositusjärjestelmillä on luonnollinen tarve pystyä tallentamaan mahdollisimman monta ominaisuutta parametreihinsa ja samalla pystyä joustavasti säätämään hallinnoitavien käyttäjien ja kohteiden määrää. 1.2 Epästationaarinen jakauma Visuaaliset ja kielelliset kuviot kehittyvät tuskin vuosisadan aikaskaalassa, kun taas sama käyttäjä, joka on kiinnostunut yhdestä aiheesta, voi muuttaa intohimoaan seuraavassa minuutissa. Tämän seurauksena käyttäjätietojen taustalla oleva jakauma on epästationaarinen, ilmiö, jota kutsutaan yleisesti käsiteajautumiseksi . Intuitiivisesti tietoa viimeaikaisemmasta historiasta voi tehokkaimmin edistää käyttäjän käyttäytymisen muutoksen ennustamisessa. Käsiteajautumisen vaikutuksen lieventämiseksi palvelumallien on päivitettävä uutta asiakaspalautetta mahdollisimman reaaliaikaisesti, jotta ne heijastavat käyttäjän viimeisimpiä kiinnostuksen kohteita. Näiden erojen valossa ja tuotantomme ongelmien havainnoinnin perusteella suunnittelimme -järjestelmän, suuren mittakaavan suositusjärjestelmän näiden kipupisteiden ratkaisemiseksi. Teimme laajoja kokeita varmistaaksemme ja iteroimme suunnittelumme tuotantoympäristössä. Monolith pystyy Monolith (1) Tarjoamaan täyden ilmaisutehon harvoille ominaisuuksille suunnittelemalla törmäysvapaan hajautustaulun ja dynaamisen ominaisuuksien poistomekanismin; (2) Palauttamaan palvelupalautteen takaisin harjoitteluun reaaliaikaisesti verkkoharjoittelulla. Näiden arkkitehtonisten ominaisuuksien avulla Monolith päihittää jatkuvasti törmäyksiä käyttäviä järjestelmiä, joissa käytetään hajautustekniikoita, suunnilleen samalla muistinkäytöllä, ja saavuttaa huippuluokan reaaliaikaisen palvelun AUC:n ilman palvelimiemme laskentatehon liiallista kuormitusta. Loppuosa tästä paperista on jäsennelty seuraavasti. Selitämme ensin suunnittelun yksityiskohdat siitä, miten Monolith käsittelee olemassa olevia haasteita törmäysvapaalla hajautustaululla ja reaaliaikaisella harjoittelulla Luvussa 2. Kokeet ja tulokset esitetään Luvussa 3, yhdessä tuotantotestattujen johtopäätösten ja joidenkin keskustelujen kanssa aikakriittisyyden, luotettavuuden ja mallin laadun välisistä kompromisseista. Luku 4 tiivistää liittyvän työn ja vertaa sitä Monolithiin. Luku 5 päättää tämän työn. 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 laskelmien suorittamisesta graafin määritelmän mukaisesti, ja PS-koneet tallentavat parametreja ja päivittävät niitä Työntekijöiden laskemien gradienttien mukaisesti. P S 2). Suositusmalleissa parametrit luokitellaan kahteen osaan: tiheisiin ja harvoihin. Tiheät parametrit ovat painoja/muuttujia syvässä neuroverkossa, ja harvat parametrit viittaavat upotustauluihin, jotka vastaavat harvoja ominaisuuksia. Suunnittelussamme sekä tiheät että harvat parametrit ovat osa TensorFlow Graphia ja ne tallennetaan parametripalvelimiin. Samoin kuin TensorFlow'n Variable tiheille parametreille, olemme suunnitelleet joukon erittäin tehokkaita, törmäysvapaita ja joustavia HashTable-operaatioita harvoille parametreille. Täydentämään TensorFlow'n rajoituksia, jotka johtuvat harjoituksen ja päättelyn erottamisesta, Monolithin joustavasti skaalautuva verkkoharjoittelu on suunniteltu synkronoimaan parametrit tehokkaasti harjoitus-PS:stä verkkopalvelu-PS:iin lyhyin väliajoin, ja mallin vankkuustakuu tarjotaan vikasietomekanismin avulla. 2.1 Hajautustaulu Ensinnäkin harvan parametriesityksen suunnittelun periaate on välttää eri tunnusten tietojen pakkaamista samaan kiinteän kokoiseen upotukseen. Dynaamisen kokoisen upotustaulun simulointi valmiilla TensorFlow Variable -muuttujalla johtaa väistämättä tunnustörmäykseen, joka pahenee uusien tunnusten saapuessa ja taulun kasvaessa. Siksi sen sijaan, että rakentaisimme Variable-muuttujan päälle, kehitimme uuden avain-arvo-HashTable-rakenteen harvoille parametreillemme. HashTable-rakenteemme käyttää sisäisesti Cuckoo Hashmapia [ ], joka tukee uusien avainten lisäämistä ilman törmäystä olemassa oleviin. Cuckoo Hashing saavuttaa pahimmassa tapauksessa 𝑂 (1) aikakompleksisuuden haku- ja poisto-operaatioille, ja odotetun amortisoidun 𝑂 (1) ajan lisäyksille. Kuten kuvassa havainnollistetaan, se ylläpitää kahta taulua 𝑇0, 𝑇1 eri hajautusfunktioilla ℎ0 (𝑥), ℎ1 (𝑥), ja elementti tallennetaan jompaankumpaan niistä. Kun yritetään lisätä elementtiä 16 3 𝐴 tauluun 𝑇0, 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ämä prosessi toistuu, kunnes kaikki elementit vakiintuvat, tai uudelleenhajautus tapahtuu, kun lisäys juuttuu silmukkaan. Muistin koon pienentäminen on myös tärkeä näkökohta suunnittelussamme. Naivi lähestymistapa jokaisen uuden tunnuksen lisäämiseksi HashTableen tyhjentää muistin nopeasti. Havainnot todellisista tuotantomalleista johtivat kahteen johtopäätökseen: (1) Muutamankin 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äille harvinaisille tunnuksille vastaavat upotukset ovat ali-harjoiteltuja harjoitusdatan puutteen vuoksi, eikä malli pysty tekemään hyvää arviota niistä. Loppujen lopuksi nämä tunnukset eivät todennäköisesti vaikuta lopputulokseen, joten mallin laatu ei kärsi näiden vähäisten esiintymiskertojen omaavien tunnusten poistamisesta; (2) > Etäisestä historiasta peräisin olevat vanhentuneet tunnukset edistävät harvoin nykyistä mallia, koska niitä ei koskaan käytetä. Tämä voi johtua käyttäjästä, joka ei ole enää aktiivinen, tai lyhytvideosta, joka on vanhentunut. Näiden tunnusten upotusten tallentaminen ei voi auttaa mallia millään tavalla, paitsi tuhlaamalla PS-muistiamme. Näiden havaintojen perusteella olemme suunnitelleet useita ominaisuustunnusten suodatusheuristiikkoja tehokkaampaan HashTable-toteutukseen: (1) Tunnukset suodatetaan ennen niiden hyväksymistä upotustauluihin. Meillä on kaksi suodatusmenetelmää: Ensinnäkin suodatamme niiden esiintymiskertojen perusteella ennen kuin ne lisätään avaimiksi, missä esiintymiskertojen raja-arvo on säädettävä hyperparametri, joka vaihtelee jokaiselle mallille; Lisäksi käytämme todennäköisyyssuodatinta, joka auttaa vähentämään muistinkäyttöä; ![#Kuva 4: Streaming Engine.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Tunnukset aikaleimataan ja asetetaan vanhenemaan tietyn ajan kuluessa passiivisuuden jälkeen. Vanhenemisajan voi myös säätää jokaiselle upotustaululle, jotta voidaan erottaa ominaisuudet, joilla on erilainen herkkyys historialliselle tiedolle. Toteutuksessamme HashTable on toteutettu TensorFlow-resurssioperaationa. Samankaltaisesti kuin Variable-muuttujassa, haut ja päivitykset toteutetaan myös natiivina TensorFlow-operaatioina helpomman integroinnin ja paremman yhteensopivuuden takaamiseksi. 2.2 Verkkoharjoittelu Monolithissa harjoittelu jaetaan kahteen vaiheeseen (Kuva 1): (1) Eräharjoitusvaihe. Tämä vaihe toimii tavallisena TensorFlow-harjoituslooppina: Jokaisessa harjoitusaskeleessa harjoitustyöntekijä lukee minierän harjoitusesimerkkejä tallennustilasta, pyytää parametreja PS:ltä, laskee eteenpäin- ja taaksepäinajon ja lopuksi siirtää päivitetyt parametrit harjoitus-PS:lle. Hieman eroten muista yleisistä syväoppimistehtävistä, harjoitamme tietojoukkoamme vain yhden kierroksen ajan. Eräharjoittelu on hyödyllistä historiallisten tietojen harjoittamisessa, kun muokkaamme malliarkkitehtuuriamme ja harjoitamme mallia uudelleen; (2) Verkkoharjoitusvaihe. Kun malli on otettu käyttöön verkkopalvelussa, harjoittelu ei pysähdy, vaan siirtyy verkkoharjoitusvaiheeseen. Sen sijaan, että lukisi minierän esimerkkejä tallennustilasta, harjoitustyöntekijä käsittelee reaaliaikaisia tietoja lennossa ja päivittää harjoitus-PS:ää. Harjoitus-PS synkronoi säännöllisesti parametrinsa palvelu-PS:ään, mikä vaikuttaa käyttäjän puolella välittömästi. Tämä mahdollistaa mallimme vuorovaikutteisen mukautumisen käyttäjän palautteen mukaan reaaliajassa. Monolith on rakennettu kyvyllä vaihtaa saumattomasti eräharjoituksen ja verkkoharjoituksen välillä. Tämän mahdollistaa suoratoistomoottorimme suunnittelu, kuten kuvassa havainnollistetaan. 2.2.1 Streaming Engine. 4 Suunnittelussamme käytämme yhtä Kafka [ ] jonoa käyttäjien toimintojen kirjaamiseen (esim. klikkaa kohdetta tai tykkää kohteesta jne.) ja toista Kafka-jonoa ominaisuuksille. Moottorin ytimessä on Flink [ ] suoratoistotyö verkkoyhdistäjälle. Verkkoyhdistäjä yhdistää ominaisuudet käyttäjätoimintojen tunnisteisiin ja tuottaa harjoitusesimerkkejä, jotka kirjoitetaan sitten Kafka-jonoon. Harjoitusesimerkkien jonoa kuluttavat sekä verkkoharjoittelu että eräharjoittelu: 13 4 Verkkoharjoittelua varten harjoitustyöntekijä lukee tiedot suoraan Kafka-jonosta; Eräharjoittelua varten datan dumppaustyö dumppaa ensin tiedot HDFS:ään [ ]; Kun HDFS:n tiedot ovat kertyneet tietyn määrän, harjoitustyöntekijä noutaa tiedot 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 toimintaloki ja ominaisuudet virtaavat verkkoyhdistäjään (Kuva ilman takuuta aikajärjestyksestä. Siksi käytämme ainutlaatuista avainta jokaiselle pyynnölle, jotta käyttäjätoiminto ja ominaisuudet voidaan parittaa oikein. 2.2.2 Online Joiner. 5) Käyttäjätoimintojen viive voi myös olla ongelma. Esimerkiksi käyttäjä voi viettää useita päiviä ennen kuin hän päättää ostaa kohteen, jota hänelle esitettiin 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-tallennusta ominaisuuksien tallentamiseen, jotka odottavat tietyn ajan ylittäviä. Kun käyttäjätoimintoloki saapuu, se etsii ensin muistissa olevasta välimuistista ja sitten etsii avain-arvo-tallennusta, jos välimuistista puuttuu. Toinen todellisissa sovelluksissa esiintyvä ongelma on, että negatiivisten ja positiivisten esimerkkien jakauma on erittäin epätasainen, jolloin entisten määrä voi olla moninkertainen jälkimmäiseen verrattuna. Jotta positiiviset esimerkit eivät peittyisi negatiivisten alle, yleinen strategia on negatiivinen näytteenotto. Tämä muuttaa varmasti harjoitetun mallin taustalla olevaa jakaumaa, hienosäätäen sitä kohti suurempaa todennäköisyyttä tehdä positiivisia ennusteita. Korjaustoimenpiteenä käytämme log odds -korjausta [ ] palvelun aikana, varmistaen, että verkkokäyttöinen malli on harhaton estimaattori alkuperäisestä jakaumasta. 19 Verkkoharjoittelun aikana Monolithin harjoitusklusteri vastaanottaa jatkuvasti tietoja verkkopalvelumoduulista ja päivittää parametreja harjoitus-PS:ssä. Kriittinen vaihe, jotta verkkopalvelu-PS voi hyötyä näistä uudelleen harjoitetuista parametreista, on päivitettyjen malliparametrien synkronointi. Tuotantoympäristössä kohtaamme useita haasteita: 2.2.3 Parametrien synkronointi. Verkkopalvelu-PS:n mallit eivät saa lopettaa palvelemista päivityksen aikana. Tuotantomallimme ovat yleensä useita teratavuja kokoisia, ja sen seurauksena kaikkien parametrien korvaaminen vie jonkin aikaa. Olisi sietämätöntä lopettaa verkkopalvelu-PS:n mallin palveleminen päivitysprosessin aikana, ja päivitykset on tehtävä lennossa; Monen teratavun mallin kokonaisuutena siirtäminen harjoitus-PS:stä verkkopalvelu-PS:ään aiheuttaa valtavan paineen sekä verkko-kaistanleveydelle että PS:n muistille, koska se vaatii kaksinkertaisen mallikoon muistia uuden mallin vastaanottamiseksi. Jotta verkkoharjoittelu skaalautuisi yritysskenaariomme kokoon, suunnittelimme Monolithiin inkrementaalisen lennossa tapahtuvan ajoittaisen parametrien synkronointimekanismin, joka perustuu useisiin havaittaviin malliemme ominaisuuksiin: (1) Harvat parametrit hallitsevat 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ä liikemäärään perustuvissa optimointialgoritmeissa liikemäärän kertyminen tiheille muuttujille vahvistuu suositusharjoitusdatan valtavasta koosta, kun taas vain harvat upotukset saavat päivityksiä yhdessä dataerässä. (1) ja (2) antavat meille mahdollisuuden hyödyntää harvoja päivityksiä kaikissa ominaisuustunnuksissa. Monolithissa ylläpidämme kosketettujen avainten hajautettua joukkoa, joka edustaa tunnuksia, joiden upotuksia harjoitetaan viimeisimmän parametrien synkronoinnin jälkeen. Siirrämme harvojen parametrien osajoukkoa, joiden avaimet ovat kosketettujen avainten joukossa, minuutin aikavälillä harjoitus-PS:stä verkkopalvelu-PS:ään. Tämä suhteellisen pieni paketti inkrementaalisia parametripäivityksiä on kevyt verkkosiirrolle eikä aiheuta terävää muistinpiikkiä synkronoinnin aikana. Hyödynnämme myös (3) vähentääksemme edelleen verkon I/O:ta ja muistinkäyttöä asettamalla aggressiivisemman synkronointiaikataulun harvoille parametreille, samalla kun päivitämme tiheitä parametreja harvemmin. Tämä voi johtaa tilanteeseen, jossa palvelemamme tiheät parametrit ovat suhteellisen vanhentuneita verrattuna harvaan osaan. Tällainen epäjohdonmukaisuus on kuitenkin siedettävää edellä mainitun (3) kohdan vuoksi, koska merkittävää menetystä ei ole havaittu. 2.3 Vikasietoisuus Tuotannossa olevana järjestelmänä Monolith on suunniteltu siten, että se pystyy palauttamaan PS:n vikatilanteessa. Yleinen valinta vikasietoisuuteen on mallin tilan säännöllinen tilannekuvaus ja palauttaminen viimeisimmästä tilannekuvasta, kun PS-vika havaitaan. Tilannekuvan tiheydellä on kaksi merkittävää vaikutusta: (1) Mallin laatu. Intuitiivisesti mallin laatu kärsii vähemmän viimeaikaisen historian menetyksestä, kun tilannekuvan tiheyttä lisätään. (2) > Laskennallinen ylikuorma. Moniteratavun mallin tilannekuvan ottaminen ei ole ilmaista. Se aiheuttaa suuria muistikopiointeja ja levyn I/O:ta. Mallin laadun ja laskennallisen ylikuorman välisenä kompromissina Monolith ottaa tilannekuvan kaikista harjoitus-PS:istä päivittäin. Vaikka PS menettää yhden päivän päivitykset vikatilanteessa, havaitsemme, että suorituskyvyn heikkeneminen on siedettävää kokeidemme perusteella. Analysoimme PS:n luotettavuuden vaikutusta seuraavassa osiossa. 3 ARVIOINTI Jotta voisimme paremmin ymmärtää ehdotetun suunnittelumme tuomia etuja ja kompromisseja, olemme suorittaneet useita kokeita tuotantomittakaavassa ja A/B-testejä reaaliaikaisella liikenteellä arvioidaksemme ja varmistaaksemme Monolithin eri näkökulmista. Pyrimme vastaamaan seuraaviin kysymyksiin kokeillamme: (1) Kuinka paljon voimme hyötyä törmäysvapaasta HashTablesta? (2) Kuinka tärkeää reaaliaikainen verkkoharjoittelu on? (3) Onko Monolithin parametrien synkronointisuunnittelu riittävän vankka suuressa tuotantoympäristössä? Tässä osiossa esittelemme ensin kokeelliset asetukset ja keskustelemme sitten yksityiskohtaisesti tuloksista ja havainnoistamme. 3.1 Kokeelliset asetukset Kuten luvussa kuvataan, Monolithin upotustaulut on toteutettu törmäysvapaina HashTable-rakenteina. Todistaaksemme tarpeen välttää upotustaulujen törmäyksiä ja kvantifioidaksemme törmäysvapaan toteutuksemme hyötyjä, suoritimme kaksi koeryhmää Movielens-tietojoukolla ja sisäisellä tuotantotietojoukolla: 3.1.1 Upotustaulu. 2.1 (1) ml-25m -tietojoukko [ ]. Tämä on standardi julkinen tietojoukko elokuvaluokituksille, sisältäen 25 miljoonaa luokitusta, jotka liittyvät noin 162 000 käyttäjään ja 62 000 elokuvaan. 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äärisignaalien vastaanottamista käyttäjiltä. Simuloidaksemme paremmin tuotantomallejamme, muunnamme asteikkomaiset tunnisteet binäärisiksi tunn