Документ описывает процессинг данных на лямбда-архитектуре для платформы управления данными в рекламной технологии. Основное внимание уделяется сбору и анализу пользовательской активности, созданию профиля пользователей и эффективной сегментации для улучшения релевантности рекламы. Также обсуждаются плюсы и минусы использования этой архитектуры, включая оперативность и масштабируемость, а также сложности и затраты на реализацию.

1. Процессинг данных
на lambda-архитектуре
Препарируем Data Management Platform
ЮКОН 2016
Анатолий Никулин

2. Коротко об AdTech
● Advertiser Technology -
технологии для рекламодателей.
● Это $60 B (только в США)
● Это десятки-сотни тысяч событий
в секунду
● Как следствие большие объемы
данных и нагрузки.

3. Что нужно рекламодателям, чтобы быть
эффективными
● Надо продать удочки
● Можно показать рекламу
Всему честному люду
● Но лучше выделить
определенную
группу - “Рыбаки”
● Их на порядок меньше,
экономия на порядок больше

4. Как им в этом помочь?
● Сбор и анализ пользовательской активности.
● Формирование профиля пользователя (интересы, увлечения,
профессиональная деятельность)*
● Группировка пользователей по заданным критериям, чтобы
можно было более точно и эффективно настраивать рекламные
кампании.
● Сделать рекламу более релевантной для пользователя, и
эффективной для рекламодателя.
*Анонимно

5. Как следствие требования
● Обработка и хранение больших объемов
исторических данных
● Оперативность принятия решений
● Устойчивость к отказам
● Горизонтальная масштабируемость

6. Трекинг входящих событий

7. ESB как единая точка входа данных

8. Spark как маршрутизатор данных

9. HDFS как хранилище сырых данных
● Распределенная файловая система
● Поддержка репликации
(надежность, ускорение вычислений)
● Файлы в формате Parquet
(компактное хранение, эффективный
последовательный доступ)
● Храним очень долго

10. HBase как хранилище консолидированных
профилей
● Распределенное колонко-ориентированное
хранилище
● Структура не фиксирована. 10 000 колонок - это
нормально
● Позволяет обособленно хранить сложные структуры
данных. Поддерживает версионность
● Отлично интегрирована с фреймворками
распределенных вычислений (Spark, MapReduce)

11. HBase как хранилище консолидированных
профилей

12. Внешние поставщики данных (3rd party data
providers)
● Соц. дем. (возраст, пол, семейное положение,
наличие детей)
● Интересы (хобби, увлечения)
● Профессиональная деятельность. (Организация,
отрасль, годовой оборот)

13. ASE сегментация пользователей.
Взять всех, да и поделить!
● Разбить профили на группы (сегменты). Чтобы
показывать релевантную рекламу.
● Сегментов может быть произвольное количество
● У сегмента есть
Правило и время жизни
Пример:
Сегмент: Охотники и рыбаки
Мужчины, 30-45, Сибирь,
Visits: www.hunters.ru

14. ASE как функция

17. Это и есть лямбда?

18. Плюсы
● Оперативность принятия решений
● Хранение сырых данных ( immutable, append-only)
● Возможность анализа всего исторического датасета
● Возможность репроцессинга всего исторического датасета
● Горизонтальная масштабируемость
● Отказоустойчивость
Минусы
● Сложность реализации
● Дороговизна реализации и владения

19. Вопросы?