Казалось бы, услуги таргетированной рекламы уже достаточно автоматизированы. И наша команда дата-инженеров решила взглянуть на некоторые привычные технологии под другим углом. Наконец, мы нашли новые действенные решения для клиента.
В этой статье я поделюсь интересными находками и опишу, что нужно учитывать каждому, кто захочет повторить подобное.
Вспомним принципы таргетированной рекламы
Когда-то для размещения баннеров в интернете нужно было договариваться напрямую с владельцами рекламных ресурсов. Они определяли стоимость услуги, собирали информацию о своей аудитории, сообщали количество кликов.
Со временем все эти шаги удалось автоматизировать благодаря таким сервисам:
- Supply-Side Platform. Эти платформы управляют рекламными местами на сторонних сайтах и приложениях. Их главная цель — продать рекламные места пользователей такого сервиса по выгодной цене. Также SSP предоставляет исчерпывающую информацию о посетителях. Фактически это сторона предложения на рынке.
- Demand-Side Platform. Созданы для размещения рекламы на площадках, предлагаемых SSP. Они формируют запросы, то есть спрос. DSP помогает рекламодателям размещать объявления на качественных площадках по минимальной цене.
- Real-Time Bidding. Это механизм рекламных аукционов в режиме настоящего времени. В нем принимают участие SSP и DSP. Принцип работы RTB изображен на этой схеме:
Что именно происходит:
- Пользователь заходит в мобильное приложение, где есть баннеры.
- Информация об этом входе передается SSP, управляющей рекламными местами в этом приложении.
- Далее создается запрос к сервису, проводимому аукционом — AD Exchange.
- Он посылает бид-реквест на все DSP, на которые подписана SSP (в изображенном примере их три).
- Все платформы делают возвращаемые ставки к сервису-аукциону.
- Сервис сравнивает ставки.
- Кто поставил больше, тот и получает право разместить баннер в приложении. Все происходит автоматически, за доли секунды.
В контексте нашей темы следует упомянуть и следующие термины:
- User Acquisition — процесс поиска новых клиентов, привлечение внимания к сайту или приложению с помощью рекламы. Это база рекламной деятельности как таковой.
- Ретаргетинг — это направление рекламы на ту аудиторию, которая уже знакома с презентуемым продуктом. Здесь внимание акцентируется на использовании определенного сайта или приложения.
Переходим к проекту. Какая цель перед нами стояла?
Наша команда должна была усовершенствовать систему таргетированной рекламы, которая модифицировала и оптимизировала User Acquisition и ретаргетинг. Масштабы деятельности этой системы действительно поразительны. В среднем сервис обрабатывает почти миллион реквестов в секунду! К тому же трафик поступает из многих регионов: от США и Бразилии в Европу и Японию.
Сервис построен на многих модулях, поэтому стек технологий очень разнообразен:
- Для хендлинга бид-реквестов мы использовали бидер, главный модуль реквестов хендлинга, написанный на Scala. Для его API берем стек Akka-библиотек. Также они требуются для других модулей на Scala.
- Для передачи бид-реквестов — в качестве месседж-брокера выбрали Apache Kafka. Он может не только передавать другим модулям рекламу о ставках, но и выдерживать значительную нагрузку в режиме реального времени.
- Для обработки массивов данных — применяем Spark Job для различных целей по обработке таких больших объемов информации.
- Для фронтенда используем Angular. Сервис, управляющий API фронтенда, написан на Java с применением фреймворка Spring.
- Для прогнозирования ставки требуется мощный инструмент предсказания оптимального уровня цены за рекламный показ. С этим помог Python с PMML-моделями.
- Для сохранения информации MySQL выбрали для данных, которые должны храниться более недели, для часто изменяемых данных и кэша — Aerospike и Redis, а для аналитических данных — Apache и Druid.
- Для работы с логами взяли Elasticsearch. Платформа генерирует множество логов. С таким массивом он лучше справится.
- Веб-сервисы. Для деплоя и других связанных задач мы подключили множество AWS-сервисов: EC2, ECS, EMR, S3, S3 Glacier и т.д.
Разница между Redis и Aerospike
Наверняка вы обратили внимание на использование одновременно Redis и Aerospike. Но ведь это NoSQL-базы со схожим функционалом. Почему бы тогда не оставить одну из них? Но нам нужны оба варианта (у нас это опенсорс-версии).
Здесь следует учитывать их отличия — критические для нашего проекта:
- Использование флеш-памяти. Сервис генерирует множество данных, которые трудно хранить только в оперативной памяти. Redis в бесплатной версии работает только с RAM. Aerospike этой проблемы нет, поэтому мы используем с ним SSD.
- Поддержка триггеров. У Aerospike отсутствует такой функционал, а вот у Redis он есть. Для нашего проекта это очень важно. Мы используем publish/subscribe-механизм для некоторых данных, и их изменение должно триггерит конкретный метод.
- Горизонтальный скейлинг. В отличие от Aerospike Redis плохо масштабируется на горизонтальном уровне. Эта БД больше подходит для хендлинга большой нагрузки.
- Консистентность данных. Redis не гарантирует консистентность данных, что для нашего проекта критично. У Aerospike есть полная поддержка этого.
- AWS-интеграции. Redis успешно интегрирован с Amazon Web Services через ElastiCache. У Aerospike этого нет. Он деплоится фактически только на EC2-инстанции.
Как работает Reporting UI
В проекте все модули по-своему интересны. И я бы выделил две наиболее нетипичные части. Первая — Reporting UI. Этот модуль отправляет репорты, но реализуемый механизм отличается от привычных методов. Обычно репорты с важной бизнес-информацией поступают на email или разные BA-инструменты.
В нашем случае репорты можно посылать еще в Slack. В этом мессенджере происходит вся коммуникация по проекту.
Мы добавили и другие функции:
- возможность получать репорт о прибыли в канале в Slack в виде детализированной диаграммы;
- подписка на нужные репорты;
- интеграция с командами в чате, чтобы с помощью ботов сгенерировать репорт прибыли по конкретному SSP (этот способ доставки репортов оценили и бизнес-аналитики, и заказчик).
Техническая реализация модуля не сложная. Сначала мы делаем запрос на Amazon Athena для получения нужной информации по бид-логам. Эти данные приводим в нужные для репортов форматы. Далее остается выбрать путь рассылки: на email, у Slack-канал или чат-бот (если есть соответствующая команда).
На иллюстрации ниже пример такого репорта. Здесь представлен график с данными о прибыли и некоторыми цифрами. Две линии обозначают данные сегодня и вчера.
Другой интересный модуль — это Stopper
В определенный момент количество клиентов сервиса резко возросло. Чтобы повысить гибкость конфигурации и скейлинга системы, появилась необходимость перейти на более модульную архитектуру. Но после апдейта в модулях возникали ошибки, что приводило к потерям денег.
Обычно зафиксировать эти проблемы просто, ведь у нас много аналитических данных и метрик. Нужно было остановить бидер и исправить баг. Тогда мы решили сделать высокоуровневый Exception Handler, наш Stopper. Его цель — автоматизировать идентификацию проблем и остановку хендлинга реквестов.
Реализация Stopper довольно проста:
Как правило, для отслеживания проблем мы смотрим на количество ивентов и лаг некоторых топиков на Kafka. Наш модуль либо смотрит на лаг, либо считывает количество ивентов, проходящих через топик.
Поскольку мы понимаем нормативные показатели, то можем выставлять минимальные и максимальные уровни для топиков и тайм задержки. При превышении или недостатке ивентов данные об этих проблемах отправляются в MySQL-таблицу. Там Stopper проверяет информацию и решает: останавливать хендлинг реквестов или нет.
Также на схеме вы могли заметить Redis. Это объясняется тем, что сейчас тестируем остановку реквестов еще и по этой базе данных. Если количество ключей станет критически большим или сильно уменьшится, система должна сделать все то же, что и для Kafka.
Что следует учесть перед началом работы?
1 Не нужно загонять себя в рамки одного решения
Как видите, одной NoSQL-базой дело не ограничились. Это позволило нам объединить все лучшее из Redis и Aerospike, увеличить возможности расширения системы и в конечном счете сэкономить деньги, что также ценит бизнес.
2 Используйте привычные подходы и инструменты необычным способом
Мы попытались отправлять важную BA-информацию в мессенджеры. Это не так уж традиционно в большинстве проектов, но оттого и интересно. И что важно — такое решение в разы повысило мобильность бизнес-аналитиков.
3 Автоматизируйте все, что можно
Даже если кажется, что это невозможно — ищите варианты реализации. Все реально. Мы в этом убедились на примере с хендлингом некоторых эксэпшенов, который освободил часть ресурсов наших специалистов.
Успехов!
Читайте также: Зарплата $68 тыс. в год: как стать дата-инженером — дорожная карта
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: