5. Как это работает?
AdRiver
Подсистема выбора рекламных материалов
ы
ос
р
ап
З
Базы информации о пользователях
Интернет
?
Базы настроек кампаний
Ре
к
ла
мн
ые
Базы-справочники
База информации о пользователях
ма
те
р
иа
л
1Тб
ы
10. Зачем нам события?
AdRiver
Интернет
За
пр
о
Подсистема выбора
рекламных материалов
сы
-
от
в
ет
ы
Отчетность по факту оказания услуг
Оценка эффективности кампаний
Заказчики
Подсистема хранения событий
Подсистемы анализа событий
11. Зачем нам события?
AdRiver
Интернет
За
пр
о
Подсистема выбора
рекламных материалов
сы
-
от
в
ет
ы
Отчетность по факту оказания услуг
Оценка эффективности кампаний
Заказчики
Подсистема хранения событий
Прочая интересная аналитика
Подсистемы анализа событий
12. Зачем нам события?
AdRiver
Интернет
За
пр
о
Подсистема хранения событий
Подсистема выбора
рекламных материалов
сы
-
от
в
ет
ы
Из
ре мене
кл
ам ние
ны на
х м стр
ате оек
ри
ал выбо
ов
ра
Отчетность по факту оказания услуг
Оценка эффективности кампаний
Заказчики
Прочая интересная аналитика
Подсистемы анализа событий
13. Зачем нам события?
●
Типовая отчетность
●
Управление эффективностью
●
Аналитика онлайн:
действия пользователя → критерии выбора
●
Прочая интересная аналитика
16. Аналитика: наведение на баннер
Искал
дату
выхода
Nexus5 Люди, которые видели баннер
Увидел
Люди, которые «водили» по баннеру
баннер
Увидел
баннер
«Водил»
по
баннеру
Анализ
Анализ
наведений наведений
Увидел
Настройка настроенный
баннер
кампании
Кликнул
по
баннеру
t
19. Аналитика: «поисковая строка»
Бронетанковый чебурашка
Ввел
поисковый
запрос
15:04:28.829
Бронетанковый чебурашка:
альтернативные
результаты поиска
Перешел на
сайт из
выдачи
Увидел
баннер
15:04:29.114
15:04:39.114
Перешел
на
целевой
сайт
15:04:42.067
t
21. Как это раньше работало?
Инструмент получения
типовых отчетов
Инструмент минимальной
оценки эффективности
События
Инструмент анализа аудиторий
Syslog
22. Что было не так?
Инструмент получения
типовых отчетов
X
События
X
Инструмент минимальной
оценки эффективности
X
Инструмент анализа аудиторий
X
X
Syslog
24. Что требуется?
●
Успеть записать — 400Тб за год, 100K в сек
●
Консистентность — непротиворечивость
●
Обеспечить чтение — ~1К клиентов к ~1трлн событий, 500К в сек
●
Надежность — 100%
●
Масштабируемость — объем, скорость
●
Отказоустойчивость — self recovery
●
Стоимость — 1 x 42u, 32А
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
Что еще
Партиционирование
руками, один мастер,
мало параллельных
запросов
Дорого
Дорого, нужна
разработка
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. Как же он ездит?
●
Взгляд сверху
●
Запись — что пишем?
●
Консистентность — как синхронизируем?
●
Чтение — как читаем?
●
Подходы, проблемы и решения
●
Итог
30. Взгляд сверху
Сге
Подсистема выбора
рекламных материалов
нер
иро
Кластерное хранилище History
ван
Под
тв е
рж
ден
и
ык
апрос
З
Подсистемы аналитики и
Подсистема выбора
подсчета статистики
рекламных материалов
ны
е со
Нода 1
бы
тия
я
м
данны
...
MUX
е
анны
Д
я
заци
они
инхр стера
С
ла
нод к
Нода 2
Нода 9
Нода 10
31. 0
1
Категория
Страница сайта
Зона страницы
3
4
5
6
7
8
Мета информация
9
Данные
Группа куки
Кука
Тип баннера
Кампания
Баннер
Сеть
Тип сети
Сайт
2
Тип события
Источник
Идентификатор
Время
10 11 12 13 14
...
Ставка RTB
Событие — единица информации
94
32. Запись событий
Подсистема выбора
рекламных материалов
Подсистема History
События 1 - 1000
Источник 1
подтверждения
Нода X
Индекс данных
Источник N
подтверждения
[1,1000]
Источник N
События 1 - 1000
Источник 1
[1,1000]
Час
данных
33. Синхронизация событий
Нода 1
Индекс событий: 2
Нода 2
Индекс событий: 1 / 2
Состояние данных
Доступные мощности
Запрос данных: 1 / 2
Данные: 1 / 2
События 1
t
События 2
34. Как это выглядит в реальности?
Подсистема
выбора
рекламных
материалов
Подсистема History
Нода 1
Нода 4
Нода 2
Нода 5
Нода 7
Нода 3
Нода 6
Нода 8
Нода 9
Клиенты
Клиенты
35. Чтение событий
Клиент
Подсистема History
Нода 1
Индекс событий: K
Индекс событий: 1 / K
Состояние данных
Доступные мощности
Запрос данных: 1 / K
Данные: 1 / K
События 1
События K
t
37. Подход: один компонент → одна функция
Подсистема выбора
рекламных
материалов
Другие ноды History
Клиенты
History Manager
History Server
Нода К
History Writer
Файл Writer'а
Файл Server'а
38. Подход: уменьшение объема данных
Один компонент ↔ Одна функция
Лучшая оптимизация →
→ Алгоритмическая оптимизация
Объем
данных
Скорость обработки
39. Подход: уменьшение объема данных
Нода К
History
Writer
Процессор
Память
Intranet
History
Manager
History
Server
Дисковый
кеш
Диск
41. Проблема: мало памяти
Решение: потоковая схема хранения и последовательная логика обработки
45Гб
Память
Очередное событие
42. Подход: страничная файловая организация
и сжатие страниц
Клиент
Событие
History Writer
History Server
Страница данных
Паковка:
lzo, zip, bzip
Пакованная страница
Файл
Пакованная страница
43. Подход: представление данных
●
Собственный протокол
●
Напоминает Google protobuf
●
Перед записью её размер →
→ можно их пропускать при чтении
●
Более богатый выбор типов данных
●
Тонкая оптимизация под конкретную задачу
44. Подход: горизонтальное масштабирование данных
Подсистема выбора рекламных материалов
Подмножество
событий 1
Подмножество
событий 2
Подмножество
событий 3
History
Группа
Нода
нод 1 1
Группа
Группа
нод 44
нод
Группа
Нода
нод 2 2
Группа
Нода
нод 5 2
Группа
Нода
нод 3 2
Группа
Нода
нод 6 2
46. Задача: увеличить скорость получения событий
History
Запрос одного часа данных
Клиент
Считает
аналитику
для сайта N
Все события запрошенного часа
Обработка событий
сайта N
47. 0
1
Категория
Страница сайта
Зона страницы
3
4
5
6
7
8
9
Группа куки
Кука
Тип баннера
Кампания
Баннер
Сеть
Тип сети
Сайт
2
Тип события
Источник
Идентификатор
Время
10 11 12 13 14
Данные
Мета информация
Дополнительный ключ данных
...
Ставка RTB
Задача: увеличить скорость получения событий
94
48. Задача: увеличить скорость получения событий
Клиент
Запрос одного часа данных,
передача дополнительного ключа — сайт N
Считает
аналитику
для сайта N
Все события запрошенного часа
Все события сайта N за час
Обработка событий
сайта N
Объем данных
Скорость чтения на 2-5 порядков
History
50. Итог: показатели ноды
●
500 клиентов
●
3000 файлов
●
100К в сек / 400К в сек
●
2 Гбит/сек
●
2-4Гб памяти
●
20-40% CPU
51. Итог: задача решена
Количество серверов
10
Характеристики серверной
единицы
SuperMicro XEON X5450 8core,
16Гб RAM, 25Тб RAID-SATA
Объем данных
400Тб (200Тб пакованных)
Количество параллельных
клиентов
До 2000
Запись/Чтение с ноды
100К в сек / 400К в сек
Исходящий трафик
До 20Гбит/сек
Время разработки
Меньше года
Платформа
x86_64, Gentoo/Debian Linux
Язык разработки
с++
Интерфейсы
с++, python, shell
