2. Пара цифр о Badoo
• 270М пользователей
• 5М новых фото в день
• 400К регистраций в сутки
• 3К серверов
• 70К RPS на PHP-FPM
3. Что мы обсудим
• Зачем анализировать
события в проекте?
• Что можно подвергнуть
анализу?
• Какие средства и решения
вы можете для этого
использовать?
8. Pinba
• MySQL-extension
• Все данные in-memory
• Транспорт: GPB over UDP
• Поддерживает таймеры, теги,
агрегации
• Клиенты для PHP, Java, Go,
Python, Ruby, JS, модуль nginx
15. Нюансы
• события одного типа собираются на
один MySQL-хост
• нет поддержки составных типов
данных
• разнородность событий — проблемы
при добавлении атрибутов
• нет единого flow обработки
18. Требования продуктов
• говорить с разработкой
«на одном языке»
• настраиваемые разрезы
и агрегаты
• апдейты каждые несколько
минут
• дашборды, графики, таблички!!!
20. Качественные требования
• возможность масштабирования
• отказоустойчивость
• высокая производительность
• работа с миллионами метрик
• долговременное хранение сырых
данных
21.
22. Unified Data Stream (UDS)
• язык описания данных
• сбор событий с
application-серверов
• обработка
• визуализация
• долговременное хранение
23. Описание событий
• специальный формат
• кодогенерация для backend
• формат при отправке: JSON
(помним про хотелку tail/grep)
25. Транспорт — берем готовый?
• О, да это просто! Есть же куча
готовых!
• Ага, но еще есть:
– Текущая инфраструктура
– Требования к доставке
– Гетерогенность событий
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-
директории, и запустить обработку
каждой строки»
38. Концепция изменилась!
• Подсчет агрегаций на MR
отличается от SQL
• Поток разнородных событий, с
разными наборами вычислений,
надо преобразовать в
гомогенный
• Для каждого события надо
посчитать пермутации из его
разрезов
45. Вычисление метрик
• Метрика — сумма одинаковых
проекций, посчитанная за интервал
NOW() - N минут
• Для каждого из желаемых
интервалов берем данные из
сохраненных агрегатов
• Повторяем процедуру
суммирования
49. Мысли вслух
●
Комбинаций — сотни тысяч
●
К каждой — hash с user_id
●
Не, ну ладно — bitset
●
На каждую комбинацию —
сотня мегабайт
●
Не успеем считать суточные
агрегации
50. «Почти честное» решение
●
HyperLogLog — вероятностная
структура для подсчета
уникальных значений
●
Настраивается процент
погрешности (больше памяти →
меньше ошибка)
●
0.5% погрешности ~ 32Kb на
объект
52. Что мы научились
●
80/20 — принцип Паретто
●
count/sum/avg/min/max/first/last
●
approx distinct
●
Да, пока нет перцентилей и
точного DISTINCT
●
Но возможность прикрутить-то
имеется!
53. Пучок цифр и фактов
●
300К events/sec в пике (больше
пока не придумали :)
●
25 серверов в Hadoop-кластере
(не только для нашей задачи)
●
В 300 раз уменьшили объем данных
для анализа (за счет замены сырых
данных на агрегаты)
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
