Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI. Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime. Перед нами стояла задача сделать систему аналитики: + Горизонтально масштабируемой — уже не хватает ресурсов SQL. + Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта. + Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика. Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти. Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.

1. Near-realtime
аналитика событий в
высоконагруженном
проекте
Крашенинников
Александр
Badoo

2. Пара цифр о Badoo
• 270М пользователей
• 5М новых фото в день
• 400К регистраций в сутки
• 3К серверов
• 70К RPS на PHP-FPM

3. Что мы обсудим
• Зачем анализировать
события в проекте?
• Что можно подвергнуть
анализу?
• Какие средства и решения
вы можете для этого
использовать?

4. Зачем что-то анализировать?
Хочешь улучшить ― измерь!

5. Что вообще измерять?

6. Что вообще измерять?

7. Технические метрики
• RPS
• SQL запросы
• кэш
• взаимодействия с сервисами

8. Pinba
• MySQL-extension
• Все данные in-memory
• Транспорт: GPB over UDP
• Поддерживает таймеры, теги,
агрегации
• Клиенты для PHP, Java, Go,
Python, Ruby, JS, модуль nginx

9. Hit/miss у ключей «user_%»?

10. Какой запрос печалит кластер?

11. Не подойдет для продуктовых метрик
• Нужны сырые данные для
кастомных аналитических
запросов
• Данные нужны в широком
диапазоне (часы, сутки)

12. Продуктовые метрики
• количество регистраций
• отправка сообщений/лайков
• загрузки медийного контента
• источники трафика

13. StatsCollector
• Внутренняя разработка BI Badoo
• Сбор событий в MySQL
• Счетчики, шардинг
• Он доставляет!!!
• Ссылка в конце доклада :)

14. StatsCollector

15. Нюансы
• события одного типа собираются на
один MySQL-хост
• нет поддержки составных типов
данных
• разнородность событий — проблемы
при добавлении атрибутов
• нет единого flow обработки

16. Нужно свежее решение!

17. Сбор требований
Выясняем, что нужно пользователям
новой системы

18. Требования продуктов
• говорить с разработкой
«на одном языке»
• настраиваемые разрезы
и агрегаты
• апдейты каждые несколько
минут
• дашборды, графики, таблички!!!

19. Требования разработчиков
• минимум усилий
• единый API отправки событий
• отладка на сырых данных
• функциональность tail/grep

20. Качественные требования
• возможность масштабирования
• отказоустойчивость
• высокая производительность
• работа с миллионами метрик
• долговременное хранение сырых
данных

22. Unified Data Stream (UDS)
• язык описания данных
• сбор событий с
application-серверов
• обработка
• визуализация
• долговременное хранение

23. Описание событий
• специальный формат
• кодогенерация для backend
• формат при отправке: JSON
(помним про хотелку tail/grep)

24. Тело события

25. Транспорт — берем готовый?
• О, да это просто! Есть же куча
готовых!
• Ага, но еще есть:
– Текущая инфраструктура
– Требования к доставке
– Гетерогенность событий

26. Транспорт — опять scribe?

27. Транспорт — опять scribe?
• Доставляет надежно
• Плавали — знаем
• Но он же legacy!
• И падает иногда
Ладно, пока возьмем...

28. Транспорт — а сами?
• Live Streaming Daemon (LSD)
– Из приложения пишем в файлы
– Дальше — как scribe,
только лучше
– Coming open-source soon!

29. Flow событий в ДЦ
App
(web, cloud)
> 1K hosts
Аггрегатор
< 10 hosts

30. Обработка на Агрегаторе
• запись в файлы (а-ля logrotate)
• gzip
• inotify
• В случае недоступности HDFS —
буфер на 24 часа

31. Структура в HDFS
• /local/UDS/
– /date=2015-01-01/
●
/hour=00/
udshost1.mlan_001.gz
udshost1.mlan_002.gz
udshost2.mlan_001.gz
…
– /date=2015-02-02/

32. Пробуем обработать — Hive
• SQL-подобный интерфейс над
данными в файлах на HDFS
• «Мои запросы могут показаться
тебе странными …» (несколько
экранов)
• Обработка суточных данных
занимает очень много времени (а
хочется realtime)

