Авторы Мариуш Домзалски, доктор философии и Якуб Всзолек, доктор философии
В DataMass.io мы создаем специализированные решения для обработки данных, от сбора и хранения данных до расширенной аналитики. У наших клиентов часто возникает вопрос, какие данные мы можем получить из общедоступных источников. Поэтому мы решили провести небольшой эксперимент. Мы выбрали данные о продажах для анализа. В первой статье цикла мы поговорим о доступе к публичному API одного из крупнейших продавцов электроники: BestBuy. Мы покажем, как легко построить систему для сбора и архивирования данных и какой анализ можно проводить. Простыми методами попробуем определить, есть ли что-то нетривиальное в данных, доступных через API. Следующий текст состоит из двух основных частей: описания архитектуры системы сбора данных и результатов анализа, который мы провели с данными.
Архитектура системы обработки данных
BestBuy - это американский транснациональный розничный продавец бытовой электроники, который предоставляет REST API, доступный для всех. Для доступа требуется бесплатная учетная запись (https://developer.bestbuy.com/), которая позволяет вам сгенерировать ключ, открывающий дверь для доступа к широкому спектру данных за всю историю BestBuy.com, включая продукт, магазин, категория и др. (https://developer.bestbuy.com/apis).
Мы решили ограничиться нашим исследованием только наиболее интересной (с нашей точки зрения) конечной точкой под названием Рекомендации. Это позволяет легко выбирать продукты Популярные, Самые просматриваемые и Также просматриваемые на основе поведения клиентов в BestBuy. Более подробную информацию о данных, которые хранятся за этими конечными точками, можно найти в главе Аналитика данных (3).
При рассмотрении современных систем приема данных был использован подход на основе акторов для создания надежных и многопоточных решений для обработки данных. Основное внимание в архитектуре решения уделялось его масштабируемости и поддержке модели, управляемой сообщениями. Мы также приняли решение использовать Kafka в качестве шины сообщений, доставляющей определения задач. Вся эта оркестровка была сделана в основном из-за того количества данных, которые требовались до того, как мы перешли к аналитике. Часто говорят, что распределенная обработка теоретически дает возможность выполнять задачи намного эффективнее, но на практике порождает и проблемы.
Можно задать вопрос, почему было использовано довольно сложное решение, такое как Akka, вместо написания нескольких скриптов Python, которые дали бы очень похожий конечный эффект. Итак, основным соображением было предоставление стабильной и отказоустойчивой платформы сбора данных для различных API. Мы также использовали полностью управляемый конфигурацией подход, когда сообщения несут метаинформацию об определении задачи. Фреймворк Akka очень хорошо подходит для поддержки разработчиков в достижении такой цели. Основываясь на нашем предыдущем опыте работы со Spark, мы решили выбрать Scala в качестве основного языка для реализации платформы сбора данных.
Экосистема Akka состоит из нескольких основных компонентов, которые кратко описаны ниже:
- Акторы являются основным блоком обработки для Akka, где каждый актор знает, как обрабатывать событие (или события), а также отвечает за отправку событий дочерним акторам для обработки подзадач.
- Akka придает первостепенное значение отказоустойчивости. Это имеет большое значение для создания отказоустойчивых приложений. Каждый субъект имеет стратегию наблюдения, с помощью которой он может контролировать поведение в ситуациях, когда дочерний субъект терпит неудачу.
- Actor-System отвечает за создание и запуск актеров.
- Маршрутизаторы обеспечивают оптимизированную обработку сообщений, эффективно получая сообщения и передавая их участникам [1].
Используя вышеуказанные шаблоны, было реализовано решение для сбора данных. Ниже представлена схема, на которой описаны основные элементы системы.
- Bestbuy open-api (https://developer.bestbuy.com/apis) - каталог конечных точек, который позволяет вам запрашивать продукты, магазины, категории и многое другое. Вся связь осуществляется по защищенному протоколу HTTP.
- Для каждой конечной точки создано три специализированных субъекта (трендовые, наиболее просматриваемые, также просматриваемые). Каждый из них связывается с соответствующей конечной точкой для получения необходимых данных в формате JSON. Также был разработан и реализован процесс ускорения более сложных задач (например, подкачки). Мы решили разделить их на более мелкие части, превратив их в подзадачи. Подзадачи могут взаимодействовать с главным процессом (актером), который постоянно отслеживает их статус.
- Актер-потребитель. Эти субъекты получают сообщения от Kafka и передают соответствующие инструкции выделенным субъектам (2). Эта методология позволяет нам также масштабировать все решение. Если мы можем наблюдать замедление обработки, довольно легко ее ускорить, добавив новых участников.
- Актер S3 - AWS Simple Storage Service - это наша судьба. Правильно сформированные актеры S3 играют роль доставки. Все данные, полученные от BestBuy API, помещаются в корзину S3. Это не просто push - объекты данных формируются в разделы, а затем присоединяются к сервису Athena.
- Scheduler - этот метод возвращает экземпляр akka.actor.Scheduler, который уникален для каждой ActorSystem и используется внутренне для планирования действий в определенные моменты времени.
- Актер журнала - журналы особенно важны в распределенных системах любого типа. Основным соображением было хранить все журналы в одном месте для более быстрого и удобного поиска. У нас есть агенты DataDog, установленные на каждой машине в кластере. Это дает нам возможность помещать журналы в один центральный репозиторий с возможностью визуализации и поиска в них.
Анализ данных
В рамках API рекомендаций BestBuy имеет 3 основные категории: «Тенденции», «Самые просматриваемые» и «Также просматриваемые».
Конечная точка Trending Products возвращает популярные продукты для данной категории или подкатегории. Самый популярный продукт - это продукт, у которого самая высокая частота обновления страницы в текущем 3-часовом окне по сравнению с предыдущим 3-часовым периодом. Например, продукт 1 имеет 1700 просмотров в первом окне, затем 1900 просмотров во втором окне, а продукт 2 имеет 600 просмотров в первом окне, а затем 1000 просмотров во втором окне. Продукт 2 будет выше, чем продукт 1 в рейтинге тенденций, потому что у него более высокий рост числа просмотров: увеличение на 400 просмотров на окно по сравнению с увеличением на 200 просмотров на окно для продукта 1.
ПРИМЕЧАНИЕ. Учитываются только товары с не менее 50 просмотров в час.
Собирая данные о популярных продуктах в определенных категориях каждые 3 часа, мы можем найти информацию, когда продукты популярны, а когда нет. Это интересно, особенно в контексте таких дней, как Черная пятница или праздничных распродаж. Однако для этого требуется непрерывный сбор данных. К сожалению, список трендовых товаров будет изменчивым, потому что некоторые товары появятся в нем на короткое время и исчезнут - преемственности не будет. Продукция обычно в тренде из-за агрессивной рекламной кампании, информации в СМИ или даже премьеры фильма. Эту информацию можно сопоставить с источниками новостей для изучения эффективности рекламных кампаний. Этот список, безусловно, более изменчив, чем список «Самые просматриваемые», поэтому он более подвержен влиянию внешних факторов.
Самые популярные просмотренные - это наиболее очевидная статистика, которая возвращает информацию о товарах, получивших наибольшее количество просмотров во всем магазине или в определенной категории или подкатегории. Он обновляется каждые 2 часа с максимальным периодом накопления 48 часов для продуктов из 10 ведущих мировых категорий.
В отличие от Trending Product, этот список меняется гораздо медленнее и отражает предпочтения потребителей в течение более длительного периода времени. Аналитику можно сделать, добавив переменную, зависящую от времени, для отслеживания сезонной популярности товаров - для потенциальных продавцов это информация о том, как подготовиться к разным сезонам.
Третий тип конечной точки, Также просматриваемый, возвращает 10 самых просматриваемых продуктов вместе с исходным продуктом. Это результат, полученный за последние 30 дней. В отличие от «Трендовых продуктов» и «Самые популярные просматриваемые продукты», здесь мы запрашиваем конечную точку для продукта, а не для категории.
В качестве примера использования этих данных мы построим график зависимостей продуктов на основе отношения «Также просматриваемые». Используя Python, помимо библиотеки для работы со службой Athena [2] и библиотеки NetworkX для анализа графов [3], мы использовали pandas, matplotlib и стандартную библиотека для обработки json. Мы не будем подробно описывать процесс сбора данных, потому что интересные вещи можно обнаружить непосредственно из анализа полученных графиков.
На рисунке 2 показан график, полученный после построения результатов запроса, ограничивающий количество продуктов, о которых мы спрашиваем, о том, что они также просматриваются, до 100.
Узлы графика указывают на отдельные товары в магазине. Ребра между узлами - это стрелки от исходных продуктов к соответствующим товарам, которые также просматриваются. Кроме того, соединительный край тем толще (и ему присвоен больший вес), чем выше продукт в рейтинге исходного продукта, который также просматривается. Наконец, цвет узла является результатом взвешенного алгоритма PageRank [4]. Те узлы, которые также просматриваются для наибольшего количества продуктов, имеют цвет, приближающийся к пурпурному, в то время как продукты, которые редко появляются в рейтинге также просматриваемых, имеют цвет, приближающийся к морскому.
Из рисунка выше мы видим две интересные вещи. Во-первых, у графа есть три связных компонента. Во-вторых, в каждом из подграфов один или несколько узлов доминируют как наиболее часто просматриваемые, тогда как остальные продукты не пользуются большой популярностью. Это результат нашего процесса сбора и того, как работает рекомендация «Также просматриваемые». На первом этапе мы собрали список «Также просматриваемые» для трех продуктов: телефона, ноутбука и умных часов. Затем мы повторили поиск результатов, собранных на первом этапе, по запросу «Также просматриваемые», получив таким образом результаты второго уровня. Еще через 2 шага рекурсивно мы достигли четвертого уровня. Так почему у нас 3 связанных подграфа? Оказывается, рекомендации "Также просматриваемые" всегда находятся в одной категории. Когда вы начинаете с умных часов, вы всегда останетесь в категории умных часов (подграф в правом нижнем углу).
Для тех, кто хочет расшифровать две другие категории, мы даем номера самых популярных товаров (в метрике Также просматриваемые) для каждого из подграфов, левый подграф - продукт BestBuy 6223303 и подграф в правом верхнем углу - продукт BestBuy 6339311. Для подграфа в нижнем левом углу (умные часы) наиболее популярным является продукт BestBuy 5706617. Подграф в правом верхнем углу имеет более похожие популярные узлы, это ноутбуки или телефоны?
Результаты аналогичны для запроса с 1000 товаров. Мы представляем их на рисунке 3.
Можете ли вы распознать, какая из категорий на Рисунке 3 соответствует категориям на Рисунке 2. Почему график в левом нижнем углу, несмотря на то, что он связан, имеет два разных подграфа? Что это за категория и в чем причина такой структуры? Это вопросы, с которыми мы сталкиваемся при анализе данных, и интересные ответы можно получить из структуры данных.
Выводы
- Благодаря используемым инструментам процесс сбора данных является масштабируемым и отказоустойчивым, но вы платите за это повышенной сложностью.
- Благодаря Amazon Athena доступ к данным становится простым, интуитивно понятным и легким.
- Общедоступный API предназначен для пользы владельца, поэтому вы мало что можете получить для своей выгоды.
- И, наконец, в этом случае мы точно знали интерпретацию данных, иногда у нас есть только графики, и мы должны делать какие-то выводы. И, как говорится в старой поговорке, рисунок стоит тысячи слов.
