Выступление на PYCON RUSSIA 2017

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

3. 40 50+ 700 1700+
млн человек
суммарная аудитория
группы
количество
изданий,
сервисов и
проектов
разработчиков человек в
хорошей
компании

5. Языки и технологии

6. Контакты
В группе компаний
Rambler&Co всегда есть
открытые вакансии для тех,
кто хочет профессионально
расти и развиваться,
занимаясь тем, что по-
настоящему нравится
hr@rambler-co.ru
www.rambler-co.ru/jobs

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

9. BATCH-ОБСЧЕТ

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

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

12. ПРОБЛЕМЫ

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

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

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

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

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

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

20. HIVE + PYTHON
• Код на произвольном
языке
программирования
• Можно заменять и
map и reduce фазу

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

22. HYPERLOGLOG
Возьмем набор случайных чисел и их бинарные представления

23. HYPERLOGLOG
Представим их как бинарное дерево

24. HYPERLOGLOG
Сбалансированные бинарные деревья очень «плоские»

25. HYPERLOGLOG

26. HYPERLOGLOG

27. РАСЧЕТ
Вероятность появления k лидирующих
нулей
Мы встречаем 0 на позиции k раз в 2 ^ k случаев
Предполагаем, что встретили 2 ^ k различных
элементов до увеличения счетчика

28. ПРОБЛЕМЫ

29. РЕШЕНИЕ

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

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

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

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

35. ПРИМЕР КОДА НА PYSPARK
Импорты

36. ПРИМЕР КОДА НА PYSPARK
Обработка данных

37. ПРИМЕР КОДА НА PYSPARK
Запускаем :)

38. ПРИМЕР
Пример unit-тестирования spark-streaming приложения
https://goo.gl/Znic23

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

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

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

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

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

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

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

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

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

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

51. ВОПРОСЫ