Схема разработки высоконагруженных систем для обработки данных на примере системы управления рекламой

Чтобы развивать свой продукт в интернете, бизнес собирает и анализирует данные: какие карточки товаров смотрят пользователи, а какие нет, с каких устройств пользователи заходят на сайт, из каких стран. Рассказываем, как проектируем решения, которые могут обрабатывать большие данные — за апрель наша система обработала 2,4 млрд показов и 408 млн кликов, и все обошлось без сбоев.

Один из способов заработать для интернет-бизнеса — управлять контентом так, чтобы пользователи как можно чаще совершали целевые действия. Контент в этом случае — общее обозначение, это могут быть:

• ролики;
• новости;
• карточки товаров или услуг;
• и что угодно еще.

Что будет целевым действием, тоже зависит от бизнеса. В одном случае — просмотр энного количества роликов, в другом — подписка на пробные уроки из рассылки.

Для управления контентом нужны данные о том, как именно пользователь работает с контентом. Может, он пропускает карточки товаров с наибольшей маржинальностью для компании или все-таки изучает, но не откладывает в корзину. Все это нужно, чтобы понять, как и что показывать пользователю.

Сам по себе массив данных мало что дает, поэтому его надо как-то сохранять и анализировать. Например:

• собирать статистические отчеты по срезам и метрикам;

• сравнивать эти же метрики за разные периоды;
• группировать данные по категориям: странам, городам, типам устройств или времени суток.

Без таких деталей сложно определить, почему какой-то контент срабатывает не так, как запланировали, и что делать для решения проблемы.

Когда данных немного, их можно обрабатывать вручную или с помощью простых программ. Но с ростом базы пользователей объем данных тоже увеличивается, поэтому обработать условный миллиард данных таким способом уже не получится.

Для обработки большого массива проектируют системы сбора и анализа данных. Основное требование для них — выдерживать высокую нагрузку.

У нас есть опыт в запуске систем, которые справляются с высокой нагрузкой. Поэтому на примере одного из проектов покажем свой подход к разработке.

О проекте. Каждый день рекламная сеть регистрирует события: ставки, которые делают пользователи на аукционах, просмотры рекламы, клики по объявлениям. Чтобы аналитики могли работать с данными, их нужно привести в читаемый формат — обработать и загрузить в программу с понятным интерфейсом.

Нагрузка системы. В апреле 2021 года система рекламной сети обработала:

• 2,4 млрд показов;
• 408 млн кликов;
  
• 1240 конверсий.
  

Анализ. Чтобы спроектировать систему, мы изучили тип и объем данных, прогнозируемый рост нагрузки, результат, который нужно получить, и ограничения по бюджету и ресурсам. После этого приступили уже к самой разработке.

Схема работы системы:

• Рекламная платформа регистрирует события в Apache Kafka.
• Collector Service следит за очередью событий в Apache Kafka, обогащает информацию о событии дополнительными данными и записывает информацию о событиях в файлы .csv.
• После завершения записи в файл Collector Service сжимает его и загружает этот файл в HDFS, в специальную директорию для входных данных.
• Каждые 5 минут Stats Service проверяет наличие новых необработанных файлов в директории входных данных на HDSF и формирует задачу для Apache Hadoop для расчета агрегированной статистики.
• Apache Hadoop рассчитывает статистику на основании входных данных и записывает полученные результаты в файлы в специальной директории на HDFS.
• Stats Server забирает результаты расчета статистики с HDFS и экспортирует данные в MySQL.
• Stats Server перемещает обработанные входные файлы в архив, расположенный также на HDFS. Файлы группируются по дням — это нужно для того, чтобы можно было пересчитать статистику за определенный период, если были какие-то ошибки в скриптах.

Результаты. Все компоненты архитектуры горизонтально масштабируются и обеспечивают отказоустойчивость.