2 bdw.key

Товарные рекомендации в интернет-магазине:

опыт внедренияАндрей Зимовнов lead data scientist

ozon.ru

Товарные рекомендации

Что было до нас, далекий 2012

Сбор логов в SQL сервере

• хранятся окном в неделю

• плохая детализация

• неудобно анализировать

Рекомендации считаются на SQL

• считаются медленно

• неподдерживаемый и нерасширяемый код

Первый подход: Python

• Придумываем новые признаки, решаем проблему холодного старта.

• Применяем машинное обучение для настройки модели.

• Запускаем тест на ограниченном ассортименте книжного каталога.

• Получаем прирост конверсии в добавления в корзину из полки рекомендаций.

Второй подход: С++

• Хотим запустить тест на большем числе товаров, но не можем: Python медленный, занимает много памяти и работает в один поток.

• Переписываем движок на C++ с распараллеливанием на OpenMP.

• Сложное обучение, матрица признаков не помещается в память. Пишем дополнительный код, используем диск.

• Запускаем тест, опять получаем прирост.

Что дальше?

Мы уперлись в ресурсы одного сервера, развивать движок стало невозможно.

Но есть и другие проблемы:

• SQL сервер - неудобное хранилище для больших объемов данных, которые хочется обрабатывать не только SQL запросами.

• Нам нужны детальные логи, их надо собирать и где-то хранить.

Архитектура платформы

Счетчик SQL серверПотоки данных

Hadoop кластер

HDFS, Hive

RabbitMQ + Flume Sqoop

Алгоритмы

Cassandra

Сервис

Data Volume & Velocity

• Логи со счетчика (трек действий пользователя, добавления в корзину, просмотры товаров, поиски, просмотры каталогов и многое другое) - 100 events/sec, 15 GB/day (raw).

• Заказы.

• Описания товаров, цены, доступность, ветки каталогов - 8 млн. постоянно обновляемых товаров.

На чем писать алгоритмы?

Первый блин комом: Java.

Плюсы:

• Работает быстро

Минусы:

• Многословна, не видно логики, математикам сложно расширять или улучшать.

• Бедное MapReduce API. Например, на каждый tuple (кортеж) приходится писать свой класс.

Может можно проще?Дубль два: Apache Spark.

Плюсы:

• Python/Scala API

• Более богатое API, чем у MapReduce: map и reduceByKey - частные случаи операций, еще есть join, distinct, intersection, ...

• Умеет кэшировать данные в памяти, помогает итерационным алгоритмам.

• Умеет работать с Hive таблицами.

Минусы:

• Проект активно развивается, но сыроват: не все работает из коробки, надо тьюнить под разный размер задачи.

SQL на больших данных?Hive on TEZ: выполняет SQL-like запросы поверх больших таблиц в HDFS.

Заметили, что в некоторых случаях SQL запросы выразительнее и понятнее даже Python кода на Spark.

Плюсы:

• Все, что можно выразить SQL запросом считается быстро.

Минусы:

• Если SQL не хватает, то нужно писать UDF (User-Defined Function) на Java.

Рабочий вариантЛучше всего работает комбинация: 40% Apache Spark (Python) + 50% Hive on TEZ + 10% Hive UDF (Java).

Плюсы:

• Парсить данные удобно в Spark на Python, дальше их можно сложить в Hive таблицу и продолжить обработку SQL запросом.

• ~ 70% code reuse между прототипом и продакшеном: как правило на UDF переписываются только критичные по производительности и не очень сложные функции, которые достаточно универсальны.

• Математики могут улучшать алгоритмы (нужно знать Python и SQL)!

Минусы:

• У каждого инструмента есть свои минусы. Но мы учимся использовать сильные стороны разных инструментов.

Пример из рекомендаций

Рассмотрим матрицу Item-User, где в ячейке записана 1, если пользователь u покупал товар i.

Одним из признаков рекомендательной системы может быть косинусная мера похожести между строчками матрицы (товарами).

u1 u2 u3 u4

i1 1 1 1

i2 1

i3 1 1

Пример из рекомендацийРешение на Java (только часть кода):

WAT?

Пример из рекомендаций

Решение на Hive (пусть векторы нормированы):

NOT BAD!

Модель и целевой вектор

• Для начала выбрали линейную модель.

• Целевой вектор базируется на информации о добавлениях в корзину в сессии после просмотра товара.

• Надежда на то, что целевой вектор коррелирует с интересующим показателем конверсии в покупку из полки.

Как настраивали

• Матрица признаков размером 40 ГБ (сжатых бинарных данных).

• Функционал качества: NDCG@50.

• Различные алгоритмы black-box оптимизации.

• Обучение написали на Spark, и это удобно.

• В Spark MLlib есть и готовые алгоритмы.

Пример: покоординатный спуск на Spark

Результаты и планы

• Увеличение конверсии блока на 7% в AB-тесте, заметный прирост в деньгах.

• Построили платформу, не придется менять технологии при увеличении объема данных.

• Можем усложнять модель.

• Работаем над прототипом персонализации.

Тест стороннего сервиса

А что кроме рекомендаций?

• Аксессуары и бандлы

• Прогнозирование продаж

• Оптимизация формулы ранжирования поиска (настраивались на клики)

• Оптимизация сортировки в каталогах (trade-off между ценой товара и вероятностью его покупки)

Как рождаются прототипы

Рабочая формула:Data scientists + Jupyter notebooks

• Практически вся работа математика происходит в веб-браузере в интерактивной консоли IPython, редко используется PyCharm.

• Удобно делиться результатами экспериментов: сохранены все шаги эксперимента, графики, встроенная HTML визуализация.

• Работа с кластером в этом же окружении.

Пример: Jupyter notebooks

Спасибо за внимание!

Вопросы?