1. Аналитическая инфраструктура
оптимизации рекламной сети
Александр Зайцев
LifeStreet

2. О себе
• ВМК МГУ 1999
• 15 лет в разработке
• 13 лет в стартапах
• 10лет разработки распределенных систем
большой нагрузки
• 5 лет разработки аналитической
инфраструктуры рекламной сети
Confidential

3. План выступления
• Как работает рекламная сеть
• Что такое оптимизация рекламной сети
• Постановка технической проблемы
• Возможные решения
• Как это делаем мыв LifeStreet
Confidential

4. Что такое рекламная сеть
RTB Buy RTB Sell
Visitors
Publishers Ad Network Advertisers
Affiliates Affiliates
Geo Web sites Campaigns
Device Applications best match Ads
History Slots Landing pages
Confidential

5. Экономика рекламной сети
$$$
Visitors
Publishers Ad Network Advertisers
$$ $$
• Flat CPM (мы платим за показы) • RPA (нам платят за клиентов)
•RevShare % •RevShare
риск риск
Время
Confidential

6. Что такое оптимизация
• Что, где, когда, кому и как показывать
• Сколько платить за показ в RTB
• Задача сети – наилучшим образом
использовать все показы:
– Наилучшим для рекламодателя – больше
клиентов
– Наилучшим для рекламной площадки – выше
CPM
Confidential

7. Как происходит оптимизация
• Много-много экспериментов (тестов)
– Ручные и автоматические
– A/B split, multi-variant
• Averages lie
– Надо «дробить» статистику
– Проблема репрезентативности объема
• Data Mining
• Зависимость от времени:
– Рынок все время меняется
– Объявления «устают»
Confidential

8. Круговорот экспериментов
Работа
ETL
системы
Run Collect
Средства Action Analyze Организация
управления и хранение
Средства
доступа и
анализа
Confidential

9. Типы анализа
• Эксперимент – сравнить с эталоном
• AdHoc– задать произвольный вопрос и
быстро получить ответ
• Алгоритмический – автоматические
алгоритмы (machine learning)
• Моделирование Мира – как бы вела себя
сеть, если бы условия были другими
Confidential

10. Причем тут HighLoad?
• Рекламные сети = большие нагрузки
– Сотни миллионов, миллиарды показов
– Кластеры фронтендов
– Терабайты логов
И все это бесполезно без возможности
анализа и оптимизации
Confidential

11. Аналитическая инфраструктура
Confidential

12. Что такое аналитическая инфраструктура
1. Логгирование и сбор данных (ETL)
2. Организация и хранение данных
3. Средства доступа/анализа
Confidential

13. Требования к инфраструктуре
• Скорость загрузки
• Latency(отставание)
• Скорость ответа
• Гибкость запросов
• Расширяемость схемы
• Масштабируемость КОМПРОМИССЫ
• Отказоустойчивость !
• Нефункциональные:
– Цена
– Commodity hardware
Confidential

14. Онтология
• Что представляют собой данные
• Как их интерпретировать
• Меняется со временем
• Бывает недоопределенной
– Браузеры
– Мобильные устройства
• Модель данных – реализация онтологии
• Идеальный мир – модель генерируется из
онтологии (например, из OWL)
Confidential

15. Требования к модели данных
• Оптимизация рекламы = многомерный
анализ (статистический)
– Многомерные кубы (сотни измерений)
– Произвольные сечения (фильтры)
– Произвольные проекции (агрегирование)
– Объединения кубов
Confidential

16. Кубы, сечения, проекции
Типичный аналитический запрос:
range scan + group by на маленькое подмножество измерений
N-dimensional
range
cube
сечение
M-
dimensional
projection
Confidential

17. Возможные решения
• Бэкенд:
– Традиционная RDBMS
– Нетрадиционная (специализированная) RDBMS
– NoSQL(Dynаmo-like или Hadoop)
– Гибридные решения
• Загрузка:
– Пакетная
– Непрерывная
Confidential

18. Компромиссы
Confidential

19. Гибридные решения
Единая точка доступа
NoSQL RDBMS Hadoop
Быстро, негибко, Гибко и Очень гибко и
масштабируемо достаточно очень не быстро
быстро
Confidential

