Перевод статьи " Нетфликс.Теги: #Машинное обучение #ИТ-инфраструктура #Большие данные #Анализ и проектирование систем #наука о данных #Инженерия данных #netflix #рекомендующая система #архитектура системыСистемные архитектуры для персонализации и рекомендаций»
.Перевод неточный, некоторые части опущены, так как показались мне повторением уже высказанных выше мыслей, некоторые уточнены и дополнены примерами.
В предыдущих публикациях о персонализации в Netflix уже обсуждалось, насколько важны как данные, так и алгоритмы обработки данных в задаче персонализации пользовательского опыта.
Также важно вовлечь пользователя в систему рекомендаций — чтобы получить от него больше ответов и данных.
Сегодня мы поговорим о том, как создать архитектуру, которая сможет максимизировать ценность собираемых вами данных и поддерживать возможность быстрого внедрения инноваций.
Разработка архитектуры, которая
это не тривиальная задача.
- обрабатывает огромные объемы существующих данных,
- реагирует на взаимодействие пользователя с системой
- позволяет легко экспериментировать с новыми подходами к рекомендациям
В этом посте мы поговорим о том, как Netflix решает некоторые из этих проблем.
Во-первых, рассмотрим общую архитектуру рекомендательных систем Netflix. Основные компоненты архитектуры содержат один или несколько алгоритмов машинного обучения.
Самое простое, что вы можете сделать с данными, — это сохранить их, чтобы можно было спокойно обрабатывать их в автономном режиме; за эту часть диаграммы отвечает «зона».Оффлайн вакансии «Но расчеты можно производить не только оффлайн, но и близлайн и онлайн.
В сети расчеты лучше реагируют на недавние события и взаимодействия с пользователем (только что был загружен на сайт новый боевик или вам как пользователю просто понравилась картинка совы), но они должны отвечать на запросы в реальном времени, а это существенно ограничивает вычислительная сложность алгоритмов, используемых в Интернете.
Объем данных, которые можно обработать онлайн, не выходя из кассы, также ограничен требованиями скорости.
Оффлайн-расчеты имеют гораздо меньше подобных ограничений, поскольку рассчитываются пакетно и имеют достаточно мягкие тайминги.
Однако результаты таких расчетов могут быть неактуальны для пользователя, поскольку не были учтены самые последние данные (например, тот факт, что за последние 2 часа вы внезапно увлеклись уличным балетом).
Это одна из ключевых проблем при построении архитектуры персонализации — нужно объединить онлайн- и офлайн-вычисления так, чтобы они работали как одно целое — слаженно, быстро, точно.
Типовые расчеты ближний - это компромисс между онлайном и офлайном, здесь мы можем производить расчеты онлайн, но не требуем их выполнения мгновенно - например, вы начали лайкать собак в ленте, а лента стала предлагать вам больше собак только через 5 минут. Модельное обучение — это тоже расчет, в результате которого мы получаем обученную на имеющихся данных модель, которая в дальнейшем дает нам рекомендации.
Другая часть архитектуры — система распределения событий и данных ( Распространение событий и данных ), описывает, как в системе обрабатываются события и данные разных типов.
Похожая задача – как обработать разные Сигналы и модели , Подробнее о том, что это такое, мы поговорим ниже.
.
Ну и в итоге нам нужно собрать некий усредненный результат рекомендаций со всех наших частей системы( Рекомендация Результат) которые будут интересны нашему пользователю.
Далее мы поговорим более подробно обо всех компонентах архитектуры, а также об их взаимодействии, для этого разделим общую схему на части и пройдемся по каждой из них.
Полезно помнить, что вся инфраструктура работает в публичном облаке AWS.
Онлайн, ближайший и оффлайн вычисления
Онлайн-вычисления позволяют быстро реагировать на недавние события и использовать новейшие данные.Например, создание галереи боевиков, отсортированной для пользователя с учетом его текущего контекста.
Но онлайн-вычисления должны соответствовать Соглашению об уровне обслуживания (SLA), которое определяет максимальную задержку ответа на запросы клиентских приложений, иными словами, время, пока наш пользователь ждет появления рекомендаций, не резиновое.
Это может затруднить реализацию вычислительно сложных алгоритмов.
Кроме того, в некоторых случаях чистые онлайн-вычисления могут не соответствовать соглашению об уровне обслуживания, поэтому всегда важно учитывать механизм быстрого возврата, например возврат к предыдущему, уже вычисленному результату.
Онлайн-вычисления также означают, что задействованные источники данных также должны быть доступны в Интернете, а для этого может потребоваться дополнительная инфраструктура.
С другой стороны, автономные вычисления позволяют использовать более сложные алгоритмы и не имеют столь жестких ограничений на объем обрабатываемых данных.
Простой пример — периодическое агрегирование миллионов просмотров для выработки основных общих рекомендаций для популярных фильмов.
Новые алгоритмы можно легче внедрить в автономные системы, не тратя много времени на их оптимизацию.
Netflix использует автономные вычисления для поддержки быстрого экспериментирования: если новый экспериментальный алгоритм работает медленнее, он может просто развернуть больше экземпляров Amazon EC2 для достижения пропускной способности, необходимой для проведения эксперимента, вместо того, чтобы тратить драгоценное инженерное время на оптимизацию алгоритма, который в конечном итоге может оказаться неудачным.
не будет столь ценным для бизнеса.
Но автономный алгоритм не будет быстро реагировать на изменения контекста или новые данные.
«Неторопливость» офлайн-рекомендаций может привести к «застою» рекомендаций, что, в свою очередь, может ухудшить пользовательский опыт. Автономные вычисления также требуют инфраструктуры для хранения, вычисления и доступа к большим наборам предварительно вычисленных результатов.
Близкие вычисления можно рассматривать как компромисс между двумя предыдущими типами.
В этом случае вычисления выполняются точно так же, как и при онлайн-подходе, но мы уже не требуем от них предоставления результатов сразу после расчета, а вместо этого сохраняем их, делая их асинхронными.
Это открывает возможность потенциально более сложной обработки событий.
Примером может служить обновление статуса фильма на «просмотренный» сразу после того, как пользователь начинает его смотреть.
Результаты могут быть сохранены в кеше или на сервере.
Близкие вычисления также являются областью применения алгоритмов поэтапного обучения.
В любом случае мы не можем выбирать ни один из этих подходов, поскольку их можно и нужно совмещать.
Есть много способов построить такую комбинированную архитектуру.
Мы уже упоминали идею использования офлайн-вычислений в качестве резервного аэродрома на случай выхода из строя онлайн-вычислений.
Другой вариант — предварительно вычислить часть результата с использованием автономного процесса и оставить менее вычислительно сложные или более контекстно-зависимые части алгоритмов для онлайн-вычислений.
Даже моделирование может проводиться в гибридном оффлайн/онлайн-режиме.
Обычно этот подход не используется для контролируемой классификации, а используется только в режиме онлайн для классификации новых входных данных.
Однако такие подходы, как матричная факторизация, более естественно подходят для гибридного онлайн-/оффлайн-моделирования: некоторые шаги можно предварительно вычислить в автономном режиме, а другие можно обновить в реальном времени.
Неконтролируемые подходы, такие как кластеризация, позволяют рассчитывать центры кластеров в автономном режиме и назначать кластеры в режиме онлайн.
Эти примеры показывают, что мы можем разделить процесс обучения модели на части — «тяжелое», масштабное, потенциально достаточно сложное обучение и более простое обучение/обновление для пользователя.
Автономные вычисления
Большую часть расчетов для рекомендаций можно выполнить в автономном режиме.Это означает, что мы можем запускать процессы периодически и в установленное нами время.
Результат этих процессов не привязан к внешним запросам, поскольку они используют уже рассчитанные данные.
Под эту категорию подпадают два основных процесса: обучение модели И расчет промежуточных или окончательных результатов в пакетном режиме .
В процессе обучения модели мы собираем существующие данные и применяем алгоритм машинного обучения, который выводит набор параметров/весов модели (которые мы будем продолжать называть моделью).
Эта модель обычно кодируется и сохраняется в файле для дальнейшего использования.
Хотя большинство моделей обучаются пакетно в автономном режиме, у нас также есть методы, позволяющие поэтапное обучение проводить онлайн.
Подсчет результатов означает, что мы что-то вычисляем по заранее обученной модели, а затем передаем это либо в онлайн-обработку, либо напрямую пользователю.
Обе эти задачи требуют предварительно обработанных и организованных данных, которые мы обычно получаем из запросов к базе данных.
Они обрабатывают большие объемы данных, поэтому полезно запускать их распределенно.
Hadoop отлично справляется с распределением запросов с помощью заданий Hive или Pig. Логично, что нам нужен механизм публикации результатов запроса, то есть оповещение всех сервисов, которым для работы необходимы эти данные — Мы говорим о схеме издатель-подписчик.
У нас есть несколько требований к этому механизму: во-первых, он должен уведомлять подписчиков о готовности результата запроса.
Во-вторых, он должен поддерживать разные типы репозиториев (не только HDFS, но и S3 или Cassandra, например).
Наконец, он должен прозрачно обрабатывать ошибки и обеспечивать мониторинг и оповещение.
Netflix использует внутренний инструмент под названием Hermes, который предоставляет все эти возможности и создает согласованную структуру публикации и подписки.
Это позволяет доставлять данные подписчикам практически в реальном времени.
В некотором смысле он похож на Apache Kafka, но, в отличие от него, Hermes не является системой очередей сообщений и событий.
Сигналы и модели.
Сигналы и модели
Независимо от того, какой тип вычислений мы используем, мы должны учитывать, как наша архитектура будет обрабатывать три типа данных — модели, данные и сигналы.Модели обычно представляют собой небольшие файлы с весами/параметрами, полученные в результате предварительного обучения в автономном режиме.
Данные — это предварительно обработанная информация, которая хранится в какой-либо базе данных, например метаданные фильмов или рейтинги популярности.
Под термином «сигнал» мы подразумеваем данные о событиях, которые поступают в систему — чей-то лайк, чей-то взгляд. Эти сигналы поступают от онлайн-сервисов и могут представлять собой информацию о пользователе, например, какие фильмы он смотрит, или контекстную информацию, например данные сеанса, устройства, дату и время.
Распространение событий и данных.
Распространение событий и данных
Наша цель — превратить данные о взаимодействии с пользователем в информацию для улучшения пользовательского опыта.Поэтому мы хотим, чтобы разные интерфейсы Netflix (умные телевизоры, планшеты, консоли и т. д.) собирали как можно больше пользовательских данных.
Это может быть щелчок, прокрутка, просмотр или даже определение содержимого в определенный момент времени.
Мы агрегируем, систематизируем и подгоняем их в модели.
Здесь можно отличить события от данных, хотя грань довольно размыта.
Мы позвоним события небольшие порции срочной информации, которые необходимо обработать с максимально короткой задержкой – лайк фильма, смена поля «любимый жанр» в профиле.
Эти события запускают следующее действие, например процесс обновления рекомендаций ближайшего окружения.
Данные - более богатые информационные единицы, которые, возможно, потребуется обработать и сохранить для последующего использования.
Здесь не так важна задержка, как качество и количество информации.
Конечно, существуют пользовательские события, которые можно рассматривать как события, так и данные, и поэтому мы отправляем их в оба потока.
В Netflix непосредственный поток событий управляется с помощью внутренней платформы под названием Manhattan. Манхэттен — это распределенная вычислительная система, занимающая центральное место в рекомендательной архитектуре Netflix. Он чем-то похож на Twitter Storm, но решает другие задачи и отвечает другому набору внутренних требований.
На начальных этапах обработки поток данных управляется в основном посредством регистрации через Chukwa в Hadoop. Позже мы используем Hermes как реализацию шаблона публикации-подписки для наших сервисов и обработчиков сообщений о событиях и изменениях данных.
Рекомендации Результаты
Цель машинного обучения в системе — предоставление персонализированных рекомендаций.Эти рекомендации можно скачать из списка, который мы рассчитываем заранее или формируем на лету онлайн-алгоритмами.
Конечно, используется и комбинация этих двух подходов, например, мы можем читать основные рекомендации в режиме офлайн, а затем добавлять к ним что-то новое, обрабатывая сигналы, поступающие из реального времени.
Netflix хранит оффлайн и промежуточные результаты в различных репозиториях, чтобы они были доступны при поступлении запроса.
В качестве хранилища данных в основном использует Cassandra, EVCache и MySQL. MySQL позволяет хранить структурированные реляционные данные, которые могут потребоваться для какого-либо будущего процесса.
Однородность запросов — неоспоримый плюс, но вместе с этим плюсом возникают проблемы с масштабируемостью в распределенных средах.
Cassandra и EVCache обладают преимуществами хранилищ «ключ-значение».
Cassandra — известное и стандартное решение, когда вам нужно распределенное и масштабируемое хранилище без SQL. Cassandra хорошо работает в некоторых ситуациях, но в случаях «интенсивной[» и постоянной записи лучше подходит EVCache. Но вопрос не в том, где хранить данные, а в том, как построить архитектуру, которая сможет сочетать противоречивые требования к сложности запросов, задержке чтения/записи и целостности транзакций.
Заключение
Статья завершается разговором о важности построения рекомендательной инфраструктуры.Netflix всегда приветствует в своей команде способных инженеров и специалистов по данным.
Если вы думаете, что можете внести свой вклад в улучшение систем Netflix, обязательно ознакомьтесь с ними.
-
Конфиденциальность В Интернете: P3P
19 Oct, 24 -
Эволюция: Графика И Механика
19 Oct, 24 -
Почему Разработчики Не Любят Маркетологов?
19 Oct, 24 -
Сеть В Законе
19 Oct, 24 -
Красивые Текстуры Фона В Ios
19 Oct, 24
