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.

Арсен Мукучян, AdRiver

2,544 views

Published on

HighLoad++ 2013

  • Be the first to comment

Арсен Мукучян, AdRiver

  1. 1. Как мы храним 60000 событий в секунду Арсен Мукучян ведущий разработчик
  2. 2. Вопросы, на которые отвечу ● Кто мы и что делаем? ● Зачем нам события? ● Что было не так? ● Почему велосипед? ● Как же он едет?
  3. 3. Кто мы? ● 16 лет → рост трафика х2000раз ● 60К (~40К) в секунду ● 2012год → 1.011.958.233.880 запросов ● comScore: май2013: U.S. - 20млрд. ↔ AdRiver - 60млрд. ● 200Тб данных
  4. 4. Кто мы? Сайт AdRiver
  5. 5. Как это работает? AdRiver Подсистема выбора рекламных материалов ы ос р ап З Базы информации о пользователях Интернет ? Базы настроек кампаний Ре к ла мн ые Базы-справочники База информации о пользователях ма те р иа л 1Тб ы
  6. 6. Что такое событие? 0.1 - 2Кб
  7. 7. Сколько их?
  8. 8. Зачем нам события? AdRiver Интернет За пр о Подсистема выбора рекламных материалов сы - от в Подсистема хранения событий ет ы Подсистемы анализа событий
  9. 9. Зачем нам события? AdRiver Интернет За пр о Подсистема выбора рекламных материалов сы - от в ет ы Отчетность по факту оказания услуг Заказчики Подсистема хранения событий Подсистемы анализа событий
  10. 10. Зачем нам события? AdRiver Интернет За пр о Подсистема выбора рекламных материалов сы - от в ет ы Отчетность по факту оказания услуг Оценка эффективности кампаний Заказчики Подсистема хранения событий Подсистемы анализа событий
  11. 11. Зачем нам события? AdRiver Интернет За пр о Подсистема выбора рекламных материалов сы - от в ет ы Отчетность по факту оказания услуг Оценка эффективности кампаний Заказчики Подсистема хранения событий Прочая интересная аналитика Подсистемы анализа событий
  12. 12. Зачем нам события? AdRiver Интернет За пр о Подсистема хранения событий Подсистема выбора рекламных материалов сы - от в ет ы Из ре мене кл ам ние ны на х м стр ате оек ри ал выбо ов ра Отчетность по факту оказания услуг Оценка эффективности кампаний Заказчики Прочая интересная аналитика Подсистемы анализа событий
  13. 13. Зачем нам события? ● Типовая отчетность ● Управление эффективностью ● Аналитика онлайн: действия пользователя → критерии выбора ● Прочая интересная аналитика
  14. 14. Аналитика: эффективная частота 12000 10000 8000 6000 Пользователи 4000 2000 0 1 2 3 4 5 6 7 8 9 10
  15. 15. Аналитика: пост-клик анализ Искал дату выхода Nexus5 понедельник Купить Nexus5 в магазине нексусов Увидел баннер Кликнул по баннеру среда Купил Nexus5 в магазине Перешел в магазин суббота t
  16. 16. Аналитика: наведение на баннер Искал дату выхода Nexus5 Люди, которые видели баннер Увидел Люди, которые «водили» по баннеру баннер Увидел баннер «Водил» по баннеру Анализ Анализ наведений наведений Увидел Настройка настроенный баннер кампании Кликнул по баннеру t
  17. 17. Аналитика: ядро аудитории Заполняют survey Смотрят интересную рекламу
  18. 18. Аналитика: предсказание вероятности взаимодействия P .8 =3 % P = 0.72% Каждый конкретный пользователь P= 24%
  19. 19. Аналитика: «поисковая строка» Бронетанковый чебурашка Ввел поисковый запрос 15:04:28.829 Бронетанковый чебурашка: альтернативные результаты поиска Перешел на сайт из выдачи Увидел баннер 15:04:29.114 15:04:39.114 Перешел на целевой сайт 15:04:42.067 t
  20. 20. Выводы ● События нужно хранить ● Аналитика нужна для основных услуг ● Аналитика — фундамент новых продуктов ● Нужно качество
  21. 21. Как это раньше работало? Инструмент получения типовых отчетов Инструмент минимальной оценки эффективности События Инструмент анализа аудиторий Syslog
  22. 22. Что было не так? Инструмент получения типовых отчетов X События X Инструмент минимальной оценки эффективности X Инструмент анализа аудиторий X X Syslog
  23. 23. Когда перестало работать? 9000000000 8000000000 7000000000 Событий в сутки 6000000000 5000000000 4000000000 3000000000 2000000000 1000000000 0 2000 2001 2002 2003 2004 2005 2006 2007 Год Syslog 2008 2009 2010 2011 2012 2013 2014 2015
  24. 24. Что требуется? ● Успеть записать — 400Тб за год, 100K в сек ● Консистентность — непротиворечивость ● Обеспечить чтение — ~1К клиентов к ~1трлн событий, 500К в сек ● Надежность — 100% ● Масштабируемость — объем, скорость ● Отказоустойчивость — self recovery ● Стоимость — 1 x 42u, 32А
  25. 25. На чем поедем? vs
  26. 26. Что попробовали? MySQL+InnoDB Hadoop+HBase Disco Последние версия и год 5.5.30, 2013 1.0.3, 0.94.5, 2012 0.2.1, 2009 Объем данных 2Тб 2Тб 500Гб Железо 2x16ядер 8x12ядер 8x12ядер Объем хранилища 16Тб 16Тб 2Тб Запись в кластер 100K в сек 100К в сек 60К в сек Чтение с кластера 100К в сек 800К в сек 5К в сек Железа в итоге 6u >42u >42u Что еще Партиционирование руками, один мастер, мало параллельных запросов Дорого Дорого, нужна разработка
  27. 27. Нужен велик!
  28. 28. Забегая вперед... Количество серверов 10 Характеристики серверной единицы SuperMicro XEON X5450 8core, 16Гб RAM, 25Тб RAID-SATA Объем данных 400Тб (200Тб пакованных) Количество параллельных клиентов До 2000 Запись/Чтение с ноды 100К в сек / 400К в сек Исходящий трафик До 20Гбит/сек Время разработки Меньше года Платформа x86_64, Gentoo/Debian Linux Язык разработки с++ Интерфейсы с++, python, shell
  29. 29. Как же он ездит? ● Взгляд сверху ● Запись — что пишем? ● Консистентность — как синхронизируем? ● Чтение — как читаем? ● Подходы, проблемы и решения ● Итог
  30. 30. Взгляд сверху Сге Подсистема выбора рекламных материалов нер иро Кластерное хранилище History ван Под тв е рж ден и ык апрос З Подсистемы аналитики и Подсистема выбора подсчета статистики рекламных материалов ны е со Нода 1 бы тия я м данны ... MUX е анны Д я заци они инхр стера С ла нод к Нода 2 Нода 9 Нода 10
  31. 31. 0 1 Категория Страница сайта Зона страницы 3 4 5 6 7 8 Мета информация 9 Данные Группа куки Кука Тип баннера Кампания Баннер Сеть Тип сети Сайт 2 Тип события Источник Идентификатор Время 10 11 12 13 14 ... Ставка RTB Событие — единица информации 94
  32. 32. Запись событий Подсистема выбора рекламных материалов Подсистема History События 1 - 1000 Источник 1 подтверждения Нода X Индекс данных Источник N подтверждения [1,1000] Источник N События 1 - 1000 Источник 1 [1,1000] Час данных
  33. 33. Синхронизация событий Нода 1 Индекс событий: 2 Нода 2 Индекс событий: 1 / 2 Состояние данных Доступные мощности Запрос данных: 1 / 2 Данные: 1 / 2 События 1 t События 2
  34. 34. Как это выглядит в реальности? Подсистема выбора рекламных материалов Подсистема History Нода 1 Нода 4 Нода 2 Нода 5 Нода 7 Нода 3 Нода 6 Нода 8 Нода 9 Клиенты Клиенты
  35. 35. Чтение событий Клиент Подсистема History Нода 1 Индекс событий: K Индекс событий: 1 / K Состояние данных Доступные мощности Запрос данных: 1 / K Данные: 1 / K События 1 События K t
  36. 36. Подход:  Один компонент ↔ Одна функция
  37. 37. Подход: один компонент → одна функция Подсистема выбора рекламных материалов Другие ноды History Клиенты History Manager History Server Нода К History Writer Файл Writer'а Файл Server'а
  38. 38. Подход: уменьшение объема данных  Один компонент ↔ Одна функция  Лучшая оптимизация → → Алгоритмическая оптимизация Объем данных Скорость обработки
  39. 39. Подход: уменьшение объема данных Нода К History Writer Процессор Память Intranet History Manager History Server Дисковый кеш Диск
  40. 40. Проблема: мало памяти
  41. 41. Проблема: мало памяти Решение: потоковая схема хранения и последовательная логика обработки 45Гб Память Очередное событие
  42. 42. Подход: страничная файловая организация и сжатие страниц Клиент Событие History Writer History Server Страница данных Паковка: lzo, zip, bzip Пакованная страница Файл Пакованная страница
  43. 43. Подход: представление данных ● Собственный протокол ● Напоминает Google protobuf ● Перед записью её размер → → можно их пропускать при чтении ● Более богатый выбор типов данных ● Тонкая оптимизация под конкретную задачу
  44. 44. Подход: горизонтальное масштабирование данных Подсистема выбора рекламных материалов Подмножество событий 1 Подмножество событий 2 Подмножество событий 3 History Группа Нода нод 1 1 Группа Группа нод 44 нод Группа Нода нод 2 2 Группа Нода нод 5 2 Группа Нода нод 3 2 Группа Нода нод 6 2
  45. 45. Задача: увеличить скорость получения событий
  46. 46. Задача: увеличить скорость получения событий History Запрос одного часа данных Клиент Считает аналитику для сайта N Все события запрошенного часа Обработка событий сайта N
  47. 47. 0 1 Категория Страница сайта Зона страницы 3 4 5 6 7 8 9 Группа куки Кука Тип баннера Кампания Баннер Сеть Тип сети Сайт 2 Тип события Источник Идентификатор Время 10 11 12 13 14 Данные Мета информация Дополнительный ключ данных ... Ставка RTB Задача: увеличить скорость получения событий 94
  48. 48. Задача: увеличить скорость получения событий Клиент Запрос одного часа данных, передача дополнительного ключа — сайт N Считает аналитику для сайта N Все события запрошенного часа Все события сайта N за час Обработка событий сайта N Объем данных Скорость чтения на 2-5 порядков History
  49. 49. Задача: уменьшить latency Подсистема выбора рекламных материалов Клиент Задержка — 0.1сек Нода Writer Память Диск
  50. 50. Итог: показатели ноды ● 500 клиентов ● 3000 файлов ● 100К в сек / 400К в сек ● 2 Гбит/сек ● 2-4Гб памяти ● 20-40% CPU
  51. 51. Итог: задача решена Количество серверов 10 Характеристики серверной единицы SuperMicro XEON X5450 8core, 16Гб RAM, 25Тб RAID-SATA Объем данных 400Тб (200Тб пакованных) Количество параллельных клиентов До 2000 Запись/Чтение с ноды 100К в сек / 400К в сек Исходящий трафик До 20Гбит/сек Время разработки Меньше года Платформа x86_64, Gentoo/Debian Linux Язык разработки с++ Интерфейсы с++, python, shell
  52. 52. Спасибо за внимание! arsen@adriver.ru

×