Вътре в монолита на ByteDance: Двигателят, захранващ по-умни, по-бързи емисии със съдържание

Автори: Жуоран Лю, Bytedance Inc. Леки Зоу, Bytedance Inc. Суан Зоу, Bytedance Inc. Кайхуа Ван, Bytedance Inc. Бяо Джан, Bytedance Inc. Да Танг, Bytedance Inc. Болин Джу*, Университет Фудан Ииджие Джу, Bytedance Inc. Пенг Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Юлонг Ченг†, Bytedance Inc. (youlong.cheng@bytedance.com) РЕЗЮМЕ Изграждането на мащабируема система за препоръки в реално време е жизненоважно за много бизнеси, задвижвани от чувствителни към времето отзиви на клиенти, като например класиране на кратки видеоклипове или онлайн реклами. Въпреки повсеместното приемане на производствени рамки за дълбоко обучение като Ten-sorFlow или PyTorch, тези рамки с общо предназначение не отговарят на бизнес нуждите в сценарии за препоръки поради различни причини: от една страна, настройката на системи въз основа на статични параметри и плътни изчисления за препоръки с динамични и разредени характеристики е пагубна за качеството на модела; от друга страна, такива рамки са проектирани с напълно разделени етапи на пакетно обучение и обслужване, което предотвратява взаимодействието на модела с обратната връзка от клиента в реално време. Тези проблеми ни накараха да преразгледаме традиционните подходи и да проучим коренно различни дизайнерски решения. В тази статия представяме 1, система, пригодена за онлайн обучение. Нашият дизайн е продиктуван от наблюдения върху нашите работни натоварвания на приложения и производствена среда, които отразяват значително отклонение от други системи за препоръки. Нашият принос е многостранен: първо, създадохме таблица за вграждане без колизии с оптимизации като изтичащи вграждания и филтриране по честота, за да намалим нейния отпечатък върху паметта; второ, предоставяме готова за производство архитектура за онлайн обучение с висока отказоустойчивост; накрая, доказахме, че надеждността на системата може да бъде разменена за обучение в реално време. Monolith е успешно внедрен в продукта BytePlus Recommend2. Monolith 1 ВЪВЕДЕНИЕ През последното десетилетие се наблюдава бум на бизнеси, захранвани от техники за препоръки. В стремежа си към по-добро потребителско изживяване, предоставянето на персонализирано съдържание за всеки отделен потребител като реакция в реално време е обща цел на тези бизнес приложения. За тази цел информацията от най-скорошното взаимодействие на потребителя често се използва като основен вход за обучение на модел, тъй като най-добре би описала портрета на потребителя и би направила прогнози за интересите и бъдещото поведение на потребителя. Дълбокото обучение доминира моделите за препоръки [ , , , , , ], тъй като огромното количество потребителски данни е естествено подходящо за масивно базирани на данни невронни модели. Въпреки това, усилията за използване на силата на дълбокото обучение в системи за препоръки на индустриално ниво непрекъснато се сблъскват с проблеми, произтичащи от уникалните характеристики на данните, получени от поведението на потребителите в реалния свят. Тези данни се различават драстично от тези, използвани в конвенционалните проблеми на дълбокото обучение като езиково моделиране или компютърно зрение в два аспекта: 5 6 10 12 20 21 (1) Характеристиките са предимно разредени, категорийни и динамично променящи се; (2) Основното разпределение на данните за обучение е нестационарно, т.е. концептуално отклонение . Такива разлики представляват уникални предизвикателства за изследователите и инженерите, работещи по системи за препоръки. 1.1 Разреденост и динамичност Данните за препоръки съдържат предимно разредени категорийни характеристики, някои от които се появяват с ниска честота. Обичайната практика за картографирането им в пространство с висока размерност на вграждане би довело до поредица от проблеми: • За разлика от езиковите модели, където броят на словните части е ограничен, броят на потребителите и класираните елементи е в порядъци по-голям. Такава огромна таблица за вграждане едва ли би се побрала в паметта на един хост; • Още по-лошо, очаква се размерът на таблицата за вграждане да нараства с времето, тъй като се добавят повече потребители и елементи, докато рамки като [ , ] използват плътни променливи с фиксиран размер за представяне на таблицата за вграждане. 1 17 На практика много системи използват хеширане с ниски колизии [ , ] като начин за намаляване на отпечатъка върху паметта и позволяване на растеж на идентификаторите. Това разчита на свръхидеалистичното предположение, че идентификаторите в таблицата за вграждане са разпределени равномерно по честота и колизиите не вредят на качеството на модела. За съжаление, това рядко е вярно за система за препоръки в реалния свят, където малка група потребители или елементи имат значително повече срещания. С органичния растеж на размера на таблицата за вграждане, шансът за колизии на хеш ключове се увеличава и води до влошаване на качеството на модела 3 6 . Следователно, естествено търсене за системи за препоръки в промишлен мащаб е да имат капацитета да улавят колкото се може повече характеристики в параметрите си, както и да имат възможност гъвкаво да коригират броя на потребителите и елементите, които се опитват да водят отчетност. 1.2 Нестационарно разпределение Визуалните и езиковите модели едва ли се развиват в времева скала от векове, докато същият потребител, заинтересован от една тема, може да промени ентусиазма си всяка следваща минута. В резултат на това основното разпределение на потребителските данни е нестационарно, явление, обикновено наричано концептуално отклонение . Интуитивно, информацията от по-скорошна история може да допринесе по-ефективно за прогнозиране на промяната в поведението на потребителя. За да се смекчи ефектът от концептуалното отклонение, обслужващите модели трябва да се актуализират от нови отзиви от потребители възможно най-близо до реално време, за да отразяват най-новите интереси на потребителя. В светлината на тези различия и в наблюдението на проблемите, произтичащи от нашата продукция, проектирахме , мащабна система за препоръки, която да адресира тези проблеми. Проведохме обширни експерименти, за да проверим и итерираме нашия дизайн в производствената среда. Monolith може да Monolith (1) Осигурява пълна изразителна сила за разредени характеристики чрез проектиране на хеш таблица без колизии и динамичен механизъм за изхвърляне на характеристики; (2) Обратно връщане на обратната връзка от обслужването към обучението в реално време с онлайн обучение. Подкрепен от тези архитектурни възможности, Monolith последователно надминава системи, които използват хеш-трикове с колизии при приблизително сходно използване на паметта и постига най-добрия в класа си онлайн AUC без прекомерно натоварване на изчислителната мощност на нашите сървъри. Останалата част от статията е организирана както следва. Първо, подробно описваме дизайнерските детайли за това как Monolith се справя със съществуващи предизвикателства с хеш таблица без колизии и обучение в реално време в Раздел 2. Експериментите и резултатите ще бъдат представени в Раздел 3, заедно с обобщени заключения от производствени тестове и някои дискусии за компромисите между чувствителност към времето, надеждност и качество на модела. Раздел 4 обобщава свързаната работа и я сравнява с Monolith. Раздел 5 заключава тази работа. 2 ДИЗАЙН В архитектурата Worker-PS машините имат различни роли; Worker машините са отговорни за извършването на изчисления, както са дефинирани от графа, а PS машините съхраняват параметри и ги актуализират според градиентите, изчислени от Workers. Общата архитектура на Monolith обикновено следва настройката Worker- arameter erver на TensorFlow (Фигура P S 2). В моделите за препоръки параметрите са категоризирани в два набора: плътни и разредени. Плътните параметри са тегла/променливи в дълбока невронна мрежа, а разредените параметри се отнасят до таблици за вграждане, които съответстват на разредени характеристики. В нашия дизайн както плътните, така и разредените параметри са част от графа на TensorFlow и се съхраняват на сървъри за параметри. Подобно на променливата на TensorFlow за плътни параметри, ние проектирахме набор от високоефективни, без колизии и гъвкави операции на хеш таблица за разредени параметри. Като допълнение към ограничението на Tensor-Flow, произтичащо от разделянето на обучението и извода, еластично мащабируемото онлайн обучение на Monolith е проектирано да синхронизира ефективно параметри от training-PS към online serving-PS в кратки интервали, с гаранция за устойчивост на модела, предоставена от механизма за отказоустойчивост. 2.1 Хеш таблица Основен принцип в нашия дизайн на представяне на разредени параметри е да се избягва претрупването на информация от различни идентификатори в едно и също фиксирано вграждане. Симулирането на динамична таблица за вграждане с готов Variable на TensorFlow неизбежно води до колизии на идентификатори, които се изострят с появата на нови идентификатори и нарастването на таблицата. Следователно, вместо да надграждаме върху Variable, разработихме нова хеш таблица ключ-стойност за нашите разредени параметри. Нашата хеш таблица използва Cuckoo Hashmap [ ] под капака, който поддържа вмъкване на нови ключове без колизии със съществуващи. Cuckoo Hashing постига най-лошия случай 𝑂 (1) времева сложност за търсене и изтриване, и очаквана амортизирана 𝑂 (1) време за вмъкване. Както е илюстрирано във Фигура , тя поддържа две таблици 𝑇0, 𝑇1 с различни хеш функции ℎ0 (𝑥), ℎ1 (𝑥), и елемент ще бъде съхранен в една от тях. Когато се опитвате да вмъкнете елемент 16 3 𝐴 в 𝑇0, тя първо се опитва да постави 𝐴 на ℎ0 (𝐴); Ако ℎ0 (𝐴) е заето от друг елемент 𝐵, тя ще изхвърли 𝐵 от 𝑇0 и ще се опита да вмъкне 𝐵 в 𝑇1 със същата логика. Този процес ще се повтаря, докато всички елементи се стабилизират, или ще се извърши повторно хеширане, когато вмъкването попадне в цикъл. Намаляването на отпечатъка върху паметта също е важно съображение в нашия дизайн. Наивен подход за вмъкване на всеки нов идентификатор в хеш таблицата ще изчерпи паметта бързо. Наблюдението на реални производствени модели води до две заключения: (1) Идентификаторите, които се появяват само няколко пъти, имат ограничено принос към подобряването на качеството на модела. Важно наблюдение е, че идентификаторите са разпределени в дълга опашка, където популярните идентификатори могат да се появят милиони пъти, докато непопулярните се появяват не повече от десет пъти. Вгражданията, съответстващи на тези редки идентификатори, са недостатъчно обучени поради липса на тренировъчни данни и моделът няма да може да направи добра оценка въз основа на тях. В крайна сметка тези идентификатори не влияят на резултата, така че качеството на модела няма да пострада от премахването на тези идентификатори с ниска честота; (2) Остарелите идентификатори от далечна история рядко допринасят за текущия модел, тъй като много от тях никога не се посещават. Това може да се дължи на неактивен потребител или кратък видеоклип, който е извън актуалност. Съхраняването на вграждания за тези идентификатори не може да помогне на модела по никакъв начин, освен да изчерпи паметта на нашия PS напразно. Въз основа на тези наблюдения, ние проектирахме няколко евристики за филтриране на идентификатори на характеристики за по-ефективна по памет имплементация на хеш таблица: (1) Идентификаторите се филтрират, преди да бъдат допуснати в таблиците за вграждане. Имаме два метода за филтриране: Първо, филтрираме по тяхната честота, преди да бъдат вмъкнати като ключове, където прагът на честотата е регулируем хиперпараметър, който варира за всеки модел; Допълнително използваме вероятностен филтър, който помага за допълнително намаляване на използването на паметта; ![#Фигура 4: Поточна машина. Информационната обратна връзка от [Потребител → Модел сървър → Обучаващ работник → Модел сървър → Потребител] би отнела много време при пътя на пакетното обучение, докато онлайн обучението затваря цикъла по-незабавно.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Идентификаторите се маркират с време и се задават да изтичат след като са били неактивни за предварително определен период от време. Времето за изтичане също се регулира за всяка таблица за вграждане, за да се позволява разграничаване на характеристики с различна чувствителност към историческа информация. В нашата имплементация, хеш таблицата е имплементирана като операция за ресурс на Tensor-Flow. Подобно на Variable, търсенията и актуализациите също са имплементирани като нативни операции на TensorFlow за по-лесна интеграция и по-добра съвместимост. 2.2 Онлайн обучение В Monolith обучението е разделено на два етапа (Фигура 1): (1) Етап на пакетно обучение. Този етап работи като обикновен цикъл за обучение на Tensor-Flow: При всяка стъпка на обучение, обучаващ работник чете мини-пакет от обучителни примери от хранилището, иска параметри от PS, изчислява преден и заден проход и накрая изпраща актуализирани параметри към training PS. Леко различно от други общи задачи за дълбоко обучение, ние обучаваме нашия набор от данни само за един проход. Пакетното обучение е полезно за обучение на исторически данни, когато модифицираме архитектурата на модела и преобучаваме модела; (2) Етап на онлайн обучение. След като моделът е внедрен за онлайн обслужване, обучението не спира, а преминава към етапа на онлайн обучение. Вместо да чете мини-пакети от примери от хранилището, обучаващ работник обработва данни в реално време в движение и актуализира training PS. Training PS периодично синхронизира своите параметри към serving PS, които ще влязат в сила за потребителя незабавно. Това позволява на нашия модел да се адаптира интерактивно според обратната връзка от потребителя в реално време. Monolith е изграден с възможността за безпроблемно превключване между пакетно обучение и онлайн обучение. Това е възможно благодарение на нашия дизайн на поточна машина, илюстриран от Фигура 2.2.1 Поточна машина. 4. В нашия дизайн използваме една опашка Kafka [ ] за записване на действията на потребителите (напр. кликване върху елемент или харесване на елемент и т.н.) и друга опашка Kafka за характеристики. В основата на машината е Flink [ ] поточна задача за онлайн свързване на характеристики. Онлайн свързващият модул свързва характеристики с етикети от потребителски действия и произвежда обучителни примери, които след това се записват в опашка Kafka. Опашката за обучителни примери се консумира както от онлайн обучение, така и от пакетно обучение: 13 4 За онлайн обучение, обучаващият работник директно чете данни от опашката Kafka; За пакетно обучение, задача за изхвърляне на данни първо ще изхвърли данни в HDFS [ ]; След като данните в HDFS се натрупат до определено количество, обучаващият работник ще извлече данни от HDFS и ще извърши пакетно обучение. 18 Актуализираните параметри в training PS ще бъдат изпратени към serving PS според графика за синхронизация на параметрите. В приложения от реалния свят, дневниците на потребителски действия и характеристиките се предават към онлайн свързващия модул (Фигура без гаранция за времеви ред. Следователно използваме уникален ключ за всяка заявка, така че потребителското действие и характеристиките да могат да бъдат правилно свързани. 2.2.2 Онлайн свързващ модул. 5) Забавянето на потребителските действия също може да бъде проблем. Например, потребител може да отнеме няколко дни, преди да реши да купи елемент, представен му преди дни. Това е предизвикателство за свързващия модул, защото ако всички характеристики се пазят в кеша, те просто няма да се поберат в паметта. В нашата система се използва хранилище ключ-стойност на диска за съхраняване на характеристики, които чакат твърде дълго. Когато пристигне журнал за потребителски действия, той първо търси в кеша в паметта, а след това търси в хранилището ключ-стойност в случай на липса на кеш. Друг проблем, възникващ в приложения от реалния свят, е, че разпределението на отрицателните и положителните примери е силно неравномерно, като броят на първите може да бъде порядъци по-голям от вторите. За да се предотвратят положителните примери да бъдат превъзмогнати от отрицателните, общата стратегия е да се извърши отрицателно семплиране. Това със сигурност ще промени основното разпределение на обучената модел, настройвайки го към по-висока вероятност за извършване на положителни прогнози. Като средство за корекция, прилагаме корекция на лог-одите [ ] по време на обслужване, като гарантираме, че онлайн моделът е безпристрастен оценител на оригиналното разпределение. 19 По време на онлайн обучение, тренировъчният клъстер на Mono-lith продължава да получава данни от модула за онлайн обслужване и да актуализира параметрите на training PS. Ключова стъпка, която позволява на online serving PS да се възползва от тези новообучени параметри, е синхронизацията на актуализираните параметри на модела. В производствена среда сме изправени пред няколко предизвикателства: 2.2.3 Синхронизация на параметри. Моделите на online serving PS не трябва да спират да обслужват при актуализация. Нашите модели в производство обикновено са с размер от няколко терабайта и в резултат на това замяната на всички параметри отнема известно време. Би било непоносимо да се спира online PS от обслужване на модела по време на процеса на замяна и актуализациите трябва да се правят в движение; Прехвърлянето на многотерабайтов модел изцяло от training PS към online serving PS би поставило огромно налягане както върху мрежовата честотна лента, така и върху паметта на PS, тъй като изисква удвоен размер на паметта, за да се приеме пристигащият модел. За да може онлайн обучението да се мащабира до размера на нашия бизнес сценарий, ние проектирахме механизъм за инкрементална синхронизация на периодични параметри в движение в Monolith, базиран на няколко забележителни характеристики на нашите модели: (1) Разредените параметри доминират размера на моделите за препоръки; (2) При кратък времеви прозорец само малка част от идентификаторите се обучават и техните вграждания се актуализират; (3) Плътните променливи се движат много по-бавно от разредените вграждания. Това е така, защото при оптимизатори, базирани на моментум, натрупването на моментум за плътни променливи се увеличава от гигантския размер на данните за обучение на препоръки, докато само малко разредени вграждания получават актуализации в една партида данни. (1) и (2) ни позволяват да експлоатираме разредените актуализации във всички идентификатори на характеристики. В Monolith поддържаме хеш набор от докоснати ключове, представляващи идентификатори, чиито вграждания са били обучени от последната синхронизация на параметри. Изпращаме подмножеството от разредени параметри, чиито ключове са в набора от докоснати ключове, с интервал от една минута от training PS към online serving PS. Този сравнително малък пакет от инкрементални актуализации на параметри е лек за мрежово предаване и няма да причини рязък скок в паметта по време на синхронизацията. Също така експлоатираме (3), за да намалим допълнително мрежовия I/O и използването на паметта, като задаваме по-агресивен график за синхронизация на разредени параметри, докато актуализираме плътни параметри по-рядко. Това може да ни доведе до ситуация, в която плътните параметри, които обслужваме, са сравнително остаряла версия в сравнение с разредената част. Въпреки това, такава несъвместимост може да бъде толерирана поради причината, спомената в (3), тъй като не е наблюдавана забележима загуба. 2.3 Отказоустойчивост Като система в продукция, Monolith е проектиран с възможност за възстановяване на PS в случай на неизправност. Често срещан избор за отказоустойчивост е периодичното заснемане на състоянието на модела и възстановяване от последното заснемане, когато се открие неизправност на PS. Изборът на честота на заснемане има две основни въздействия: (1) Качество на модела. Интуитивно, качеството на модела страда по-малко от загуба на скорошна история с повишена честота на заснемане. (2) Изчислителни разходи. Заснемането на многотерабайтов модел не е безплатно. То води до големи копия на паметта и I/O на диска. Като компромис между качеството на модела и изчислителните разходи, Monolith заснема всички training PS всеки ден. Въпреки че PS ще загуби дневна актуализация в случай на неизправност, открихме, че деградацията на производителността е поносима чрез нашите експерименти. Ще анализираме ефекта от надеждността на PS в следващата секция. 3 ОЦЕНКА За по-добро разбиране на ползите и компромисите, донесени от предложения от нас дизайн, проведохме няколко експеримента в производствен мащаб и A/B тест с трафик на живо, за да оценим и проверим Monolith от различни аспекти. Целим да отговорим на следните въпроси чрез нашите експерименти: (1) Колко можем да се възползваме от хеш таблица без колизии? (2) Колко важно е онлайн обучението в реално време? (3) Устойчив ли е дизайнът на Monolith за синхронизация на параметри в мащабен производствен сценарий? В този раздел първо представяме нашите експериментални настройки и след това обсъждаме подробно резултатите и нашите открития. 3.1 Експериментална настройка Както е описано в Раздел таблиците за вграждане в Monolith са имплементирани като хеш таблици без колизии. За да докажем необходимостта от избягване на колизии в таблиците за вграждане и да квантифицираме ползите от нашата имплементация без колизии, проведохме две групи експерименти върху набора от данни Movielens и върху нашия вътрешен производствен набор от данни съответно: 3.1.1 Таблица за вграждане. 2.1, (1) Набор от данни ml-25m [ ]. Това е стандартен публичен набор от данни за оценки на филми, съдържащ 25 милиона оценки, включващи приблизително 162 000 потребители и 62 000 филма. MovieLens 11 • . Оригиналните етикети са оценки от Предварителна обработка на етикетите 0.5 до 5.0, докато в продукция задачите ни са предимно получаване на бинарни сигнали от потребители. За да симулираме по-добре нашите производствени модели, преобразуваме скалните етикети в бинарни етикети, като третираме оценки ≥ 3.5 като положителни примери и останалите като отрицателни примери. • Модел и метрики. Имплементирахме стандартен модел DeepFM, често използван архитектурен модел за задачи за препоръки. Той се състои от FM компонент и плътен компонент (Фигура 6). Прогнозите се оценяват чрез AUC, тъй като това е основното измерване за реални модели. • Колизии на вграждания. Този набор от данни съдържа приблизително 160K потребителски идентификатори и 60K идентификатори на филми. За да сравним с версията без колизии на имплементацията на таблицата за вграждане, проведохме друга група експерименти, при която идентификаторите са предварително обработени с MD5 хеширане и след това картографирани в по-малко ID пространство. В резултат на това някои идентификатори ще споделят своето вграждане с други. Таблица 1 показва подробна статистика на потребителските и филмовите идентификатори преди и след хеширане. (2) . Вътрешен набор от данни за препоръки Проведохме експерименти и върху модел за препоръки в производствена среда. То