Арсен Мукучян, 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

Спасибо за внимание!

arsen@adriver.ru