Upload
ontico
View
423
Download
3
Embed Size (px)
Citation preview
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
Спасибо за внимание,я готов ответить на Ваши
вопросы!
[email protected]@gmail.com
facebook.com/alex.krash