33. Как ускорить обработку?
• Divide and conquer!
• Вычислить агрегаты в коротких
временных интервалах, и
сохранить
• Для расчета
суточных/месячных/годовых
данных использовать сумму
агрегатов

34. Apache Spark
●
Фреймворк для распределенной
обработки данных
• Интеграция с Hadoop
• Данные in-memory
• Streaming API «из коробки»

35. Apache Spark - Streaming
• Строго говоря, это batching
• Можно грабить корованы выполнять
map-reduce
• Весь входящий поток событий
превращается в гомогенную
коллекцию, размещенную в памяти
машин кластера

36. Streaming API
«Каждые 15 секунд проверить
наличие новых файлов в HDFS-
директории, и запустить обработку
каждой строки»

37. Streaming API
• Я умею wc -l !!!
• strings
.map(inputLine → 1)
.reduce(
(cnt1, cnt2) → cnt1 + cnt2)
).count() // 42

38. Концепция изменилась!
• Подсчет агрегаций на MR
отличается от SQL
• Поток разнородных событий, с
разными наборами вычислений,
надо преобразовать в
гомогенный
• Для каждого события надо
посчитать пермутации из его
разрезов

39. Обработка события
Задача: посчитать min/max/avg/sum
платежей за последние час и сутки,
в разрезе по стране и полу

40. Обработка события
1. Берем 2 свеклы JSON-path
2. Парсим значимые поля
события, согласно
конфигурации (hello, products!)
3. Множим по числу комбинаций
4. Суммируем одинаковые
комбинации

41. Большой взрыв события

42. Подсчет агрегатов

43. Суммирование проекций

44. Хранение агрегатов
• /data/uds/agg/
– /minute/
●
2015-10-01-04-00-00_2015-10-04-01-00
●
2015-10-01-04-01-00_2015-10-04-02-00
– /hour/
●
2015-10-01-02-00-00_2015-10-03-00-00
●
2015-10-01-03-00-00_2015-10-04-00-00

45. Вычисление метрик
• Метрика — сумма одинаковых
проекций, посчитанная за интервал
NOW() - N минут
• Для каждого из желаемых
интервалов берем данные из
сохраненных агрегатов
• Повторяем процедуру
суммирования

46. Результат вычислений
Все результаты сохранены в директориях
HDFS

47. Что делать с результатами
• Отправка в time-series хранилища
(rrd, Influx, etc.)
• Сохранение в базу данных
• Дашборды, графики, таблички!!!

48. Посчитайте уникальных юзеров!

49. Мысли вслух
●
Комбинаций — сотни тысяч
●
К каждой — hash с user_id
●
Не, ну ладно — bitset
●
На каждую комбинацию —
сотня мегабайт
●
Не успеем считать суточные
агрегации

50. «Почти честное» решение
●
HyperLogLog — вероятностная
структура для подсчета
уникальных значений
●
Настраивается процент
погрешности (больше памяти →
меньше ошибка)
●
0.5% погрешности ~ 32Kb на
объект

51. Удав, который проглотил слона

52. Что мы научились
●
80/20 — принцип Паретто
●
count/sum/avg/min/max/first/last
●
approx distinct
●
Да, пока нет перцентилей и
точного DISTINCT
●
Но возможность прикрутить-то
имеется!

53. Пучок цифр и фактов
●
300К events/sec в пике (больше
пока не придумали :)
●
25 серверов в Hadoop-кластере
(не только для нашей задачи)
●
В 300 раз уменьшили объем данных
для анализа (за счет замены сырых
данных на агрегаты)

54. Scientia potencia est!
(Знание — сила)

55. Есть простые инструменты
для решения ваших сложных
задач

56. Where to go from here
1. tech.badoo.com/
Техблог Badoo
2. pinba.org
Real-time аналитика вашего
приложения
3. bit.ly/StatsCollector
Доклад о StatsCollector
4. spark.apache.org

57. Спасибо за внимание,
я готов ответить на Ваши
вопросы!
krash@corp.badoo.com
krash3@gmail.com
facebook.com/alex.krash