Netflix объявил об архитектуре своей системы рекомендаций в 2013 году. Эта статья в основном обобщает и переводит сSystem Architectures for Personalization and Recommendation, но это не полный перевод статьи.
Overview
Во-первых, мы приводим общую системную диаграмму рекомендательной системы на рисунке ниже. Основные компоненты архитектуры содержат один или несколько алгоритмов машинного обучения.
Расчеты могут быть выполнены в режиме онлайн, в режиме реального времени или в автономном режиме. Онлайн-вычисления могут лучше реагировать на недавние события и взаимодействия с пользователем, но должны реагировать на запросы в режиме реального времени. Это ограничивает вычислительную сложность используемого алгоритма и объем данных, которые могут быть обработаны. Вычисления в автономном режиме менее ограничивают объем данных и вычислительную сложность алгоритма, потому что они работают в пакетном режиме и имеют более мягкие требования к времени. Одна из ключевых проблем в архитектуре персонализации заключается в том, как беспрепятственно сочетать онлайн- и офлайн-вычисления и управлять ими. Почти оперативные вычисления — это промежуточный компромисс между этими двумя режимами, когда мы можем выполнять вычисления, подобные онлайновым, но не требуя, чтобы они были доступны в режиме реального времени. Обучение модели — это еще одна форма вычислений, в которой используются существующие данные для создания модели, которая будет использоваться позже во время фактического вычисления результатов. Другая часть архитектуры описывает, как система распределения событий и данных обрабатывает различные типы событий и данных. Связанный с этим вопрос заключается в том, как комбинировать различные сигналы и модели, необходимые для автономного, ближнего и оперативного режимов. Наконец, нам также нужно выяснить, как объединить промежуточные результаты рекомендаций таким образом, чтобы они были значимы для пользователей. В оставшейся части этой статьи будут подробно описаны эти компоненты этой архитектуры и их взаимодействие. Вся инфраструктура Netflix работает в облаке Amazon Web Services.
Computation
Онлайн-вычисления могут быстро реагировать на события и использовать самые свежие данные. Примером может служить сортировка галереи боевиков с использованием текущего контекста. Онлайн-компоненты регулируются соглашениями об уровне обслуживания (SLA) о доступности и времени отклика, которые определяют максимальную задержку процессов, отвечающих на запросы от клиентских приложений. Это затрудняет использование сложных и ресурсоемких алгоритмов в онлайн-сервисах. Кроме того, чисто онлайн-вычисления в некоторых случаях могут не соответствовать SLA, поэтому важно учитывать механизмы быстрого отката (например, возврат к предварительно вычисленным результатам). Онлайн-вычисления также означают, что различные задействованные источники данных также должны быть доступны онлайн, что может потребовать дополнительной инфраструктуры.
Автономные вычисления позволяют использовать более сложные алгоритмы и больше данных.Простым примером может быть регулярное агрегирование статистики по миллионам событий воспроизведения фильмов для расчета базовых показателей популярности. Автономные системы также имеют более простые инженерные требования. Например, могут быть легко соблюдены SLA с упрощенным временем отклика, установленные клиентами. Новые алгоритмы можно развертывать в рабочей среде, не затрачивая слишком много усилий на настройку производительности. Эта гибкость поддерживает гибкие инновации. Netflix использует это преимущество для поддержки быстрых экспериментов: если новые экспериментальные алгоритмы работают медленно, мы можем просто развернуть больше экземпляров Amazon EC2 для достижения пропускной способности, необходимой для проведения экспериментов, вместо того, чтобы тратить драгоценное инженерное время на оптимизацию производительности. иметь небольшую коммерческую ценность. Однако, поскольку автономная обработка не требует больших задержек, она не может быстро реагировать на изменения контекста или новые данные. Это может ухудшить пользовательский опыт. Автономные вычисления также требуют наличия инфраструктуры для хранения, обработки и доступа к большому количеству предварительно вычисленных результатов.
Почтилинейные вычисления можно рассматривать как компромисс между первыми двумя режимами. Ближайшие вычисления выполняются в ответ на пользовательские события.
В любом случае онлайн/почти/офлайн можно и нужно совмещать. Есть много способов их комбинировать. Мы уже упоминали идею использования офлайн-вычислений в качестве запасного варианта. Другой вариант — использовать автономный процесс для предварительного вычисления частичных результатов и оставить менее затратные или контекстно-зависимые части алгоритма для онлайн-вычислений. Даже часть моделирования может быть выполнена гибридным оффлайн/онлайн способом. Традиционные приложения контролируемой классификации должны пакетно обучать классификаторы на основе размеченных данных и делать прогнозы в режиме онлайн. Однако такие методы, как матричная факторизация, лучше подходят для гибридного онлайн-/офлайн-моделирования: некоторые факторы могут быть предварительно вычислены в автономном режиме, а другие могут обновляться в режиме реального времени для получения более свежих результатов. Другие неконтролируемые методы, такие как кластер, также позволяют вычислять центры кластеров в автономном режиме и назначать кластеры в режиме онлайн.
Offline Jobs
Signals & Models & Event & Data
Независимо от того, выполняем ли мы вычисления в режиме онлайн или в автономном режиме, нам необходимо учитывать, как алгоритм обрабатывает три входных данных: модель, данные и сигнал. Модели обычно представляют собой небольшие файлы параметров, которые предварительно обучались в автономном режиме. Данные — это предварительно обработанная информация, которая была сохранена в какой-либо базе данных, например, метаданные фильмов или популярность. Мы используем термин «сигнал» для обозначения новой информации, которую мы вводим в алгоритм. Эти данные получаются из сервисов в режиме реального времени и могут состоять из информации, относящейся к пользователю (например, что участник недавно смотрел), или контекстных данных, таких как сеанс, устройство, дата или время.
Netflix пытается провести различие между событием и данными. Они рассматривают события как небольшие блоки чувствительной ко времени информации, которые необходимо обрабатывать с минимально возможной задержкой, чтобы инициировать последующие действия или процедуры, такие как обновление ближайшего набора результатов. С другой стороны, они рассматривают данные как более плотную единицу информации, которую, возможно, потребуется обработать и сохранить для последующего использования. Задержка здесь не так важна, как качество и количество информации. Конечно, некоторые пользовательские события можно рассматривать как события и данные, и поэтому они отправляются в оба потока.
Recommendation Results
MySQL позволяет хранить структурированные реляционные данные, которые могут потребоваться для некоторых будущих процессов с помощью общих запросов. Однако эта универсальность достигается за счет масштабируемости в распределенной среде. И Cassandra, и EVCache предлагают преимущества хранилищ ключей и значений. Cassandra — известное стандартное решение, когда требуется распределенное и масштабируемое хранилище без SQL. В некоторых случаях Cassandra работает хорошо, но EVCache лучше подходит для интенсивных и продолжительных операций записи.