Как Яндекс Дзен стал сердцем рекомендаций ВК

В 2022 году Дзен стал двигаться вместе с ВК, но что это означало под капотом?
Разберём внутрянку технологий рекомендаций Дзена и текущих продуктов ВК по докладам Дмитрия Погорелова до 2024 ^[1] и самого свежего 2025 с PML ^[2].

Узнаем самые первые архитектуры Дзена, что начали делать с увеличением нагрузки и хотелок МЛщиков. Как пришлось выкручиваться, когда столкнулись с объемами ВК.

Спойлер: нам пригодится шардирование

Сначала был Дзен ^[1]. Куча пользователей и куча документов. Нужно научиться одному искать/рекомендовать другое.

Нагрузка растет, бекенду нужно выкручиваться (есть хорошее практика, всегда когда нагрузка/кол-во данных растет в 10-ки раз – нужно перепроверять на прочность и часто придумывать новое), а МЛ-щикам хочется наоборот бОльше возможностей для более точных предсказаний!

Скорость проверки гипотез/внедрения, реактивность => Основополагающим условием становится – real-time рекомендации!

Что делать?

Основные данные для рекомендаций, это вектора коллаборативные ALS/контентные енкодеры и одиночные/попарные счетчики.

Ембед из 100 float (=400b) * ~15 моделей + остальное ~ 10kb (один документ), а теперь 20k (док на запрос) * 10kb (1 док) * 10k (rps) = 2tb нужно перемещать! По сети не по гоняешь! => Все нужно хранить (рядшыком) на машинке.

Поехали!

2017 год. UserID -> джава монолит с 40gb (=все документы) и касандра для куска истории пользователя. => Документов <=2млн, latency 600ms (для пользователя +-200ms незаметно ) и один монолит в которой все пишут…. и каждый день роняют.

2020 год. Шардируем сервис по типам контента (видео, клипы, посты и кучу экспериментального), выносим отдельно блендер(=объединение разных типов контента).

1. Теперь зоны влияния разработки естественным образом поделились независимо. У каждого свой отдельный сервис.

2. Как общаться между собой микросервисам? Апп-хост ^[3]! Так как сетевые пути становятся запутанней и длинеее, весьма оправдано сделать ровно одну сущность, которая отвечает за пути перемещения данных. (Например потому что, тайммауты при увеличении слоенности микросервисов экспонициалньо растут + конфиг логистики запросов унифицирован)

3. Разные сервисы катаются вместе или независимо? Независимо и точка.

4. 2+млн документов на каждый тип, по прежнему мало!

5. latency 600 -> 400 хорошо, но нужно меньше

2023 год. Захотели хранить индекс из 60млн якорей и 300 кандидатов(=похожих) => ~140gb.

Шардируют рекомендер одного типа и мерджим отдельным микросервисом(напомню, скору уже посчитаны в рекомендорах).
А как шардировать?

• По якорю(=в одном шарде лежат кандидаты его якорей), но это примерно все видео все равно (на одном шарде)!

• По кандидатам(=один шард, знает только о шардированной части кандидатов), но ходить нужно в каждый шард => сетевая нагрузка множится!

• А именно, рассылается информация о пользователе, о его позитивах! А она нужно ровно для тех видео, которые есть на шарде => отправляем только шардированную информацию!

А что получаем?

• graceful degradation – (возможность разменивать качество сервиса, на вместимость) – можем легко отключать часть шардов случайно => пользователь чаще всего будет не замечать (тк он может перезагрузить и найти нужное), так можно и до 50% деградацию включить (=трафика сливать)! Важное свойство публичного сервиса.

• latency=190ms!

• 50млн видео

• НО, тяжелее/дороже поднимать весь стенд, но можно по частям!

Что дальше? Хотим: бесконечную базу и изоляцию разработки. А что получилось, узнаем на PML в 2025 ^[2] .

2024 год. А видим, более детальные схемы сервисов. Узнаем, что ембеды и счетчики многие считаются в Near-real-time, так же в копилочку прошлых лет.

Теперь Дзен пришел в ВК. А пробы начались с ВК Видео, да аж с победой с 80% tvt (total view time) по сравнению со старым движком. И началось великое переселению всего на это. Второй по счету стала Лента ВК.

Кратно больше rps, база. Шардируем дальше? Так же нагрузка огромная. Теперь шардируем, не случайным обрзаом, а по авторам (авторские фичи занимают значимую часть и их теперь не нужно размазывать по всем шардам) + трюк, по сети только нужные отправляем. Но чуть хуже деградируем!

Дальше больше! Для ВК Видео рекомендации справа (doc2doc), хотим бесконечную базу!
Больше шардов 8 -> 32! Но увы, это не помогло…. Даже теоретически это не верно.

Например, потому что если на одном шарде хорошие видео, а на другом плохие, то вот эти плохие видео отберутся и займут место хороших. Теряются связи сравнений пар фильмов.

=> Шардировать кандидатогенераторов нельзя! Выносим отдельно. А независимые индексы уже можно маштабировать. Вот только мы как-будто мы вернулись к изначальной проблеме, гоняем по сети вектора теперь. Но утверждается, это сейчас менее не больно.

Дальше пошли в 10+ продуктов ВК. Интересно было бы послушать, что там с Клипами. В Следующий раз.

Узнали как развивался Дзен и захватил весь ВК. Любопытно, как получилось унифицировать технологию для всех продуктов. И очень полезно видеть развитие технологии с самого начала. Можно попробовать найти на каком из этих этапов (например по rps/кол-во данных) находится ваша технология и переиспользовать техники.

Потихоньку начинаю писать в @noisetosignal ^[4] — идёмте вместе!