Near-realtime аналитика событий в высоконагруженном проекте...

Near-realtime аналитика событий в высоконагруженном проекте

Крашенинников АлександрBadoo

Пара цифр о Badoo

• 270М пользователей

• 5М новых фото в день

• 400К регистраций в сутки

• 3К серверов

• 70К RPS на PHP-FPM

Что мы обсудим

• Зачем анализировать события в проекте?

• Что можно подвергнуть анализу?

• Какие средства и решения вы можете для этого использовать?

Зачем что-то анализировать?

Хочешь улучшить ― измерь!

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

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

Технические метрики

• RPS

• SQL запросы

• кэш

• взаимодействия с сервисами

Pinba• MySQL-extension

• Все данные in-memory

• Транспорт: GPB over UDP

• Поддерживает таймеры, теги, агрегации

• Клиенты для PHP, Java, Go, Python, Ruby, JS, модуль nginx

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

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

Не подойдет для продуктовых метрик

• Нужны сырые данные для кастомных аналитических запросов

• Данные нужны в широком диапазоне (часы, сутки)

Продуктовые метрики

• количество регистраций

• отправка сообщений/лайков

• загрузки медийного контента

• источники трафика

StatsCollector• Внутренняя разработка BI Badoo

• Сбор событий в MySQL

• Счетчики, шардинг

• Он доставляет!!!

• Ссылка в конце доклада :)

StatsCollector

Нюансы• события одного типа собираются на

один MySQL-хост

• нет поддержки составных типов данных

• разнородность событий — проблемы при добавлении атрибутов

• нет единого flow обработки

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

Сбор требований

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

Требования продуктов

• говорить с разработкой «на одном языке»

• настраиваемые разрезы и агрегаты

• апдейты каждые несколько минут

• дашборды, графики, таблички!!!

Требования разработчиков

• минимум усилий

• единый API отправки событий

• отладка на сырых данных

• функциональность tail/grep

Качественные требования

• возможность масштабирования

• отказоустойчивость

• высокая производительность

• работа с миллионами метрик

• долговременное хранение сырых данных

Unified Data Stream (UDS)

• язык описания данных

• сбор событий с application-серверов

• обработка

• визуализация

• долговременное хранение

Описание событий

• специальный формат

• кодогенерация для backend

• формат при отправке: JSON (помним про хотелку tail/grep)

Тело события

Транспорт — берем готовый?

• О, да это просто! Есть же куча готовых!

• Ага, но еще есть:– Текущая инфраструктура– Требования к доставке– Гетерогенность событий

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

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

• Доставляет надежно

• Плавали — знаем

• Но он же legacy!

• И падает иногда

Ладно, пока возьмем...

Транспорт — а сами?

• Live Streaming Daemon (LSD)

– Из приложения пишем в файлы– Дальше — как scribe,

только лучше– Coming open-source soon!

Flow событий в ДЦ

App(web, cloud)> 1K hosts

Аггрегатор< 10 hosts

Обработка на Агрегаторе

• запись в файлы (а-ля logrotate)• gzip

• inotify

• В случае недоступности HDFS — буфер на 24 часа

Структура в HDFS

• /local/UDS/– /date=2015-01-01/

● /hour=00/

udshost1.mlan_001.gzudshost1.mlan_002.gzudshost2.mlan_001.gz…

– /date=2015-02-02/

Пробуем обработать — Hive

• SQL-подобный интерфейс над данными в файлах на HDFS

• «Мои запросы могут показаться тебе странными …» (несколько экранов)

• Обработка суточных данных занимает очень много времени (а хочется realtime)

Как ускорить обработку?

• Divide and conquer!

• Вычислить агрегаты в коротких временных интервалах, и сохранить

• Для расчета суточных/месячных/годовых данных использовать сумму агрегатов

Apache Spark

● Фреймворк для распределенной обработки данных

• Интеграция с Hadoop

• Данные in-memory

• Streaming API «из коробки»

Apache Spark - Streaming

• Строго говоря, это batching

• Можно грабить корованы выполнять map-reduce

• Весь входящий поток событий превращается в гомогенную коллекцию, размещенную в памяти машин кластера

Streaming API

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

Streaming API

• Я умею wc -l !!!

• strings.map(inputLine → 1).reduce(

(cnt1, cnt2) → cnt1 + cnt2)

).count() // 42

Концепция изменилась!• Подсчет агрегаций на MR

отличается от SQL

• Поток разнородных событий, с разными наборами вычислений, надо преобразовать в гомогенный

• Для каждого события надо посчитать пермутации из его разрезов

Обработка события

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

Обработка события

1. Берем 2 свеклы JSON-path

2. Парсим значимые поля события, согласно конфигурации (hello, products!)

3. Множим по числу комбинаций

4. Суммируем одинаковые комбинации

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

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

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

Хранение агрегатов• /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

Вычисление метрик

• Метрика — сумма одинаковых проекций, посчитанная за интервал NOW() - N минут

• Для каждого из желаемых интервалов берем данные из сохраненных агрегатов

• Повторяем процедуру суммирования

Результат вычислений

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

Что делать с результатами

• Отправка в time-series хранилища (rrd, Influx, etc.)

• Сохранение в базу данных

• Дашборды, графики, таблички!!!

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

Мысли вслух

● Комбинаций — сотни тысяч● К каждой — hash с user_id● Не, ну ладно — bitset ● На каждую комбинацию —

сотня мегабайт● Не успеем считать суточные

агрегации

«Почти честное» решение

● HyperLogLog — вероятностная структура для подсчета уникальных значений

● Настраивается процент погрешности (больше памяти → меньше ошибка)

● 0.5% погрешности ~ 32Kb на объект

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

Что мы научились● 80/20 — принцип Паретто

● count/sum/avg/min/max/first/last● approx distinct

● Да, пока нет перцентилей и точного DISTINCT

● Но возможность прикрутить-то имеется!

Пучок цифр и фактов● 300К events/sec в пике (больше

пока не придумали :)● 25 серверов в Hadoop-кластере

(не только для нашей задачи)● В 300 раз уменьшили объем данных

для анализа (за счет замены сырых данных на агрегаты)

Scientia potencia est!

(Знание — сила)

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

задач

Where to go from here

1. tech.badoo.com/Техблог Badoo

2. pinba.orgReal-time аналитика вашего приложения

3. bit.ly/StatsCollector Доклад о StatsCollector

4. spark.apache.org

Спасибо за внимание,я готов ответить на Ваши

вопросы!

krash@corp.badoo.comkrash3@gmail.com

facebook.com/alex.krash