Во внатрешноста на ByteDance Monolith: Моторот што ги напојува попаметните, побрзи федови со содржина

Автори: Жуоран Лиу, Bytedance Inc. Леки Зоу, Bytedance Inc. Сјуан Зоу, Bytedance Inc. Каихуа Ванг, Bytedance Inc. Биао Жанг, Bytedance Inc. Да Танг, Bytedance Inc. Болин Жу∗, Универзитет Фудан Јије Жу, Bytedance Inc. Пенг Ву, Bytedance Inc. Ке Ванг, Bytedance Inc. Јулонг Ченг†, Bytedance Inc. (youlong.cheng@bytedance.com) АПСТРАКТ Изградбата на скалабилен систем за препораки во реално време е од витално значење за многу бизниси кои се потпираат на временски чувствителни повратни информации од клиентите, како што се рангирање на кратки видеа или онлајн реклами. И покрај сеприсутната употреба на продукциски рамки за длабоко учење како TensorFlow или PyTorch, овие рамки за општа намена не ги задоволуваат бизнис барањата во сценаријата за препораки од различни причини: од една страна, прилагодувањето на системите врз основа на статични параметри и густи пресметки за препорака со динамични и ретки карактеристики е штетно за квалитетот на моделот; од друга страна, таквите рамки се дизајнирани со целосно одделена фаза на групно тренирање и фаза на сервирање, спречувајќи го моделот да комуницира со повратните информации од клиентите во реално време. Овие проблеми нè наведоа да ги преиспитаме традиционалните пристапи и да истражиме радикално различни избори во дизајнот. Во овој труд, го претставуваме 1, систем прилагоден за онлајн тренирање. Нашиот дизајн е поттикнат од набљудувањата на нашите работни оптоварувања на апликациите и продукциското опкружување кое одразува забележливо отстапување од другите системи за препораки. Нашите придонеси се повеќекратни: прво, создадовме табела со вградувања без судири со оптимизации како што се истекувачки вградувања и филтрирање по фреквенција за да го намалиме нејзиниот мемориски отпечаток; второ, обезбедуваме продукциска архитектура за онлајн тренирање со висока толеранција на грешки; конечно, докажавме дека доверливоста на системот може да се менува за учење во реално време. Monolith успешно е имплементиран во производот BytePlus Recommend2. Monolith 1 ВОВЕД Изминатата деценија забележа бум на бизниси поттикнати од техниките за препораки. Во потрага по подобра корисничка услуга, испораката на персонализирана содржина за секој поединечен корисник како одговор во реално време е заедничка цел на овие деловни апликации. За таа цел, информациите од најновата интеракција на корисникот често се користат како примарен влез за тренирање на модел, бидејќи најдобро го прикажува портретот на корисникот и ги предвидува интересите и идното однесување на корисникот. Длабокото учење доминира во моделите за препораки [ , , , , , ] бидејќи огромната количина на податоци од корисникот е природен натпревар за масивно податочно-ориентирани невронски модели. Сепак, напорите за искористување на моќта на длабокото учење во индустриски препорачани системи постојано се соочуваат со проблеми што произлегуваат од уникатните карактеристики на податоците добиени од реалното однесување на корисниците. Овие податоци драстично се разликуваат од оние што се користат во конвенционалните проблеми со длабоко учење како моделирање на јазик или компјутерски вид во два аспекти: 5 6 10 12 20 21 (1) Карактеристиките се претежно ретки, категорични и динамично се менуваат; (2) Основната дистрибуција на податоците за тренирање е нестационарна, т.н. Концептен дрифт . Ваквите разлики поставија уникатни предизвици за истражувачите и инженерите кои работат на системи за препораки. 1.1 Редкост и динамика Податоците за препораки претежно содржат ретки категорични карактеристики, од кои некои се појавуваат со мала фреквенција. Вообичаената пракса на нивно мапирање во високодимензионален простор за вградување би предизвикала низа проблеми: • За разлика од моделите на јазикот каде бројот на зборни парчиња е ограничен, бројот на корисници и ставки за рангирање е многу поголем. Таквата огромна табела за вградување тешко дека ќе се вклопи во меморијата на еден домаќин; • Уште полошо, големината на табелата за вградување се очекува да расте со текот на времето како што се примаат повеќе корисници и ставки, додека рамките како [ , ] користат густи променливи со фиксна големина за да ја претстават табелата за вградување. 1 17 Во пракса, многу системи усвојуваат хеширање со низок судир [ , ] како начин за намалување на меморискиот отпечаток и за овозможување растење на ID-ата. Ова се потпира на претерано идеалистичка претпоставка дека ID-ата во табелата за вградување се рамномерно распределени по фреквенција, и судирите се безопасни за квалитетот на моделот. За жал, ова ретко е вистина за систем за препораки од реалниот свет, каде мал број корисници или ставки имаат значително повеќе појавувања. Со органскиот раст на големината на табелата за вградување, шансите за судир на хеш-клуч се зголемуваат и доведуваат до влошување на квалитетот на моделот 3 6 . Затоа, природна потреба за продукциски системи за препораки е да имаат капацитет да ги фатат што е можно повеќе карактеристики во нивните параметри, а исто така да имаат можност еластично да го прилагодат бројот на корисници и ставки што се обидуваат да ги евидентираат. 1.2 Нестационарна дистрибуција Визуелните и јазичните обрасци едвај се развиваат во временски период од векови, додека истиот корисник заинтересиран за една тема може да го промени својот ентузијазам секоја следна минута. Како резултат на тоа, основната дистрибуција на податоците од корисниците е нестационарна, феномен кој вообичаено се нарекува Концептен дрифт . Интуитивно, информациите од поновата историја можат поефективно да придонесат за предвидување на промената во однесувањето на корисникот. За да се ублажи ефектот на Концептниот дрифт, моделите за сервирање треба да се ажурираат од новите повратни информации од корисниците што е можно поблиску до реално време за да го одразат најновиот интерес на корисникот. Имајќи ги предвид овие разлики и набљудувајќи ги проблемите што произлегуваат од нашето производство, го дизајниравме , скалабилен систем за препораки за да ги реши овие болни точки. Спроведовме обемни експерименти за да го потврдиме и итерираме нашиот дизајн во продукциската средина. Monolith е способен да Monolith (1) Обезбеди целосна експресивна моќ за ретки карактеристики со дизајнирање хеш-табела без судири и механизам за динамично исфрлање на карактеристиките; (2) Да го врати повратниот сигнал од сервирањето во тренирање во реално време со онлајн тренирање. Овозможен со овие архитектонски капацитети, Monolith постојано ги надминува системите што усвојуваат хеш-трикови со судири со приближно слично користење на меморијата, и постигнува најсовремена онлајн AUC при сервирање без прекумерно оптеретување на пресметковната моќ на нашите сервери. Остатокот од статијата е организиран на следниов начин. Прво ги разработуваме деталите за дизајнот за тоа како Monolith се справува со постоечките предизвици со хеш-табела без судири и тренирање во реално време во Секција 2. Експериментите и резултатите ќе бидат претставени во Секција 3, заедно со заклучоци тестирани во продукција и некои дискусии за компромисите помеѓу временската чувствителност, доверливоста и квалитетот на моделот. Секција 4 ги сумира поврзаните трудови и ги споредува со Monolith. Секција 5 го заклучува ова дело. 2 ДИЗАЈН Целокупната архитектура на Monolith генерално го следи поставувањето Worker- arameter erver на TensorFlow (Слика Во архитектурата Worker-PS, машините се доделени со различни улоги; Worker машините се одговорни за извршување на пресметките дефинирани со графикот, а PS машините ги чуваат параметрите и ги ажурираат според градиентите пресметани од Workers. P S 2). Во моделите за препораки, параметрите се категоризираат во два сета: густи и ретки. Густите параметри се тежини/променливи во длабока невронска мрежа, а ретките параметри се однесуваат на табели за вградување што соодветствуваат на ретки карактеристики. Во нашиот дизајн, и густите и ретките параметри се дел од TensorFlow Graph, и се чуваат на параметар серверите. Слично на Variable на TensorFlow за густи параметри, дизајниравме сет на високо-ефикасни, хеш-табли без судири и флексибилни операции за ретки параметри. Како дополнение на ограничувањата на TensorFlow што произлегуваат од одвојувањето на тренирањето и инференцијата, еластично скалабилното онлајн тренирање на Monolith е дизајнирано за ефикасно синхронизирање на параметрите од training-PS до online serving-PS во кратки интервали, со гаранција за робусност на моделот обезбедена од механизам за толеранција на грешки. 2.1 Хеш-табела Првиот принцип во нашиот дизајн на репрезентација на ретки параметри е да се избегне пренатрупување информации од различни ID-а во исто вградување со фиксна големина. Симулирањето на динамичка табела за вградување со постоечка TensorFlow Variable неизбежно води до судир на ID, што се влошува како што пристигнуваат нови ID-а и табелата расте. Затоа, наместо да се гради врз Variable, развивме нова хеш-табела за клуч-вредност за нашите ретки параметри. Нашата HashTable користи Cuckoo Hashmap [ ] под хаубата, која поддржува вметнување нови клучеви без да се судира со постоечките. Cuckoo Hashing постигнува најлош случај 𝑂 (1) време на сложеност за пребарување и бришење, и очекувана амортизирана 𝑂 (1) време за вметнување. Како што е илустрирано на Слика , таа одржува две табели 𝑇0, 𝑇1 со различни хеш функции ℎ0 (𝑥), ℎ1 (𝑥), и елемент би бил сместен во една од нив. При обидот за вметнување елемент 16 3 𝐴 во 𝑇0, прво се обидува да го смести 𝐴 на ℎ0 (𝐴); Ако ℎ0 (𝐴) е окупирано од друг елемент 𝐵, тој ќе го исфрли 𝐵 од 𝑇0 и ќе се обиде да го вметне 𝐵 во 𝑇1 со истата логика. Овој процес ќе се повторува додека сите елементи не се стабилизираат, или ќе се случи повторно хеширање кога вметнувањето ќе наиде на циклус. Намалувањето на меморискиот отпечаток е исто така важна разгледување во нашиот дизајн. Наивен пристап на вметнување на секој нов ID во HashTable брзо ќе ја исцрпи меморијата. Набљудувањето на реалните продукциски модели води до два заклучоци: (1) ID-ата што се појавуваат само неколку пати имаат ограничено учество во подобрувањето на квалитетот на моделот. Важно набљудување е дека ID-ата се дистрибуирани по долга опашка, каде популарните ID-а може да се појават милиони пати додека непопуларните се појавуваат не повеќе од десет пати. Вградувањата што соодветствуваат на овие инфекуентни ID-а се недотренирани поради недостаток на податоци за тренирање и моделот нема да може да направи добра проценка врз основа на нив. На крајот на краиштата, овие ID-а веројатно нема да влијаат на резултатот, така што квалитетот на моделот нема да страда од отстранување на овие ID-а со ниски појавувања; (2) Застарените ID-а од далечна историја ретко придонесуваат за тековниот модел бидејќи многу од нив никогаш не се посетени. Ова можеби се должи на корисник што веќе не е активен, или кратко видео што е застарено. Чувањето вградувања за овие ID-а не може да му помогне на моделот на кој било начин, освен да ја троши нашата PS меморија залудно. Врз основа на овие набљудувања, дизајниравме неколку евристики за филтрирање на ID-а за помош за поефикасна меморија на имплементацијата на HashTable: (1) ID-ата се филтрираат пред да бидат примени во табелите за вградување. Имаме два методи за филтрирање: Прво, филтрираме по нивните појавувања пред да бидат вметнати како клучеви, каде прагот на појавувања е прилагодлив хиперпараметар што варира за секој модел; Дополнително, користиме веројатносен филтер што помага дополнително да се намали користењето на меморијата; ![#Слика 4: Стриминг мотор. Информациската повратна врска од [Корисник → Модел Сервер → Тренинг Работник → Модел Сервер → Корисник] би поминала долго време кога би се користел патот за Group Training, додека Online Training би го затворил циклусот побрзо.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-ата се обележани со време и поставени да истечат откако ќе бидат неактивни одреден период. Времето на истекување исто така се прилагодува за секоја табела за вградување за да се овозможи разликување на карактеристиките со различна чувствителност на историски информации. Во нашата имплементација, HashTable е имплементирана како TensorFlow ресурс операција. Слично на Variable, пребарувањата и ажурирањата се исто така имплементирани како нативни TensorFlow операции за полесна интеграција и подобра компатибилност. 2.2 Онлајн тренирање Во Monolith, тренирањето е поделено во две фази (Слика 1): (1) Фаза на групно тренирање. Оваа фаза работи како обична TensorFlow тренинг циклус: Во секој чекор на тренирање, еден worker за тренирање чита мини-пакет од податоци за тренирање од складиштето, бара параметри од PS, пресметува напред и назад поминување, и конечно ги испраќа ажурираните параметри до тренинг PS. Малку поинаку од другите вообичаени задачи за длабоко учење, ние го тренираме нашиот сет на податоци само за еден премин. Group training е корисен за тренирање на историски податоци кога ја менуваме архитектурата на нашиот модел и го претренираме моделот; (2) Фаза на онлајн тренирање. Откако моделот ќе биде распореден за онлајн сервирање, тренирањето не престанува, туку влегува во фазата на онлајн тренирање. Наместо да чита мини-пакети од податоци од складиштето, worker за тренирање конзумира податоци во реално време „во лет“ и ги ажурира тренинг PS. Тренинг PS периодично ги синхронизира своите параметри со serving PS, што веднаш ќе стапи на сила од страна на корисникот. Ова му овозможува на нашиот модел интерактивно да се прилагодува според повратните информации од корисникот во реално време. Monolith е изграден со можност за беспрекорно префрлање помеѓу групно тренирање и онлајн тренирање. Ова е овозможено со нашиот дизајн на стриминг мотор, како што е илустрирано на Слика 2.2.1 Стриминг мотор. 4. Во нашиот дизајн, користиме една Kafka [ ] опашка за да ги евидентираме акциите на корисниците (на пр. Кликнување на ставка или Лајкување на ставка итн.) и друга Kafka опашка за карактеристики. Во срцето на моторот е Flink [ ] стриминг работа за онлајн спојувач на карактеристики. Онлајн спојувачот ги спојува карактеристиките со ознаките од корисничките акции и произведува примери за тренирање, кои потоа се запишуваат во Kafka опашка. Опашката за примери за тренирање се консумира и од онлајн и од групно тренирање: 13 4 За онлајн тренирање, worker за тренирање директно чита податоци од Kafka опашката; За групно тренирање, работа за префрлање податоци прво ќе ги префрли податоците во HDFS [ ]; Откако податоците во HDFS ќе се акумулираат до одредена количина, worker за тренирање ќе ги преземе податоците од HDFS и ќе изврши групно тренирање. 18 Ажурираните параметри во тренинг PS ќе бидат испратени до serving PS според распоредот за синхронизација на параметри. Во апликации од реалниот свет, дневниците за кориснички акции и карактеристиките се стримуваат во онлајн спојувачот (Слика без гаранција за временски редослед. Затоа, користиме уникатен клуч за секое барање за да може корисничката акција и карактеристиките правилно да се спојат. 2.2.2 Онлајн Спојувач. 5) Закснетоста на корисничката акција исто така може да биде проблем. На пример, корисникот може да потроши неколку дена пред да одлучи да купи ставка што му била прикажана пред неколку дена. Ова е предизвик за спојувачот бидејќи ако сите карактеристики се чуваат во кеш, тоа едноставно нема да се вклопи во меморијата. Во нашиот систем, се користи дисково складирање клуч-вредност за чување на карактеристики што чекаат повеќе од одреден временски период. Кога ќе пристигне дневник за корисничка акција, тој прво го пребарува кешот во меморијата, а потоа го пребарува складиштето клуч-вредност во случај на недостаток во кешот. Друг проблем што се јавува во апликации од реалниот свет е дека дистрибуцијата на негативни и позитивни примери е многу нееднаква, каде бројот на првите може да биде многу поголем од вторите. За да се спречи позитивните примери да бидат преплавени од негативните, вообичаена стратегија е негативно земање примероци. Ова сигурно ќе ја промени основната дистрибуција на тренираниот модел, прилагодувајќи го кон поголема веројатност за правење позитивни предвидувања. Како лек, применуваме корекција на логаритмот на шансите [ ] за време на сервирање, осигурувајќи дека онлајн моделот е непристрасен проценувач на оригиналната дистрибуција. 19 За време на онлајн тренирање, Monolith тренинг кластерот продолжува да прима податоци од онлајн модулот за сервирање и ги ажурира параметрите на тренинг PS. Клучен чекор за да се овозможи онлајн serving PS да има корист од овие новотренирани параметри е синхронизацијата на ажурираните параметри на моделот. Во продукциската средина, се соочуваме со неколку предизвици: 2.2.3 Синхронизација на параметри. Моделите на онлајн serving PS не смеат да престанат да служат при ажурирање. Нашите модели во продукција обично се неколку терабајти во големина, и како резултат на тоа, заменувањето на сите параметри одзема време. Би било неприфатливо да се запре онлајн PS од сервирање на моделот за време на процесот на замена, и ажурирањата мора да се направат „во лет“; Пренесувањето на модел од повеќе терабајти во неговата целост од тренинг PS до онлајн serving PS би претставувало огромен притисок и на мрежниот опсег и на меморијата на PS, бидејќи бара двојно поголема големина на меморија за да се прими новопристигнатиот модел. За онлајн тренирањето да се скалира до големината на нашето деловно сценарио, дизајниравме инкрементален механизам за периодична синхронизација на параметри „во лет“ во Monolith врз основа на неколку забележителни карактеристики на нашите модели: (1) Редните параметри доминираат во големината на моделите за препораки; (2) Со оглед на краток временски прозорец, само мал подмножество од ID-ата се тренираат и нивните вградувања се ажурираат; (3) Густите променливи се движат многу поспоро од ретките. (1) и (2) ни овозможуваат да искористиме ретки ажурирања низ сите ID-а на карактеристиките. Во Monolith, одржуваме хеш-сет од допрени клучеви, што претставува ID-а чии вградувања се тренирани од последната синхронизација на параметри. Го испраќаме подмножеството од ретки параметри чии клучеви се во сетот на допрени клучеви со интервал од неколку минути од тренинг PS до онлајн serving PS. Овој релативно мал пакет од инкрементално ажурирање на параметри е лесен за мрежен пренос и нема да предизвика остар скок на меморијата за време на синхронизацијата. Исто така, го искористуваме (3) за дополнително да го намалиме I/O на мрежата и користењето на меморијата со поставување поагресивен распоред за синхронизација за ретки параметри, додека густите параметри ги ажурираме поретко. Ова може да ни даде ситуација каде густите параметри што ги сервираме се релативно застарена верзија во споредба со реткиот дел. Сепак, таквата недоследност може да се толерира поради причината спомената во (3) бидејќи не е забележан очигледен губиток. 2.3 Толеранција на грешки Како систем во продукција, Monolith е дизајниран со можност да врати PS во случај на грешка. Вообичаен избор за толеранција на грешки е периодично да се прави снимка на состојбата на моделот и да се врати од најновата снимка кога ќе се открие грешка во PS. Изборот на фреквенцијата на снимање има две главни влијанија: (1) Квалитет на моделот. Интуитивно, квалитетот на моделот помалку страда од губење на неодамнешната историја со зголемена фреквенција на снимање. (2) Пресметковен преоптоварување. Снимањето на модел од повеќе терабајти не е бесплатно. Тоа предизвикува големи делови од копирање на меморија и I/O на дискот. Како компромис помеѓу квалитетот на моделот и преоптоварувањето на пресметките, Monolith снима сите тренинг PS секој ден. Иако PS ќе изгуби еден ден ажурирања во случај на грешка, откриваме дека деградацијата на перформансите е толерантна преку нашите експерименти. Ефектот на доверливоста на PS ќе го анализираме во следниот дел. 3 ЕВАЛУАЦИЈА За подобро разбирање на придобивките и компромисите што произлегуваат од нашиот предложен дизајн, спроведовме неколку експерименти во продукциски размер и A/B тестирање со во живо сообраќај за да го процениме и потврдиме Monolith од различни аспекти. Целиме да одговориме на следниве прашања со нашите експерименти: (1) Колку можеме да имаме корист од хеш-табела без судири? (2)