Унутры ByteDance's Monolith: рухавік, які сілкуе разумнейшыя і хутчэйшыя стужкі змесціва

```html Аўтары: Чжуаран Лю, Bytedance Inc. Лэцы Цзоу, Bytedance Inc. Сюань Цзоу, Bytedance Inc. Цайхуа Ван, Bytedance Inc. Бяо Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Балін Чжу*, Fudan University Іцзе Чжу, Bytedance Inc. Пэн Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Ёўлун Чэн†, Bytedance Inc. (youlong.cheng@bytedance.com) РЭЗЮМЭ Стварэнне маштабаванай сістэмы рэкамендацый у рэжыме рэальнага часу з'яўляецца жыццёва важным для многіх бізнесаў, якія кіруюцца адчувальнымі да часу водгукамі кліентаў, такімі як рэйтынг кароткіх відэа ці онлайн-рэклама. Нягледзячы на шырокае распаўсюджванне вытворчых фрэймворкаў глыбокага навучання, такіх як Ten-sorFlow або PyTorch, гэтыя фрэймворкі агульнага прызначэння не адпавядаюць бізнес-патрабаванням у сцэнарыях рэкамендацый з розных прычын: з аднаго боку, наладка сістэм на аснове статычных параметраў і шчыльных вылічэнняў для рэкамендацый з дынамічнымі і sparse-характарыстыкамі шкодзіць якасці мадэлі; з іншага боку, такія фрэймворкі распрацаваны з цалкам асобнымі этапамі пакетнага навучання і абслугоўвання, што перашкаджае мадэлі ўзаемадзейнічаць з водгукамі кліентаў у рэжыме рэальнага часу. Гэтыя праблемы прымусілі нас перагледзець традыцыйныя падыходы і вывучыць радыкальна іншыя выбары дызайну. У гэтым артыкуле мы прадстаўляем 1, сістэму, спецыяльна прызначаную для онлайн-навучання. Наш дызайн быў абумоўлены назіраннямі за нашымі працоўнымі нагрузкамі прыкладанняў і вытворчым асяроддзем, якія адлюстроўваюць значнае адхіленне ад іншых сістэм рэкамендацый. Наш уклад шматлікі: па-першае, мы стварылі табліцу ўбудавання без сутыкненняў з аптымізацыямі, такімі як прамежкавыя ўбудаванні і фільтраванне па частоце, каб паменшыць яе патрабаванне да памяці; па-другое, мы прадастаўляем гатовую да вытворчасці архітэктуру онлайн-навучання з высокай адмоваўстойлівасцю; нарэшце, мы даказалі, што надзейнасць сістэмы можа быць прынесена ў ахвяру дзеля навучання ў рэжыме рэальнага часу. Monolith быў паспяхова ўкаранёны ў прадукт BytePlus Recommend2. Monolith 1 УВОДЗІНЫ Апошняе дзесяцігоддзе стала сведкам буму бізнесу, які выкарыстоўвае метады рэкамендацый. У імкненні да лепшага кліенцкага досведу, забеспячэнне персаналізаванага кантэнту для кожнага асобнага карыстальніка ў якасці адказу ў рэжыме рэальнага часу з'яўляецца агульнай мэтай гэтых бізнес-прыкладанняў. Для гэтага інфармацыя з апошняга ўзаемадзеяння карыстальніка часта выкарыстоўваецца ў якасці асноўнага ўваходу для навучання мадэлі, паколькі яна найлепш адлюстроўвае партрэт карыстальніка і дазваляе прагназаваць цікавасць і будучую паводзіну карыстальніка. Глыбокае навучанне дамінуе ў мадэлях рэкамендацый [ , , , , , ], паколькі велізарны аб'ём даных карыстальнікаў добра падыходзіць для масавых, заснаваных на даных нейронных мадэляў. Аднак намаганні па выкарыстанні магутнасці глыбокага навучання ў рэкамендацыйных сістэмах прамысловага ўзроўню пастаянна сутыкаюцца з праблемамі, якія ўзнікаюць з-за унікальных характарыстык даных, атрыманых з паводзін карыстальнікаў у рэальным свеце. Гэтыя даныя кардынальна адрозніваюцца ад тых, што выкарыстоўваюцца ў звычайных праблемах глыбокага навучання, такіх як мадэляванне мовы ці камп'ютарнае зрок, у двух аспектах: 5 6 10 12 20 21 (1) Характарыстыкі ў асноўным sparse, катэгарыйныя і дынамічна змяняюцца; (2) Асноўнае размеркаванне навучальных даных нестацыянарнае, вядомае як канцэптуальны дрэйф [8]. Такія адрозненні стварылі унікальныя праблемы для даследчыкаў і інжынераў, якія працуюць над рэкамендацыйнымі сістэмамі. 1.1 Sparse і дынамізм Даныя для рэкамендацый у асноўным утрымліваюць sparse катэгарыяльныя характарыстыкі, некаторыя з якіх сустракаюцца з нізкай частатой. Звычайная практыка адлюстравання іх у высокавымяральнай прасторы убудавання прывядзе да шэрагу праблем: • У адрозненне ад моўных мадэляў, дзе колькасць слоў абмежаваная, колькасць карыстальнікаў і прадметаў для рэйтынгу значна большая. Такая велізарная табліца убудавання з цяжкасцю змясціцца ў памяць аднаго хоста; • Што яшчэ горш, чакаецца, што памер табліцы убудавання будзе расці з часам, калі будзе дадавацца больш карыстальнікаў і прадметаў, у той час як фрэймворкі, такія як [ , ], выкарыстоўваюць шчыльныя зменныя фіксаванага памеру для прадстаўлення табліцы убудавання. 1 17 На практыцы многія сістэмы выкарыстоўваюць хешаванне з нізкім узроўнем сутыкненняў [ , ] для памяншэння патрабаванняў да памяці і дазволу росту ідэнтыфікатараў. Гэта грунтуецца на занадта ідэалістычным здагадцы, што ідэнтыфікатары ў табліцы убудавання размеркаваны раўнамерна па частаце, і сутыкненні не шкодзяць якасці мадэлі. На жаль, гэта рэдка бывае праўдай для рэальнай сістэмы рэкамендацый, дзе невялікая група карыстальнікаў або прадметаў мае значна больш супадзенняў. З арганічным ростам памеру табліцы убудавання шансы сутыкнення хеш-ключоў павялічваюцца і прыводзяць да пагаршэння якасці мадэлі 3 6 [3]. Такім чынам, існуе натуральны попыт на прамысловыя рэкамендацыйныя сістэмы, якія маглі б захопліваць максімальна магчымыя характарыстыкі ў сваіх параметрах, а таксама мелі б здольнасць эластычна рэгуляваць колькасць карыстальнікаў і прадметаў, якія яны імкнуцца весці. 1.2 Нестацыянарнае размеркаванне Візуальныя і моўныя шаблоны ледзь развіваюцца на працягу стагоддзяў, у той час як адзін і той жа карыстальнік, які цікавіцца адной тэмай, можа змяніць свой энтузіязм кожную наступную хвіліну. У выніку асноўнае размеркаванне даных карыстальнікаў нестацыянарнае, што з'яўляецца з'явай, звычайна называнай канцэптуальным дрэйфам [8]. Інтуітыўна, інфармацыя з больш нядаўняй гісторыі можа больш эфектыўна спрыяць прагназаванню змены паводзін карыстальніка. Каб змякчыць эфект канцэптуальнага дрэйфу, мадэлі абслугоўвання павінны абнаўляцца з новых водгукаў карыстальнікаў як мага бліжэй да рэжыму рэальнага часу, каб адлюстраваць апошнія інтарэсы карыстальніка. У святле гэтых адрозненняў і назіраючы за праблемамі, якія ўзнікаюць у нашай вытворчасці, мы распрацавалі , маштабаваную сістэму рэкамендацый для вырашэння гэтых праблем. Мы правялі шырокія эксперыменты для праверкі і ітэрацыі нашага дызайну ў вытворчым асяроддзі. Monolith здольны Monolith (1) Забяспечыць поўную выразную моц для sparse характарыстык шляхам распрацоўкі хеш-табліцы без сутыкненняў і механізму эвакуацыі дынамічных характарыстык; (2) Замыкаць зваротную сувязь аб абслугоўванні на навучанне ў рэжыме рэальнага часу з дапамогай анлайн-навучання. Дзякуючы гэтым архітэктурным магчымасцям, Monolith стабільна пераўзыходзіць сістэмы, якія выкарыстоўваюць хеш-прыёмы з сутыкненнямі пры прыблізна аднолькавым выкарыстанні памяці, і дасягае найноўшага AUC анлайн-абслугоўвання, не перагружаючы вылічальную магутнасць нашых сервераў. Астатняя частка артыкула арганізавана наступным чынам. Спачатку мы падрабязна апісваем дэталі дызайну таго, як Monolith вырашае існуючыя праблемы з дапамогай хеш-табліцы без сутыкненняў і навучання ў рэжыме рэальнага часу ў раздзеле 2. Эксперыменты і вынікі будуць прадстаўлены ў раздзеле 3, разам з высновамі, праверанымі на практыцы, і некаторымі абмеркаваннямі праблем супастаўлення паміж адчувальнасцю да часу, надзейнасцю і якасцю мадэлі. У раздзеле 4 абагульняецца звязаная праца і параўноўваецца з Monolith. У раздзеле 5 заключаецца гэтая праца. 2 ДЫЗАЙН Агульная архітэктура Monolith у асноўным адпавядае размеркаванай наладзе Worker- arameter erver TensorFlow (Малюнак У архітэктуры Worker-PS машыны выконваюць розныя ролі; Worker-машыны адказваюць за выкананне вылічэнняў, вызначаных графікам, а PS-машыны захоўваюць параметры і абнаўляюць іх у адпаведнасці з градыентамі, разлічанымі Workers. P S 2). У рэкамендацыйных мадэлях параметры класіфікуюцца на дзве групы: шчыльныя і sparse. Шчыльныя параметры - гэта вагі/зменныя ў глыбокай нейроннай сетцы, а sparse параметры адносяцца да табліц убудавання, якія адпавядаюць sparse характарыстыкам. У нашым дызайне як шчыльныя, так і sparse параметры з'яўляюцца часткай графіка TensorFlow і захоўваюцца на серверы параметраў. Падобна да зменнай TensorFlow для шчыльных параметраў, мы распрацавалі набор высокаэфектыўных, без сутыкненняў і гнуткіх аперацый HashTable для sparse параметраў. У якасці дадатку да абмежаванняў TensorFlow, якія ўзнікаюць з-за падзелу навучання і вываду, эластычна маштабаванае анлайн-навучанне Monolith прызначана для эфектыўнай сінхранізацыі параметраў ад навучальнага PS да анлайн-абслуговага PS у кароткія прамежкі часу, з гарантыяй надзейнасці мадэлі, якая забяспечваецца механізмам адмоваўстойлівасці. 2.1 Хеш-табліца Першым прынцыпам у нашым дызайне sparse прадстаўлення параметраў з'яўляецца пазбяганне аб'яднання інфармацыі ад розных ідэнтыфікатараў у адно і тое ж убудаванне фіксаванага памеру. Сімуляцыя дынамічнай па памеры табліцы убудавання з стандартнай зменнай TensorFlow непазбежна прыводзіць да сутыкнення ідэнтыфікатараў, якое ўзмацняецца па меры паступлення новых ідэнтыфікатараў і росту табліцы. Таму, замест таго, каб будаваць на аснове зменнай, мы распрацавалі новую хеш-табліцу ключ-значэнне для нашых sparse параметраў. Наша HashTable выкарыстоўвае Cuckoo Hashmap [ ] у аснове, якая падтрымлівае ўстаўку новых ключоў без сутыкнення з існуючымі. Cuckoo Hashing дасягае найгоршага выпадку 𝑂 (1) часу для пошукаў і выдаленняў, і чаканага амартызаванага 𝑂 (1) часу для вставак. Як паказана на Малюнку , яна падтрымлівае дзве табліцы 𝑇0, 𝑇1 з рознымі функцыямі хешавання ℎ0 (𝑥), ℎ1 (𝑥), і элемент будзе захоўвацца ў адной з іх. Пры спробе ўстаўкі элемента 16 3 𝐴 у 𝑇0, спачатку робіцца спроба размясціць 𝐴 у ℎ0 (𝐴); калі ℎ0 (𝐴) заняты іншым элементам 𝐵, ён выцясняе 𝐵 з 𝑇0 і спрабуе ўставіць 𝐵 у 𝑇1 па той жа логіцы. Гэты працэс будзе паўтарацца да таго часу, пакуль усе элементы не стабілізуюцца, альбо адбудзецца перахешаванне, калі ўстаўка прывядзе да цыклу. Змяншэнне патрабаванняў да памяці таксама з'яўляецца важнай задачай у нашым дызайне. Наіўны падыход да ўстаўкі кожнага новага ідэнтыфікатара ў HashTable хутка вычарпае памяць. Назіранне за рэальнымі вытворчымі мадэлямі прыводзіць да двух высноў: (1) Ідэнтыфікатары, якія сустракаюцца толькі некалькі разоў, маюць абмежаваны ўклад у паляпшэнне якасці мадэлі. Важным назіраннем з'яўляецца тое, што ідэнтыфікатары размеркаваны па доўгім хвасце, дзе папулярныя ідэнтыфікатары могуць сустракацца мільёны разоў, у той час як непапулярныя сустракаюцца не больш за дзесяць разоў. Убудаванні, якія адпавядаюць гэтым рэдкім ідэнтыфікатарам, недавучаны з-за недахопу навучальных даных, і мадэль не зможа зрабіць добрае ацэньванне на іх аснове. У рэшце рэшт, гэтыя ідэнтыфікатары, хутчэй за ўсё, не паўплываюць на вынік, таму якасць мадэлі не пацярпіць ад выдалення гэтых ідэнтыфікатараў з нізкай частатой; (2) Старыя ідэнтыфікатары з далёкага мінулага рэдка спрыяюць бягучай мадэлі, паколькі многія з іх ніколі не наведваюцца. Гэта можа быць звязана з карыстальнікам, які больш не актыўны, або кароткім відэа, якое састарэла. Захоўванне убудаванняў для гэтых ідэнтыфікатараў ніяк не дапаможа мадэлі, акрамя як дарма выдаткоўваць нашу памяць PS. На аснове гэтых назіранняў мы распрацавалі некалькі эўрыстычных фільтраў ідэнтыфікатараў характарыстык для больш эфектыўнага выкарыстання памяці ў рэалізацыі HashTable: (1) Ідэнтыфікатары фільтруюцца перад тым, як яны будуць дапушчаны ў табліцы убудавання. У нас ёсць два метады фільтравання: спачатку мы фільтруем па іх супадзеннях перад тым, як яны будуць устаўлены ў якасці ключоў, дзе парог супадзенняў з'яўляецца наладжвальным гіперпараметрам, які адрозніваецца для кожнай мадэлі; Дадаткова мы выкарыстоўваем імавернасны фільтр, які дапамагае дадаткова знізіць выкарыстанне памяці; ![#Figure 4: Streaming Engine. Петля зваротнай сувязі інфармацыі ад [Карыстальнік → Сервер мадэлі → Навучальны Worker → Сервер мадэлі → Карыстальнік] будзе займаць шмат часу пры выкарыстанні шляху пакетнага навучання, у той час як анлайн-навучанне будзе замыкаць пятлю больш імгненна.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Ідэнтыфікатары маркіруюцца і ўсталёўваюцца для заканчэння тэрміну дзеяння пасля перыяду неактыўнасці на працягу вызначанага перыяду часу. Тэрмін дзеяння таксама наладжваецца для кожнай табліцы убудавання, каб дазволіць адрозніваць характарыстыкі з рознай адчувальнасцю да гістарычнай інфармацыі. У нашай рэалізацыі HashTable рэалізавана як рэсурсная аперацыя TensorFlow. Падобна да зменнай, пошукі і абнаўленні таксама рэалізаваны як натыўныя аперацыі TensorFlow для палягчэння інтэграцыі і палепшанай сумяшчальнасці. 2.2 Анлайн-навучанне У Monolith навучанне падзелена на два этапы (Малюнак 1): (1) Этап пакетнага навучання. Гэты этап працуе як звычайны цыкл навучання TensorFlow: на кожным этапе навучання навучальны worker чытае адзін міні-бач навучальных прыкладаў з сховішча, запытвае параметры ад PS, выконвае прамы і зваротны праход, і нарэшце адпраўляе абноўленыя параметры ў навучальны PS. Крыху адрозніваецца ад іншых распаўсюджаных задач глыбокага навучання, мы навучаем наш набор даных толькі адзін раз. Пакетнае навучанне карысна для навучання гістарычных даных пры змене архітэктуры нашай мадэлі і пераналадцы мадэлі; (2) Этап анлайн-навучання. Пасля разгортвання мадэлі для анлайн-абслугоўвання, навучанне не спыняецца, а пераходзіць у этап анлайн-навучання. Замест чытання міні-бачаў прыкладаў са сховішча, навучальны worker спажывае даныя ў рэжыме рэальнага часу на ляту і абнаўляе навучальны PS. Навучальны PS перыядычна сінхранізуе свае параметры з абслугоўваючым PS, што неадкладна ўступае ў сілу для карыстальніка. Гэта дазваляе нашай мадэлі інтэрактыўна адаптавацца ў адпаведнасці з водгукамі карыстальніка ў рэжыме рэальнага часу. Monolith створаны з магчымасцю бесперапыўнага пераключэння паміж пакетным і анлайн-навучаннем. Гэта ажыццяўляецца дзякуючы нашаму дызайну струменевага рухавіка, як паказана на Малюнку 2.2.1 Струменевы рухавік. 4. У нашым дызайне мы выкарыстоўваем адну чаргу Kafka [ ] для рэгістрацыі дзеянняў карыстальнікаў (напрыклад, націск на элемент або лайк элемента і г.д.) і другую чаргу Kafka для характарыстык. У аснове рухавіка ляжыць струменевая праца Flink [ ] для анлайн-злучэння характарыстык. Анлайн-злучэнне аб'ядноўвае характарыстыкі з меткамі з дзеянняў карыстальнікаў і стварае навучальныя прыклады, якія затым запісваюцца ў чаргу Kafka. Чаргу для навучальных прыкладаў спажываюць як анлайн-, так і пакетнае навучанне: 13 4 Для анлайн-навучання навучальны worker непасрэдна чытае даныя з чаргі Kafka; Для пакетнага навучання праца па выгрузцы даных спачатку выгружае даныя ў HDFS [ ]; пасля назапашвання пэўнай колькасці даных у HDFS, навучальны worker атрымлівае даныя з HDFS і выконвае пакетнае навучанне. 18 Абноўленыя параметры ў навучальным PS будуць адпраўлены ў абслугоўваючы PS у адпаведнасці з раскладам сінхранізацыі параметраў. У рэальных прыкладаннях, часопісы дзеянняў карыстальнікаў і характарыстыкі перадаюцца ў анлайн-злучэнне (Малюнак без гарантыі парадку часу. Таму мы выкарыстоўваем унікальны ключ для кожнага запыту, каб дзеянне карыстальніка і характарыстыкі маглі правільна спалучыцца. 2.2.2 Анлайн-злучэнне. 5) Затрымка дзеянняў карыстальніка таксама можа быць праблемай. Напрыклад, карыстальнік можа прыняць некалькі дзён, перш чым вырашыць купіць тавар, які быў яму прадстаўлены некалькі дзён таму. Гэта праблема для злучэння, таму што калі ўсе характарыстыкі захоўваюцца ў кэшы, яны проста не змесціцца ў памяць. У нашай сістэме выкарыстоўваецца дыскавая сістэма захоўвання ключ-значэнне для захоўвання характарыстык, якія чакаюць больш за пэўны перыяд часу. Калі паступае часопіс дзеянняў карыстальніка, ён спачатку шукае ў кэшы памяці, а затым шукае ў сістэме захоўвання ключ-значэнне ў выпадку адсутнасці кэшу. Яшчэ адна праблема, якая ўзнікае ў рэальных прыкладаннях, заключаецца ў тым, што размеркаванне адмоўных і станоўчых прыкладаў вельмі нераўнамернае, дзе колькасць першых можа быць на парадак вышэйшая за другія. Каб прадухіліць перагрузку станоўчых прыкладаў адмоўнымі, распаўсюджанай стратэгіяй з'яўляецца адмоўнае ўзорыраванне. Гэта, безумоўна, зменіць асноўнае размеркаванне навучанай мадэлі, наладзіўшы яе на больш высокую верагоднасць станоўчых прагназаванняў. У якасці сродку кампенсацыі мы прымяняем карэкцыю логарыфмічных шанцаў [ ] падчас абслугоўвання, гарантуючы, што анлайн-мадэль з'яўляецца непрадузятым ацэншчыкам арыгінальнага размеркавання. 19 Падчас анлайн-навучання навучальны кластар Monolith працягвае атрымліваць даныя ад модуля анлайн-абслугоўвання і абнаўляць параметры на навучальным PS. Важным крокам для таго, каб навучальны PS атрымаў выгаду ад гэтых нядаўна навучаных параметраў, з'яўляецца сінхранізацыя абноўленых параметраў мадэлі. У вытворчым асяроддзі мы сутыкаемся з некалькімі праблемамі: 2.2.3 Сінхранізацыя параметраў. Мадэлі на анлайн-абслугоўваючым PS не павінны спыняць абслугоўванне падчас абнаўлення. Нашы мадэлі ў вытворчасці звычайна маюць памер некалькіх тэрабайт, і ў выніку замена ўсіх параметраў займае некаторы час. Было б недапушчальна спыняць анлайн-PS ад абслугоўвання мадэлі падчас працэсу замены, і абнаўленні павінны адбывацца на ляту; Перадача мультытэрабайтавай мадэлі ў поўным аб'ёме ад навучальнага PS да анлайн-абслуговага PS стварыла б велізарны ціск як на прапускную здольнасць сеткі, так і на памяць на PS, паколькі для прыняцця новай мадэлі патрабуецца падвойны памер памяці мадэлі. Каб анлайн-навучанне магло маштабавацца да памеру нашага бізнес-сцэнарыя, мы распрацавалі інкрыментны механізм перыядычнай сінхранізацыі параметраў на ляту ў Monolith, заснаваны на некалькіх прыкметных характарыстыках нашых мадэляў: (1) Sparse параметры дамінуюць над памерам рэкамендацыйных мадэляў; (2) Улічваючы кароткі прамежак часу, толькі невялікая падмноства ідэнтыфікатараў навучаецца і іх убудаванні абнаўляюцца; (3) Шчыльныя зменныя рухаюцца значна павольней, чым sparse убудаванні. Гэта адбываецца таму, што ў аптымізатарах на аснове імпульсу, назапашванне імпульсу для шчыльных зменных павялічваецца велізарным памерам даных для навучання рэкамендацый, у той час як толькі некалькі sparse убудаванняў атрымліваюць абнаўленні ў адным бачце даных. (1) і (2) дазваляюць нам выкарыстоўваць sparse абнаўленні па ўсіх ідэнтыфікатарах характарыстык. У Monolith мы падтрымліваем набор sparse ключоў, якія дакрануліся, прадстаўляючы ідэнтыфікатары, чые убудаванні былі навучаны з моманту апошняй сінхранізацыі параметраў. Мы адпраўляем падмноства sparse параметраў, чые ключы знаходзяцца ў наборы дакранутых ключоў, з інтэрвалам у хвіліну ад навучальнага PS да анлайн-абслуговага PS. Гэты адносна невялікі пакет інкрыментных абнаўленняў параметраў лёгкі для перадачы па сетцы і не выклікае рэзкага павышэння памяці падчас сінхранізацыі. Мы таксама выкарыстоўваем (3), каб дадаткова знізіць сеткавую перадачу даных і выкарыстанне памяці, усталяваўшы больш агрэсіўны графік сінхранізацыі для sparse параметраў, абнаўляючы шчыльныя параметры радзей. Гэта можа прывесці да сітуацыі, калі шчыльныя параметры, якія мы абслугоўваем, з'яўляюцца адносна састарэлай версіяй у параўнанні з sparse часткай. Аднак такая не