20. О LifeStreet
• Основана в 2005
Facebook Apps
• Запуск реклмной сети в FaceBookв 2008
• Крупнейшая рекламная сетьв
приложениях FaceBookc 2010 (выбили
Google)
• Запуск рекламной сети в мобильных
приложениях в 2011
• Ежеквартальный рост доходов
• 3/4 технологии, 1/4 бизнес Mobile Apps
Confidential

21. LifeStreetв цифрах
• ~300M показов в день
• ~1100М бидов в день
• Десятки ручных тестов в день
• Десятки тысяч автоматических тестов в день
– Можно также считать, что показ = тест (или
много)
• ~3TB ежедневно обрабатываемых данных
• 350+ измерений (125 независимых), 80+
метрик
Confidential

22. Эволюционные шаги
• 2007 MySQL
• 2008 Oracle
• 2009 MySQL+TokuDB
• 2010 Vertica
• 2012 Vertica + Cassandra
Confidential

23. Некоторые очевидные принципы
• Много данных – узкое место диск
– Нормализация – короткие ключи
– Денормализация – иерархии, агрегирование
– Временные таблицы для промежуточных этапов
– Кэши
– Партиционирование по времени
– Random vs. sequential IO
• Данные теряют ценность со временем
– Удаление старых данных
– Разные стратегии удаления для разной
гранулярности
Confidential

24. Упрощенная модель данных
• Star или snow flake схема
– Fact = произошло событие
– Dimension = свойство события
– Metric = количественная
характеристика факта
• Денормализация
– Иерархии (одна таблица, ключ
по самому нижнему уровню)
• Час <День< Месяц<Год
• Слот<Сайт< Publisher
– Многочисленные агрегаты
• Оптимизированы под разные use
cases
Confidential

25. MySQL
• 100GB DWH (5 лет назад)
• Пакетная загрузка
• Аттрибуция ключейчерез хранимую процедуру
• Активное использование temp tables и memory
(hash index)
• Факты/агрегаты – MyISAM, измерения –
InnoDB
• Проблемы с ростом размера таблиц и
индексов
Confidential

26. Oracle
• Как надстройка за MySQL
• ETL ->MySQL table ->csv -> Oracle
• MVsвместо агрегатов
• Проблемы
– Сильная зависимость от DBA
– MVs очень тяжело поддерживать
Confidential

27. MySQLcTokuDB
• Масштабирование MySQL для OLAP
• Компрессия данных и индексов (~ в 5 раз)
• Кластеризующие индексы (индекс+данные вместе)
• Fractal-tree индексы (fractional cascading)
• Неблокирующее добавление индексов*
• Неблокирующее добавление колонок*
• Проблемы
– Неэффективные планы в некоторых случаях
– Некластер
* Появились после того, как мы перестали использовать
Confidential

28. Чем плохи B-Trees – inserts
* From MySQL UC 2010 Tokutek presentation
Confidential

29. Чем плохи B-Trees – range scans
* From MySQL UC 2010 Tokutek presentation
Confidential

30. TokuDB–компрессия
* From Percona 2009 benchmark
Confidential

31. TokuDB–inserts
* From Percona 2009 benchmark
Confidential

32. Выбор альтернативы
• Критерии выбора:
– Column store (почему?)
– Scalability and failover (cluster)
– Скорость типичных OLAP запросов
– Поддержка, документация и т.п.
• Тест-проект на системах:
– GreenPlum
– CalpointInfiniDB
– ParAccel
– Vertica
• Verticaвыиграла с большим отрывом
Confidential

33. Итак, Vertica
• Колонки!
• Эффективная компрессия данных
– Много стратегий
– У нас в среднем в 13 раз (в TokuDBв 5 раз)
• Нет индексов!
• Очень быстрая загрузка (можно параллельно)
• Simply Fast
• MPP
• Ноль администрирования (почти)
Confidential

34. Физическое представление
• Проекции (projection)
– Подмножество колонок с сортировкой
– Для каждой таблицы есть супер-проекция = все
колонки
– Возможны pre-join проекции
• Тип кодирования колонок:
• RLE
• DELTAVAL
• BLOCK_DICT
• Etc.12 разных способов
• Группы колонок (фрагменты строк)
• Сортировка (особенно важна для RLE)
• Сегментация по узлам кластера
Confidential

