Документ описывает проблемы и решения, связанные с аналитикой данных на платформе Рамблер, включая использование batch-обсчета, хранения агрегаций и обработки входных данных. Основное внимание уделяется модернизации механизма хранения сессий, скорости обработки и возможности масштабирования. Представлены недостатки текущих инструментов и платформ, а также результаты и впечатления от используемых технологий таких как Kafka, Spark и ClickHouse.

1. Про аналитику и
серебряные пули

2. Рамблер/топ-100

4. BATCH-ОБСЧЕТ

5. BATCH-ОБСЧЕТ
• Обсчет раз в сутки
• Hive-скрипты
• Предопределенный набор
агрегатов
• HBase
• Суммирование на стороне
flask

6. ФУНДАМЕНТАЛЬНЫЕ ПРОБЛЕМЫ ХРАНЕНИЯ АГРЕГАТОВ
• Заранее определенные отчеты
• Чтобы добавить отчет нужно
писать код
• Данные для нового отчета
доступны только с момента
добавления отчета
• Комбинаторный взрыв
• Количество данных после
агрегации может быть больше
чем, до агрегации
Подробнее https://goo.gl/pfrRTR

7. ПРОБЛЕМЫ

8. ПРОБЛЕМЫ
• Изменяющиеся сущности
• Реалтайм
• Произвольная сегментация
• Скорость работы
• Масштабируемость
• Большое количество
одновременных запросов

9. ОБРАБОТКА ВХОДНЫХ ДАННЫХ, ТРЕБОВАНИЯ

10. ОБРАБОТКА ВХОДНЫХ ДАННЫХ, ТРЕБОВАНИЯ
• Механизм хранения сессий
• Механизм потоковой обработки
• Скорость обработки (1 млрд
событий на старте)
• Горизонтальная
масштабируемость

11. БАЗА ДАННЫХ, ТРЕБОВАНИЯ
• Хранение слабоагрегированных сущностей
• Построение отчетов на лету
• Механизм сэмплирования
• Эффективное хранение данных,
сжатие (1.0 - 1.5TB в день на старте)
• Горизонтальное масштабирование
• Склейка / изменение загруженных данных
• Быстрая вставка в базу данных

13. ИНСТРУМЕНТЫ НА РЫНКЕ НА ТОТ МОМЕНТ

14. BATCH-ОБСЧЕТ
• Обсчет раз в сутки
• Hive-скрипты
• Предопределенный набор
агрегатов
• HBase
• Суммирование на стороне
flask

15. ДОПОЛНИТЕЛЬНАЯ ПРОБЛЕМА
•Вероятностные структуры данных
•HyperLogLog

16. HYPERLOGLOG
https://goo.gl/DgzNvQОбзор основного принципа алгоритма
Почитать
Подробный разбор, исследование от
гугла
https://goo.gl/z1VHGA

17. РЕЗУЛЬТАТ
•Кластер: Собираем и
записываем объекты HLL в
базу
•Бэкенд: merge объектов за период
•Бэкенд: Вызываем count у
получившегося объекта

19. БАЗА ДАННЫХ
•Скорость работы и сжатие
данных
•Хранение
неагрегированных
сущностей и аналитика на
лету
•Горизонтальная
масштабируемость
•Сэмплирование
•Быстрая вставка данных
•Возможность изменения
уже записанных событий
•SQL

20. СИСТЕМА ПОТОКОВОЙ ОБРАБОТКИ ДАННЫХ
• Поддерживается большим
количеством людей
• Удобный механизм
потоковой обработки
данных
• Нативный коннектор к
Kafka
• Есть механизм
тестирования
имитирующий кластер
локально
• Python

22. МЕХАНИЗМ ОБРАБОТКИ ИЗМЕНЯЮЩИХСЯ СУЩНОСТЕЙ

23. ЧТО ПРИНЯТЬ ЗА СТРОКУ В БАЗЕ ДАННЫХ?
• Просмотр страницы
• Дешево делать запросы
• Меньше данных

24. ЗАЧЕМ НУЖЕН МЕХАНИЗМ ХРАНЕНИЯ СЕССИЙ?

25. MERGE TREE
•У каждой строки в базе есть
параметр sign
•Как только приходит новая запись -
мы пишем ее в базу со знаком (+)
•Когда нужно обновить значение -
пишем старое значение со знаком (-)
•И новое значение со знаком (+)
•Движок в конечном итоге удаляет
строки по определенному правилу

27. ГРАБЛИ
• Нет восстановления с
offset’ов из коробки
• Не слишком
информативные логи
• Нет нормального
механизма gracefull
shutdown для наших задач

28. ГРАБЛИ
• Для тестового неймспейса
нужен отдельный раздел

29. ГРАБЛИ
•Нет автоматизации DDL
для кластера
•Большое количество
недокументированных
функций
•Слабо автоматизирована
работа с репликами и
шардами
•Партиционирование только
по месяцам

30. РЕЗУЛЬТАТЫ
Количество просмотров страниц и сессий за месяц с группировкой по
датам

31. РЕЗУЛЬТАТЫ
Посчитать все page_views, sessions за месяц с группировкой по части
url

32. ВПЕЧАТЛЕНИЯ
•Kafka - не напрягается
•Spark - работает
достаточно быстро
•ClickHouse - хорошо
сжимает данные
•ClickHouse - держит
нагрузку на запись / чтение

33. ВОПРОСЫ