Pull to refresh

Comments 12

Ребят, кто Kafka в проде достаточно долго использовал, что скажите?

На какие моменты стоит уделять внимание?
Какие могут быть сложности? Планирую запустить для не очень большой нагрузки — Zookeeper отдельно на одном физической сервере и 3 сервера Kafka на 3х отдельных серверах.
Все сервера не чисто под Kafka а вместе с другими сервисами. Но 200 GB SAS дисков + 2 GB ОЗУ на каждой машине свободны.
Планируемый RPS до 1-5к по 1-2KB.
Очень довольны Кафкой в проде. Никаких сложностей не вызывает. Зукиперу нужно нечетное количество машин > 1 для кворума. Там машина-лидер определяется путём голосования. Но нагрузка на него небольшая. Поэтому, как мне кажется, лучше взять 3 нежирные машинки для него. Другой вариант: запустить его на тех же 3-х машинах, что и Кафку. Планируемый RPS потянет без проблем.
Если я правильно понял алгоритм, то в базе хранятся itemCount-ы и pairCount-ы.
Ну и результирующие степени похожести конечно вместе с pairCount-ами в одной записи.
Если с айтемами вопросов нет, то у пар выходит уж больно высокое количество записей пропорциональное количеству пользователей и квадрату количества айтемов. В реальности их будет меньше, но всё равно много.
В связи с этим вопросы:
1 — я всё правильно понял?
2 — вы что-то делаете для сокращения этих цифр, ведь интересует только топ схожести?
3 — можно поинтересоваться статистикой именно по pairCount? Сколько всего, по сколько записей на одно видео и т.п.
1) все правильно понял :)
2) В реальности пар гораздо меньше чем квадрат айтемов. На текущий момент айтемов хранится 1.5 млн, а пар — 250 млн. Это число более-менее стабильно, так как мы используем механизм TTL встроенный в аэроспайк — если запись не обновлялась месяц — она выкидывается из хранилища.
Добавлю, что для каждого item мы храним не все его пары, а лишь K самых частых. Таким образом количество хранимых пар ограничено K*(# of items).
Хороший ход, но работает именно для вашей задачи. Если бы видео не имели тенденцию устаревать, и вкусы имели бы свойство меняться динамичнее, то отбрасывая «слабые» связи лишались бы гибкости, ведь новое видео никогда не сможет попасть в рекомендуемые, даже будучи на 99% одинаковым по просмотрам, если К айтемов уже есть.
очень интересная статья, спасибо.
несколько вопросов:
1 — сами свойства видео нигде не учитываются для оценки похожести? т.е. грубо говоря, если один пользователь посмотрел видео х, у, то пользователю который посмотрел видео х предложат посмотреть видео у.
2 — 1.2М айтемов это не так много вроде. Причем активных скорее всего гораздо меньше. Почему просто не держать их счетчики в памяти?
Добрый день.
1) Пока не учитываются, хотя планируем учитывать.
2) Счетчики действительно пока могут влезть в память(хотя тут надо иметь ввиду что количество счетчиков гораздо больше чем айтемов — счетчик заводится на пару айтемов). Смысл в следующем: система во-первых должна быть масштабируемой, это значит что любая машина в кластере должна иметь возможность прочитать нужный счетчик. Во вторых хочется чтобы система была устойчивой к падениям, поэтому хорошо бы чтобы данные хранились персистентно. Обе эти проблемы решаются при помощи исппользования аэроспайка.
  • а Aerospike кластер бежит на своих машинах или в облаке? Какая у них примерная конфигурация?
  • Есть ли уже готовые библиотеки под этот алгоритм?
Все работает на арендованных железных серверах в hetzner. Аэроспайк — 2 машины по 64 гигабайта памяти и 500гб SSD.

Алгоритмов не нашли реализованных, поэтому реализовали в собственном движке.
А вы в итоге данные, которые из стрима в Aerosprike сложили, потом снова в Spark обрабатывали? Насколько коннектор хорошо работает?
В Aerospike мы складываем уже обработанные в Spark'е данные. Обратно в Spark они не идут. Поэтому особо никакой коннектор тут не нужен. Создается соединение и идет запись.

Чтение из Aerospik'а обратно в Spark мы используем в другой системе, и там тоже никаких проблем нет. Так же создаем соединение и считываем.
Sign up to leave a comment.