Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Near-realtime
аналитика событий в
высоконагруженном
проекте
Крашенинников
Александр
Badoo
Пара цифр о Badoo
• 270М пользователей
• 5М новых фото в день
• 400К регистраций в сутки
• 3К серверов
• 70К RPS на PHP-FPM
Что мы обсудим
• Зачем анализировать
события в проекте?
• Что можно подвергнуть
анализу?
• Какие средства и решения
вы мож...
Зачем что-то анализировать?
Хочешь улучшить ― измерь!
Что вообще измерять?
Что вообще измерять?
Технические метрики
• RPS
• SQL запросы
• кэш
• взаимодействия с сервисами
Pinba
• MySQL-extension
• Все данные in-memory
• Транспорт: GPB over UDP
• Поддерживает таймеры, теги,
агрегации
• Клиенты...
Hit/miss у ключей «user_%»?
Какой запрос печалит кластер?
Не подойдет для продуктовых метрик
• Нужны сырые данные для
кастомных аналитических
запросов
• Данные нужны в широком
диап...
Продуктовые метрики
• количество регистраций
• отправка сообщений/лайков
• загрузки медийного контента
• источники трафика
StatsCollector
• Внутренняя разработка BI Badoo
• Сбор событий в MySQL
• Счетчики, шардинг
• Он доставляет!!!
• Ссылка в к...
StatsCollector
Нюансы
• события одного типа собираются на
один MySQL-хост
• нет поддержки составных типов
данных
• разнородность событий ...
Нужно свежее решение!
Сбор требований
Выясняем, что нужно пользователям
новой системы
Требования продуктов
• говорить с разработкой
«на одном языке»
• настраиваемые разрезы
и агрегаты
• апдейты каждые несколь...
Требования разработчиков
• минимум усилий
• единый API отправки событий
• отладка на сырых данных
• функциональность tail/...
Качественные требования
• возможность масштабирования
• отказоустойчивость
• высокая производительность
• работа с миллион...
Unified Data Stream (UDS)
• язык описания данных
• сбор событий с
application-серверов
• обработка
• визуализация
• долгов...
Описание событий
• специальный формат
• кодогенерация для backend
• формат при отправке: JSON
(помним про хотелку tail/gre...
Тело события
Транспорт — берем готовый?
• О, да это просто! Есть же куча
готовых!
• Ага, но еще есть:
– Текущая инфраструктура
– Требов...
Транспорт — опять scribe?
Транспорт — опять scribe?
• Доставляет надежно
• Плавали — знаем
• Но он же legacy!
• И падает иногда
Ладно, пока возьмем....
Транспорт — а сами?
• Live Streaming Daemon (LSD)
– Из приложения пишем в файлы
– Дальше — как scribe,
только лучше
– Comi...
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.gz
udshost1.mlan_002.gz
udshost2.mlan_001...
Пробуем обработать — Hive
• SQL-подобный интерфейс над
данными в файлах на HDFS
• «Мои запросы могут показаться
тебе стран...
Как ускорить обработку?
• 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....
Большой взрыв события
Подсчет агрегатов
Суммирование проекций
Хранение агрегатов
• /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-...
Вычисление метрик
• Метрика — сумма одинаковых
проекций, посчитанная за интервал
NOW() - N минут
• Для каждого из желаемых...
Результат вычислений
Все результаты сохранены в директориях
HDFS
Что делать с результатами
• Отправка в time-series хранилища
(rrd, Influx, etc.)
• Сохранение в базу данных
• Дашборды, гр...
Посчитайте уникальных юзеров!
Мысли вслух
●
Комбинаций — сотни тысяч
●
К каждой — hash с user_id
●
Не, ну ладно — bitset
●
На каждую комбинацию —
сотня ...
«Почти честное» решение
●
HyperLogLog — вероятностная
структура для подсчета
уникальных значений
●
Настраивается процент
п...
Удав, который проглотил слона
Что мы научились
●
80/20 — принцип Паретто
●
count/sum/avg/min/max/first/last
●
approx distinct
●
Да, пока нет перцентилей...
Пучок цифр и фактов
●
300К events/sec в пике (больше
пока не придумали :)
●
25 серверов в Hadoop-кластере
(не только для н...
Scientia potencia est!
(Знание — сила)
Есть простые инструменты
для решения ваших сложных
задач
Where to go from here
1. tech.badoo.com/
Техблог Badoo
2. pinba.org
Real-time аналитика вашего
приложения
3. bit.ly/StatsC...
Спасибо за внимание,
я готов ответить на Ваши
вопросы!
krash@corp.badoo.com
krash3@gmail.com
facebook.com/alex.krash
Near-realtime аналитика событий в высоконагруженном проекте
Upcoming SlideShare
Loading in …5
×

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

Near-realtime аналитика событий в высоконагруженном проекте. Доклад Александра Кашенинникова на Highload 2015
https://youtu.be/3XJhBRiVKW8

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

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

  1. 1. Near-realtime аналитика событий в высоконагруженном проекте Крашенинников Александр Badoo
  2. 2. Пара цифр о Badoo • 270М пользователей • 5М новых фото в день • 400К регистраций в сутки • 3К серверов • 70К RPS на PHP-FPM
  3. 3. Что мы обсудим • Зачем анализировать события в проекте? • Что можно подвергнуть анализу? • Какие средства и решения вы можете для этого использовать?
  4. 4. Зачем что-то анализировать? Хочешь улучшить ― измерь!
  5. 5. Что вообще измерять?
  6. 6. Что вообще измерять?
  7. 7. Технические метрики • RPS • SQL запросы • кэш • взаимодействия с сервисами
  8. 8. Pinba • MySQL-extension • Все данные in-memory • Транспорт: GPB over UDP • Поддерживает таймеры, теги, агрегации • Клиенты для PHP, Java, Go, Python, Ruby, JS, модуль nginx
  9. 9. Hit/miss у ключей «user_%»?
  10. 10. Какой запрос печалит кластер?
  11. 11. Не подойдет для продуктовых метрик • Нужны сырые данные для кастомных аналитических запросов • Данные нужны в широком диапазоне (часы, сутки)
  12. 12. Продуктовые метрики • количество регистраций • отправка сообщений/лайков • загрузки медийного контента • источники трафика
  13. 13. StatsCollector • Внутренняя разработка BI Badoo • Сбор событий в MySQL • Счетчики, шардинг • Он доставляет!!! • Ссылка в конце доклада :)
  14. 14. StatsCollector
  15. 15. Нюансы • события одного типа собираются на один MySQL-хост • нет поддержки составных типов данных • разнородность событий — проблемы при добавлении атрибутов • нет единого flow обработки
  16. 16. Нужно свежее решение!
  17. 17. Сбор требований Выясняем, что нужно пользователям новой системы
  18. 18. Требования продуктов • говорить с разработкой «на одном языке» • настраиваемые разрезы и агрегаты • апдейты каждые несколько минут • дашборды, графики, таблички!!!
  19. 19. Требования разработчиков • минимум усилий • единый API отправки событий • отладка на сырых данных • функциональность tail/grep
  20. 20. Качественные требования • возможность масштабирования • отказоустойчивость • высокая производительность • работа с миллионами метрик • долговременное хранение сырых данных
  21. 21. Unified Data Stream (UDS) • язык описания данных • сбор событий с application-серверов • обработка • визуализация • долговременное хранение
  22. 22. Описание событий • специальный формат • кодогенерация для backend • формат при отправке: JSON (помним про хотелку tail/grep)
  23. 23. Тело события
  24. 24. Транспорт — берем готовый? • О, да это просто! Есть же куча готовых! • Ага, но еще есть: – Текущая инфраструктура – Требования к доставке – Гетерогенность событий
  25. 25. Транспорт — опять scribe?
  26. 26. Транспорт — опять scribe? • Доставляет надежно • Плавали — знаем • Но он же legacy! • И падает иногда Ладно, пока возьмем...
  27. 27. Транспорт — а сами? • Live Streaming Daemon (LSD) – Из приложения пишем в файлы – Дальше — как scribe, только лучше – Coming open-source soon!
  28. 28. Flow событий в ДЦ App (web, cloud) > 1K hosts Аггрегатор < 10 hosts
  29. 29. Обработка на Агрегаторе • запись в файлы (а-ля logrotate) • gzip • inotify • В случае недоступности HDFS — буфер на 24 часа
  30. 30. Структура в 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/
  31. 31. Пробуем обработать — Hive • SQL-подобный интерфейс над данными в файлах на HDFS • «Мои запросы могут показаться тебе странными …» (несколько экранов) • Обработка суточных данных занимает очень много времени (а хочется realtime)
  32. 32. Как ускорить обработку? • Divide and conquer! • Вычислить агрегаты в коротких временных интервалах, и сохранить • Для расчета суточных/месячных/годовых данных использовать сумму агрегатов
  33. 33. Apache Spark ● Фреймворк для распределенной обработки данных • Интеграция с Hadoop • Данные in-memory • Streaming API «из коробки»
  34. 34. Apache Spark - Streaming • Строго говоря, это batching • Можно грабить корованы выполнять map-reduce • Весь входящий поток событий превращается в гомогенную коллекцию, размещенную в памяти машин кластера
  35. 35. Streaming API «Каждые 15 секунд проверить наличие новых файлов в HDFS- директории, и запустить обработку каждой строки»
  36. 36. Streaming API • Я умею wc -l !!! • strings .map(inputLine → 1) .reduce( (cnt1, cnt2) → cnt1 + cnt2) ).count() // 42
  37. 37. Концепция изменилась! • Подсчет агрегаций на MR отличается от SQL • Поток разнородных событий, с разными наборами вычислений, надо преобразовать в гомогенный • Для каждого события надо посчитать пермутации из его разрезов
  38. 38. Обработка события Задача: посчитать min/max/avg/sum платежей за последние час и сутки, в разрезе по стране и полу
  39. 39. Обработка события 1. Берем 2 свеклы JSON-path 2. Парсим значимые поля события, согласно конфигурации (hello, products!) 3. Множим по числу комбинаций 4. Суммируем одинаковые комбинации
  40. 40. Большой взрыв события
  41. 41. Подсчет агрегатов
  42. 42. Суммирование проекций
  43. 43. Хранение агрегатов • /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
  44. 44. Вычисление метрик • Метрика — сумма одинаковых проекций, посчитанная за интервал NOW() - N минут • Для каждого из желаемых интервалов берем данные из сохраненных агрегатов • Повторяем процедуру суммирования
  45. 45. Результат вычислений Все результаты сохранены в директориях HDFS
  46. 46. Что делать с результатами • Отправка в time-series хранилища (rrd, Influx, etc.) • Сохранение в базу данных • Дашборды, графики, таблички!!!
  47. 47. Посчитайте уникальных юзеров!
  48. 48. Мысли вслух ● Комбинаций — сотни тысяч ● К каждой — hash с user_id ● Не, ну ладно — bitset ● На каждую комбинацию — сотня мегабайт ● Не успеем считать суточные агрегации
  49. 49. «Почти честное» решение ● HyperLogLog — вероятностная структура для подсчета уникальных значений ● Настраивается процент погрешности (больше памяти → меньше ошибка) ● 0.5% погрешности ~ 32Kb на объект
  50. 50. Удав, который проглотил слона
  51. 51. Что мы научились ● 80/20 — принцип Паретто ● count/sum/avg/min/max/first/last ● approx distinct ● Да, пока нет перцентилей и точного DISTINCT ● Но возможность прикрутить-то имеется!
  52. 52. Пучок цифр и фактов ● 300К events/sec в пике (больше пока не придумали :) ● 25 серверов в Hadoop-кластере (не только для нашей задачи) ● В 300 раз уменьшили объем данных для анализа (за счет замены сырых данных на агрегаты)
  53. 53. Scientia potencia est! (Знание — сила)
  54. 54. Есть простые инструменты для решения ваших сложных задач
  55. 55. Where to go from here 1. tech.badoo.com/ Техблог Badoo 2. pinba.org Real-time аналитика вашего приложения 3. bit.ly/StatsCollector Доклад о StatsCollector 4. spark.apache.org
  56. 56. Спасибо за внимание, я готов ответить на Ваши вопросы! krash@corp.badoo.com krash3@gmail.com facebook.com/alex.krash

    Be the first to comment

    Login to see the comments

  • marliotto

    Dec. 8, 2015

Near-realtime аналитика событий в высоконагруженном проекте. Доклад Александра Кашенинникова на Highload 2015 https://youtu.be/3XJhBRiVKW8

Views

Total views

395,356

On Slideshare

0

From embeds

0

Number of embeds

176,949

Actions

Downloads

13

Shares

0

Comments

0

Likes

1

×