Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Аналитическая инфраструктура оптимизации рекламной сети       Александр Зайцев           LifeStreet
О себе• ВМК МГУ 1999• 15 лет в разработке• 13 лет в стартапах• 10лет разработки распределенных систем  большой нагрузки• 5...
План выступления•   Как работает рекламная сеть•   Что такое оптимизация рекламной сети•   Постановка технической проблемы...
Что такое рекламная сеть                           RTB Buy                         RTB SellVisitors           Publishers  ...
Экономика рекламной сети                                $$$Visitors            Publishers                Ad Network       ...
Что такое оптимизация• Что, где, когда, кому и как показывать• Сколько платить за показ в RTB• Задача сети – наилучшим обр...
Как происходит оптимизация• Много-много экспериментов (тестов)  – Ручные и автоматические  – A/B split, multi-variant• Ave...
Круговорот экспериментов          Работа                                         ETL         системы               Run    ...
Типы анализа• Эксперимент – сравнить с эталоном• AdHoc– задать произвольный вопрос и  быстро получить ответ• Алгоритмическ...
Причем тут HighLoad?• Рекламные сети = большие нагрузки  – Сотни миллионов, миллиарды показов  – Кластеры фронтендов  – Те...
Аналитическая инфраструктура            Confidential
Что такое аналитическая инфраструктура1. Логгирование и сбор данных (ETL)2. Организация и хранение данных3. Средства досту...
Требования к инфраструктуре•   Скорость загрузки•   Latency(отставание)•   Скорость ответа•   Гибкость запросов•   Расширя...
Онтология•   Что представляют собой данные•   Как их интерпретировать•   Меняется со временем•   Бывает недоопределенной  ...
Требования к модели данных• Оптимизация рекламы = многомерный  анализ (статистический)  – Многомерные кубы (сотни измерени...
Кубы, сечения, проекцииТипичный аналитический запрос:range scan + group by на маленькое подмножество измерений            ...
Возможные решения• Бэкенд:  – Традиционная RDBMS  – Нетрадиционная (специализированная) RDBMS  – NoSQL(Dynаmo-like или Had...
Компромиссы     Confidential
Гибридные решения               Единая точка доступа    NoSQL              RDBMS                HadoopБыстро, негибко,    ...
О LifeStreet• Основана в 2005                                          Facebook Apps• Запуск реклмной сети в FaceBookв 200...
LifeStreetв цифрах•   ~300M показов в день•   ~1100М бидов в день•   Десятки ручных тестов в день•   Десятки тысяч автомат...
Эволюционные шаги•   2007 MySQL•   2008 Oracle•   2009 MySQL+TokuDB•   2010 Vertica•   2012 Vertica + Cassandra           ...
Некоторые очевидные принципы• Много данных – узкое место диск  –   Нормализация – короткие ключи  –   Денормализация – иер...
Упрощенная модель данных• Star или snow flake схема   – Fact = произошло событие   – Dimension = свойство события   – Metr...
MySQL• 100GB DWH (5 лет назад)• Пакетная загрузка• Аттрибуция ключейчерез хранимую процедуру• Активное использование temp ...
Oracle•   Как надстройка за MySQL•   ETL ->MySQL table ->csv -> Oracle•   MVsвместо агрегатов•   Проблемы    – Сильная зав...
MySQLcTokuDB•   Масштабирование MySQL для OLAP•   Компрессия данных и индексов (~ в 5 раз)•   Кластеризующие индексы (инде...
Чем плохи B-Trees – inserts             * From MySQL UC 2010 Tokutek presentation             Confidential
Чем плохи B-Trees – range scans               * From MySQL UC 2010 Tokutek presentation               Confidential
TokuDB–компрессия                       * From Percona 2009 benchmark        Confidential
TokuDB–inserts                      * From Percona 2009 benchmark       Confidential
Выбор альтернативы• Критерии выбора:  –   Column store (почему?)  –   Scalability and failover (cluster)  –   Скорость тип...
Итак, Vertica• Колонки!• Эффективная компрессия данных    – Много стратегий    – У нас в среднем в 13 раз (в TokuDBв 5 раз...
Физическое представление• Проекции (projection)  – Подмножество колонок с сортировкой  – Для каждой таблицы есть супер-про...
Выполнение запросов• Только «нужные» колонки• Сильно зависит от структуры проекций (не  таблиц)• Есть автоматический DB-de...
Блоки RLE• RLE – run length encoding• Идеально для колонок с низкой кардинальностьюGender   Age           Impressions     ...
Блоки RLE• RLE – run length encoding• Идеально для колонок с низкой кардинальностьюGender   Age           Impressions     ...
Загрузка данных• Две зоны хранения:  – WOS (in-memory)  – ROS (on-disk)  – Перенос из WOS в ROS автоматический• Загрузка б...
Кластер• 3..N узлов• Конфигурируется на уровне проекции  – Несегментированные – каждая нода полные    данные  – Сегментиро...
Требования к ETL• Масштабирование• Равномерная загрузка (балансировка)• Устойчивость к сбоям:  – Сети  – Софта  – Кривые д...
ETL• LMS «собирает» логи с серверов, и распределяет их по ETL•5мин лог, 3000 файлов в час, 10-30К записей в файле (тяжелый...
Многоуровневый Failover• Сбой ETL  – Переключение на другой  – Есть резервные в запасе• Сбой внутри кластера  – Сбой диска...
“One size does not fit all”• Michael Stonebreaker’sstartups:  – StreamBase – CEP  – Vertica – OLAP  – VoltDB – OLTP• У нас...
Многообразие систем                                                    Плюсы:                                             ...
Аналитика реального времениAd Server       Ad Server                   Ad Server            Непрерывный поток            (...
Аналитика реального времениAd Server   Ad Server                     Ad Server            Минутные сбросы            счетч...
Субъективностьаналитики• Отражает состояние миракак его ощущает  рантайм• Искажает его собственными моделями  восприятия  ...
СПАСИБО!   Confidential
Upcoming SlideShare
Loading in …5
×

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

2,763 views

Published on

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

  1. 1. Аналитическая инфраструктура оптимизации рекламной сети Александр Зайцев LifeStreet
  2. 2. О себе• ВМК МГУ 1999• 15 лет в разработке• 13 лет в стартапах• 10лет разработки распределенных систем большой нагрузки• 5 лет разработки аналитической инфраструктуры рекламной сети Confidential
  3. 3. План выступления• Как работает рекламная сеть• Что такое оптимизация рекламной сети• Постановка технической проблемы• Возможные решения• Как это делаем мыв LifeStreet Confidential
  4. 4. Что такое рекламная сеть RTB Buy RTB SellVisitors Publishers Ad Network Advertisers Affiliates AffiliatesGeo Web sites CampaignsDevice Applications best match AdsHistory Slots Landing pages Confidential
  5. 5. Экономика рекламной сети $$$Visitors Publishers Ad Network Advertisers $$ $$ • Flat CPM (мы платим за показы) • RPA (нам платят за клиентов) •RevShare % •RevShare риск риск Время Confidential
  6. 6. Что такое оптимизация• Что, где, когда, кому и как показывать• Сколько платить за показ в RTB• Задача сети – наилучшим образом использовать все показы: – Наилучшим для рекламодателя – больше клиентов – Наилучшим для рекламной площадки – выше CPM Confidential
  7. 7. Как происходит оптимизация• Много-много экспериментов (тестов) – Ручные и автоматические – A/B split, multi-variant• Averages lie – Надо «дробить» статистику – Проблема репрезентативности объема• Data Mining• Зависимость от времени: – Рынок все время меняется – Объявления «устают» Confidential
  8. 8. Круговорот экспериментов Работа ETL системы Run Collect Средства Action Analyze Организация управления и хранение Средства доступа и анализа Confidential
  9. 9. Типы анализа• Эксперимент – сравнить с эталоном• AdHoc– задать произвольный вопрос и быстро получить ответ• Алгоритмический – автоматические алгоритмы (machine learning)• Моделирование Мира – как бы вела себя сеть, если бы условия были другими Confidential
  10. 10. Причем тут HighLoad?• Рекламные сети = большие нагрузки – Сотни миллионов, миллиарды показов – Кластеры фронтендов – Терабайты логов И все это бесполезно без возможности анализа и оптимизации Confidential
  11. 11. Аналитическая инфраструктура Confidential
  12. 12. Что такое аналитическая инфраструктура1. Логгирование и сбор данных (ETL)2. Организация и хранение данных3. Средства доступа/анализа Confidential
  13. 13. Требования к инфраструктуре• Скорость загрузки• Latency(отставание)• Скорость ответа• Гибкость запросов• Расширяемость схемы• Масштабируемость КОМПРОМИССЫ• Отказоустойчивость !• Нефункциональные: – Цена – Commodity hardware Confidential
  14. 14. Онтология• Что представляют собой данные• Как их интерпретировать• Меняется со временем• Бывает недоопределенной – Браузеры – Мобильные устройства• Модель данных – реализация онтологии• Идеальный мир – модель генерируется из онтологии (например, из OWL) Confidential
  15. 15. Требования к модели данных• Оптимизация рекламы = многомерный анализ (статистический) – Многомерные кубы (сотни измерений) – Произвольные сечения (фильтры) – Произвольные проекции (агрегирование) – Объединения кубов Confidential
  16. 16. Кубы, сечения, проекцииТипичный аналитический запрос:range scan + group by на маленькое подмножество измерений N-dimensional range cube сечение M- dimensional projection Confidential
  17. 17. Возможные решения• Бэкенд: – Традиционная RDBMS – Нетрадиционная (специализированная) RDBMS – NoSQL(Dynаmo-like или Hadoop) – Гибридные решения• Загрузка: – Пакетная – Непрерывная Confidential
  18. 18. Компромиссы Confidential
  19. 19. Гибридные решения Единая точка доступа NoSQL RDBMS HadoopБыстро, негибко, Гибко и Очень гибко имасштабируемо достаточно очень не быстро быстро Confidential
  20. 20. О LifeStreet• Основана в 2005 Facebook Apps• Запуск реклмной сети в FaceBookв 2008• Крупнейшая рекламная сетьв приложениях FaceBookc 2010 (выбили Google)• Запуск рекламной сети в мобильных приложениях в 2011• Ежеквартальный рост доходов• 3/4 технологии, 1/4 бизнес Mobile Apps Confidential
  21. 21. LifeStreetв цифрах• ~300M показов в день• ~1100М бидов в день• Десятки ручных тестов в день• Десятки тысяч автоматических тестов в день – Можно также считать, что показ = тест (или много)• ~3TB ежедневно обрабатываемых данных• 350+ измерений (125 независимых), 80+ метрик Confidential
  22. 22. Эволюционные шаги• 2007 MySQL• 2008 Oracle• 2009 MySQL+TokuDB• 2010 Vertica• 2012 Vertica + Cassandra Confidential
  23. 23. Некоторые очевидные принципы• Много данных – узкое место диск – Нормализация – короткие ключи – Денормализация – иерархии, агрегирование – Временные таблицы для промежуточных этапов – Кэши – Партиционирование по времени – Random vs. sequential IO• Данные теряют ценность со временем – Удаление старых данных – Разные стратегии удаления для разной гранулярности Confidential
  24. 24. Упрощенная модель данных• Star или snow flake схема – Fact = произошло событие – Dimension = свойство события – Metric = количественная характеристика факта• Денормализация – Иерархии (одна таблица, ключ по самому нижнему уровню) • Час <День< Месяц<Год • Слот<Сайт< Publisher – Многочисленные агрегаты • Оптимизированы под разные use cases Confidential
  25. 25. MySQL• 100GB DWH (5 лет назад)• Пакетная загрузка• Аттрибуция ключейчерез хранимую процедуру• Активное использование temp tables и memory (hash index)• Факты/агрегаты – MyISAM, измерения – InnoDB• Проблемы с ростом размера таблиц и индексов Confidential
  26. 26. Oracle• Как надстройка за MySQL• ETL ->MySQL table ->csv -> Oracle• MVsвместо агрегатов• Проблемы – Сильная зависимость от DBA – MVs очень тяжело поддерживать Confidential
  27. 27. MySQLcTokuDB• Масштабирование MySQL для OLAP• Компрессия данных и индексов (~ в 5 раз)• Кластеризующие индексы (индекс+данные вместе)• Fractal-tree индексы (fractional cascading)• Неблокирующее добавление индексов*• Неблокирующее добавление колонок*• Проблемы – Неэффективные планы в некоторых случаях – Некластер* Появились после того, как мы перестали использовать Confidential
  28. 28. Чем плохи B-Trees – inserts * From MySQL UC 2010 Tokutek presentation Confidential
  29. 29. Чем плохи B-Trees – range scans * From MySQL UC 2010 Tokutek presentation Confidential
  30. 30. TokuDB–компрессия * From Percona 2009 benchmark Confidential
  31. 31. TokuDB–inserts * From Percona 2009 benchmark Confidential
  32. 32. Выбор альтернативы• Критерии выбора: – Column store (почему?) – Scalability and failover (cluster) – Скорость типичных OLAP запросов – Поддержка, документация и т.п.• Тест-проект на системах: – GreenPlum – CalpointInfiniDB – ParAccel – Vertica• Verticaвыиграла с большим отрывом Confidential
  33. 33. Итак, Vertica• Колонки!• Эффективная компрессия данных – Много стратегий – У нас в среднем в 13 раз (в TokuDBв 5 раз)• Нет индексов!• Очень быстрая загрузка (можно параллельно)• Simply Fast• MPP• Ноль администрирования (почти) Confidential
  34. 34. Физическое представление• Проекции (projection) – Подмножество колонок с сортировкой – Для каждой таблицы есть супер-проекция = все колонки – Возможны pre-join проекции• Тип кодирования колонок: • RLE • DELTAVAL • BLOCK_DICT • Etc.12 разных способов• Группы колонок (фрагменты строк)• Сортировка (особенно важна для RLE)• Сегментация по узлам кластера Confidential
  35. 35. Выполнение запросов• Только «нужные» колонки• Сильно зависит от структуры проекций (не таблиц)• Есть автоматический DB-designer – Дизайн по данным (наилучшее хранение) – Дизайн по конкретным запросам• Ключевые инструменты – RLE с сортировкой и сегментация – Предикаты по отсортированной колонке = индексы – Джойны – merge, hash – Группировка Confidential
  36. 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. 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. 38. Загрузка данных• Две зоны хранения: – WOS (in-memory) – ROS (on-disk) – Перенос из WOS в ROS автоматический• Загрузка большими порциями очень быстрая• Удаление и апдейты – плохо – Удаление – метка – Апдейты – удаление + добавление – «Сборка мусора» • При переносе из WOS в ROS • При объединении ROS-контейнеров • По команде Confidential
  39. 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. 40. Требования к ETL• Масштабирование• Равномерная загрузка (балансировка)• Устойчивость к сбоям: – Сети – Софта – Кривые данные• Онтология – Трудность поддержки динамических измерений• Исходные данные: – Логи рекламных серверов – Адаптер, интегрированный в сервер Confidential
  41. 41. ETL• LMS «собирает» логи с серверов, и распределяет их по ETL•5мин лог, 3000 файлов в час, 10-30К записей в файле (тяжелый JSON)• Двухфазный (по историческим причинам), Java+bsh+sql• Latency 20-30 минут Confidential
  42. 42. Многоуровневый Failover• Сбой ETL – Переключение на другой – Есть резервные в запасе• Сбой внутри кластера – Сбой диска: • Замена узла на резервный • Замена диска и возвращение узла в резерв – Сбой узла: • Замена узла на резервный • Заказ нового резервного узла• Сбой кластера – Переключение на резервный (полная работающая копия со своим ETL-кластером) Confidential
  43. 43. “One size does not fit all”• Michael Stonebreaker’sstartups: – StreamBase – CEP – Vertica – OLAP – VoltDB – OLTP• У нас тоже – разные случаи: – Внешние пользователи • Ограниченная гибкость, легкие запросы – Внутренние пользователи • Максимальная гибкость, любые запросы – Машины (optimizer, pacing controller etc.) • Ограниченная гибкость, тяжелые запросы, минимальная latency Confidential
  44. 44. Многообразие систем Плюсы: • Распределение нагрузкиRuntime General Optimizer • Снижает риски DWH DWH DWH Минусы: • Сложнее поддерживать • Целостность данных StandBy DWHPacing Internal/Externa OptimizerLearning l usersMonitoring Financial master Confidential
  45. 45. Аналитика реального времениAd Server Ad Server Ad Server Непрерывный поток (возможно, небольшими пакетами) • Имплементировано в Zynga Vertica • 100+ nodes cluster • 5+ TB/day •Сырые данные потом дополнительно обрабатываются • В случае сбоя сети данные теряются Confidential
  46. 46. Аналитика реального времениAd Server Ad Server Ad Server Минутные сбросы счетчиков • Идея Twitter Rainbird •Cassandra Counters Cassandra • Гибкость сильно ограничена • Работает для простых случаев • Устойчива к сетевым проблемам Confidential
  47. 47. Субъективностьаналитики• Отражает состояние миракак его ощущает рантайм• Искажает его собственными моделями восприятия Confidential
  48. 48. СПАСИБО! Confidential

×