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)

580 views

Published on

Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.

Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.

Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.

Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.

Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  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

×