Download - Арсен Мукучян, AdRiver
Как мы храним 60000 событий в секунду
Арсен Мукучянведущий разработчик
Вопросы, на которые отвечу
● Кто мы и что делаем?● Зачем нам события?● Что было не так?● Почему велосипед?● Как же он едет?
Кто мы?
● 16 лет → рост трафика х2000раз● 60К (~40К) в секунду● 2012год → 1.011.958.233.880 запросов● comScore: май2013: U.S. - 20млрд. ↔ AdRiver - 60млрд.● 200Тб данных
Кто мы?
Сайт AdRiver
Как это работает?
Интернет
Запросы
AdRiver
Подсистема выбора рекламных материалов
1Тб
Базы информации о пользователях
Базы настроек кампаний
База информации о пользователяхБазы-справочники
Рекламные материалы
?
Что такое событие?
0.1 - 2Кб
Сколько их?
Зачем нам события?
AdRiver
Подсистема выбора рекламных материалов
Подсистема хранения событий
Запросы-ответы
Подсистемы анализа событий
Интернет
Зачем нам события?
AdRiver
Подсистема выбора рекламных материалов
Подсистема хранения событий
Запросы-ответы
Подсистемы анализа событий
Интернет
Заказчики
Отчетность по факту оказания услуг
Зачем нам события?
AdRiver
Подсистема выбора рекламных материалов
Подсистема хранения событий
Запросы-ответы
Подсистемы анализа событий
Интернет
Оценка эффективности кампанийОтчетность по факту оказания услуг
Заказчики
Зачем нам события?
AdRiver
Подсистема выбора рекламных материалов
Подсистема хранения событий
Запросы-ответы
Подсистемы анализа событий
Интернет
Прочая интересная аналитика
Оценка эффективности кампанийОтчетность по факту оказания услуг
Заказчики
Зачем нам события?
AdRiver
Подсистема выбора рекламных материалов
Подсистема хранения событий
Запросы-ответы
Подсистемы анализа событий
Интернет
Прочая интересная аналитика
Оценка эффективности кампанийОтчетность по факту оказания услуг
Изменение настроек выбора
рекламных материалов
Заказчики
Зачем нам события?
● Типовая отчетность● Управление эффективностью● Аналитика онлайн:
действия пользователя → критерии выбора● Прочая интересная аналитика
Аналитика: эффективная частота
1 2 3 4 5 6 7 8 9 100
2000
4000
6000
8000
10000
12000
Пользователи
Аналитика: пост-клик анализ
Кликнулпо
баннеру
Купить Nexus5в магазине нексусов
Перешел в магазин
Купил Nexus5 в магазине
понедельник среда суббота t
Искал дату
выхода Nexus5
Увидел баннер
Аналитика: наведение на баннер
Люди, которые «водили» по баннеру
t
Искал дату
выхода Nexus5
Увидел баннер
«Водил» по
баннеру
Кликнулпо
баннеру
Анализ наведений
Анализ наведений
Увидел баннер
Настройкакампании
Люди, которые видели баннер
Увидел настроенный
баннер
Аналитика: ядро аудитории
Заполняют survey
Смотрят интересную рекламу
Аналитика: предсказание вероятности взаимодействия
Каждый конкретный пользователь
P = 3.8%
P = 0.72%
P = 24%
Аналитика: «поисковая строка»
15:04:28.829 15:04:29.114 15:04:42.067 t
Бронетанковый чебурашка Бронетанковый чебурашка:альтернативные
результаты поискаПерешел
на целевой
сайт
15:04:39.114
Перешел на сайт из выдачи
Увидел баннер
Ввел поисковый
запрос
Выводы
● События нужно хранить● Аналитика нужна для основных услуг● Аналитика — фундамент новых продуктов● Нужно качество
Как это раньше работало?
Инструмент получениятиповых отчетов
Инструмент минимальнойоценки эффективности
Инструмент анализа аудиторий
Syslog
События
Что было не так?
Инструмент получениятиповых отчетов
Инструмент минимальнойоценки эффективности
Инструмент анализа аудиторий
Syslog
События
X
X
X
X
X
Когда перестало работать?
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 20150
1000000000
2000000000
3000000000
4000000000
5000000000
6000000000
7000000000
8000000000
9000000000
Год
Собы
тий
в су
тки
Syslog
Что требуется?
● Успеть записать — 400Тб за год, 100K в сек
● Консистентность — непротиворечивость
● Обеспечить чтение — ~1К клиентов к ~1трлн событий, 500К в сек
● Надежность — 100%
● Масштабируемость — объем, скорость
● Отказоустойчивость — self recovery
● Стоимость — 1 x 42u, 32А
На чем поедем?
vs
Что попробовали?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
Что еще Партиционирование руками, один мастер,мало параллельных запросов
Дорого Дорого, нужна разработка
Нужен велик!
Количество серверов 10
Характеристики серверной единицы SuperMicro XEON X5450 8core, 16Гб RAM, 25Тб RAID-SATA
Объем данных 400Тб (200Тб пакованных)
Количество параллельных клиентов До 2000
Запись/Чтение с ноды 100К в сек / 400К в сек
Исходящий трафик До 20Гбит/сек
Время разработки Меньше года
Платформа x86_64, Gentoo/Debian Linux
Язык разработки с++
Интерфейсы с++, python, shell
Забегая вперед...
Как же он ездит?
● Взгляд сверху● Запись — что пишем?● Консистентность — как синхронизируем?● Чтение — как читаем?● Подходы, проблемы и решения● Итог
Взгляд сверху
Подсистема выборарекламных материалов
Кластерное хранилище History
MUX
Сгенерированные событияПодтверждения
Подсистема выборарекламных материалов
Подсистемы аналитики иподсчета статистики
Запросы к данным
Данные
Синхронизация
нод кластера
Нода 1 Нода 2
Нода 9 Нода 10
...
Событие — единица информации
Вре м
я
0 1 2 3 4 5 6 7 8И
с то ч
ник
Ид е
нти ф
и кат
орТи
п со
б ыти
яСа
й тКа
тего
р ия
Стра
н иц а
сай
таЗо
н а с
т ра н
ицы
Сеть
Тип
сет и
Камп
а ния
Банн
е р
Тип
б ан н
ера
Кука
Груп
п а к
у ки
9 10 11 12 13 14
...94
Став
к а R
T B
Мета информация
Данные
Запись событийПодсистема выборарекламных материалов
Источник 1
Источник N
Подсистема History
Нода XСобытия 1 - 1000
События 1 - 1000
Источник 1
Источник N [1,1000]
[1,1000]
Часданных
Индекс данныхподтверждения
подтверждения
Синхронизация событий
Нода 1 Нода 2
t
События 1 События 2
Индекс событий: 2
Индекс событий: 1 / 2
Состояние данных
Доступные мощности
Запрос данных: 1 / 2
Данные: 1 / 2
Как это выглядит в реальности?
Подсистема выборарекламных материалов
Подсистема History
Нода 1 Нода 2 Нода 3
Нода 4 Нода 5 Нода 6
Нода 7 Нода 8
Нода 9
КлиентыКлиенты
Чтение событий
Нода 1
Клиент
t
События 1События K
Индекс событий: K
Индекс событий: 1 / K
Состояние данных
Доступные мощности
Запрос данных: 1 / K
Данные: 1 / K
Подсистема History
Подход:
Один компонент ↔ Одна функция
Подход: один компонент → одна функция
History Writer
Нода К
Файл Writer'а
History Manager History Server
Файл Server'а
Подсистема выборарекламныхматериалов
Другие ноды History Клиенты
Подход: уменьшение объема данных
Один компонент ↔ Одна функция
Лучшая оптимизация →→ Алгоритмическая оптимизация
Объем данных
Скорость обработки
Подход: уменьшение объема данных
HistoryWriter
Нода К
Диск
HistoryManager
HistoryServer
Дисковыйкеш
Процессор
Память
Intranet
Проблема: мало памяти
Проблема: мало памяти
Решение: потоковая схема хранения и последовательная логика обработки
45ГбПамять
Очередное событие
Подход: страничная файловая организация и сжатие страниц
History Writer
Событие
Страница данных
Пакованная страница
Паковка:lzo, zip, bzip
Файл Пакованная страница
Клиент
History Server
Подход: представление данных
● Собственный протокол● Напоминает Google protobuf● Перед записью её размер →
→ можно их пропускать при чтении● Более богатый выбор типов данных● Тонкая оптимизация под конкретную задачу
Подход: горизонтальное масштабирование данных
Нода 2Группанод 2Нода 1
Группанод 1 Нода 2
Группанод 3
Нода 2Группанод 5 Нода 2
Группанод 6
Группанод 4
Группанод 4
Подсистема выбора рекламных материалов
Подмножествособытий 1
Подмножествособытий 2
Подмножествособытий 3
History
Задача: увеличить скорость получения событий
Задача: увеличить скорость получения событий
History
Клиент
Считаетаналитикудля сайта N
Запрос одного часа данных
Обработка событийсайта N
Все события запрошенного часа
Задача: увеличить скорость получения событий
Вре м
я
0 1 2 3 4 5 6 7 8И
с то ч
ник
Ид е
нти ф
и кат
орТи
п со
б ыти
яСа
й тКа
тего
р ия
Стра
н иц а
сай
таЗо
н а с
т ра н
ицы
Сеть
Тип
сет и
Камп
а ния
Банн
е р
Тип
б ан н
ера
Кука
Груп
п а к
у ки
9 10 11 12 13 14
...94
Став
к а R
T B
Мета информация
Данные
Дополнительный ключ данных
Задача: увеличить скорость получения событий
Запрос одного часа данных,передача дополнительного ключа — сайт N
Объем данных Скорость чтения на 2-5 порядков
History
Клиент
Считаетаналитикудля сайта N
Обработка событийсайта N
Все события запрошенного часаВсе события сайта N за час
Задача: уменьшить latencyПодсистема выбора
рекламныхматериалов
Нода
ДискПамять
Клиент
Writer
Задержка — 0.1сек
Итог: показатели ноды
● 500 клиентов● 3000 файлов● 100К в сек / 400К в сек● 2 Гбит/сек● 2-4Гб памяти● 20-40% CPU
Итог: задача решенаКоличество серверов 10
Характеристики серверной единицы
SuperMicro XEON X5450 8core, 16Гб RAM, 25Тб RAID-SATA
Объем данных 400Тб (200Тб пакованных)
Количество параллельных клиентов
До 2000
Запись/Чтение с ноды 100К в сек / 400К в сек
Исходящий трафик До 20Гбит/сек
Время разработки Меньше года
Платформа x86_64, Gentoo/Debian Linux
Язык разработки с++
Интерфейсы с++, python, shell
Спасибо за внимание!