35. Выполнение запросов
• Только «нужные» колонки
• Сильно зависит от структуры проекций (не
таблиц)
• Есть автоматический DB-designer
– Дизайн по данным (наилучшее хранение)
– Дизайн по конкретным запросам
• Ключевые инструменты – RLE с сортировкой и
сегментация
– Предикаты по отсортированной колонке = индексы
– Джойны – merge, hash
– Группировка
Confidential

36. Блоки RLE
• RLE – run length encoding
• Идеально для колонок с низкой кардинальностью
Gender Age Impressions
select sum(impressions) from t
1-20
where gender=‘M’ and age=‘21-25’
21-25
M
26-35
36+
1-20
21-25
F
26-35
36+
1 I/O 1 I/O 1 I/O
Confidential

37. Блоки RLE
• RLE – run length encoding
• Идеально для колонок с низкой кардинальностью
Gender Age Impressions
select sum(impressions) from t
1-20
where age=‘21-25’
21-25
M
26-35
36+
1-20
21-25
F
26-35
36+
2 I/O 2I/O
Confidential

38. Загрузка данных
• Две зоны хранения:
– WOS (in-memory)
– ROS (on-disk)
– Перенос из WOS в ROS автоматический
• Загрузка большими порциями очень быстрая
• Удаление и апдейты – плохо
– Удаление – метка
– Апдейты – удаление + добавление
– «Сборка мусора»
• При переносе из WOS в ROS
• При объединении ROS-контейнеров
• По команде
Confidential

39. Кластер
• 3..N узлов
• Конфигурируется на уровне проекции
– Несегментированные – каждая нода полные
данные
– Сегментированные – каждая нода 1/N данных
– K-safety level – уровень дублирования
– Полный контроль
1 2 3 4 5
A A A A A Несегментированная
A B C D E Сегментированная, K-
E A B C D safety=1 со смещением 1
Confidential

40. Требования к ETL
• Масштабирование
• Равномерная загрузка (балансировка)
• Устойчивость к сбоям:
– Сети
– Софта
– Кривые данные
• Онтология
– Трудность поддержки динамических измерений
• Исходные данные:
– Логи рекламных серверов
– Адаптер, интегрированный в сервер
Confidential

41. ETL
• LMS «собирает» логи с серверов, и распределяет их по ETL
•5мин лог, 3000 файлов в час, 10-30К записей в файле (тяжелый JSON)
• Двухфазный (по историческим причинам), Java+bsh+sql
• Latency 20-30 минут
Confidential

42. Многоуровневый Failover
• Сбой ETL
– Переключение на другой
– Есть резервные в запасе
• Сбой внутри кластера
– Сбой диска:
• Замена узла на резервный
• Замена диска и возвращение узла в резерв
– Сбой узла:
• Замена узла на резервный
• Заказ нового резервного узла
• Сбой кластера
– Переключение на резервный (полная работающая
копия со своим ETL-кластером)
Confidential

43. “One size does not fit all”
• Michael Stonebreaker’sstartups:
– StreamBase – CEP
– Vertica – OLAP
– VoltDB – OLTP
• У нас тоже – разные случаи:
– Внешние пользователи
• Ограниченная гибкость, легкие запросы
– Внутренние пользователи
• Максимальная гибкость, любые запросы
– Машины (optimizer, pacing controller etc.)
• Ограниченная гибкость, тяжелые запросы, минимальная
latency
Confidential

44. Многообразие систем
Плюсы:
• Распределение нагрузки
Runtime General Optimizer • Снижает риски
DWH DWH DWH
Минусы:
• Сложнее поддерживать
• Целостность данных
StandBy
DWH
Pacing Internal/Externa Optimizer
Learning l users
Monitoring Financial master
Confidential

45. Аналитика реального времени
Ad Server Ad Server Ad Server
Непрерывный поток
(возможно, небольшими
пакетами) • Имплементировано в
Zynga
Vertica • 100+ nodes cluster
• 5+ TB/day
•Сырые данные потом
дополнительно
обрабатываются
• В случае сбоя сети
данные теряются
Confidential

46. Аналитика реального времени
Ad Server Ad Server Ad Server
Минутные сбросы
счетчиков
• Идея Twitter Rainbird
•Cassandra Counters
Cassandra
• Гибкость сильно
ограничена
• Работает для простых
случаев
• Устойчива к сетевым
проблемам
Confidential

47. Субъективностьаналитики
• Отражает состояние миракак его ощущает
рантайм
• Искажает его собственными моделями
восприятия
Confidential

48. СПАСИБО!
Confidential