В «Одноклассниках» логируются любые действия пользователей, любой вызов классов и методов, любые взаимодействия компонентов системы. Через несколько минут эти данные уже видны на графиках системы статистики. Данные собирает, хранит и обрабатывет хранилище данных, построенное на базе MS SQL Server. Для адмистраторов, разработчиков и менеджеров построены универсальные интерактивные графики. Эти графики можно настроить так, чтобы они показывали любую подвыборку данных, агрегированных по периодам, начиная с 5 минут и заканчивая годом. Из графиков составлены тематические страницы (дэшборды), которые наглядно показывают состояние всего сайта или его отдельного компонента. В докладе будут рассмотрены архитектура, основные компоненты и примененные алгоритмы обработки данных.

1. Система внутренней
статистики odnoklassniki.ru
Александр Шарак
Руководитель
отдела статистики
Одноклассников

2. Зачем?
• Оценивают эффективность
• Устанавливают цели
• Отслеживают достижение целей
Менеджеры • Наблюдают за активностью
пользователей
• Следят за качеством работы
Разработчики
Статистика компонентов сайта
• Расследуют аномалии
Администраторы
• Мониторят компоненты сайта
• Наблюдают за активностью
пользователей
• Расследуют аномалии

3. 5-минутный график

4. 5-минутный график

5. Дневной график

6. Графики интерактивны

7. Дешборд
http://www.flickr.com/photos/lofink/4501610335/

8. Собственная WEB-аппликация для работы с дешбордами
http://www.flickr.com/photos/lofink/4501610335/

9. Немного цифр
• Сайт логирует больше одного триллиона
(1 000 000 000 000) действий в день.
• Свежие данные подгружаются с задержкой в
2-3 минуты. Почти в режиме реального
времени.
• В часы пик сотрудники запрашивают до 40
графиков в секунду.
• Отдельный график в среднем высчитывается
менее чем за одну секунду.

10. Как мы этого достигли?

11. Агрегация данных
Как обычно делают Как делаем мы
1. Тысячи серверов логируют 1. Тысячи серверов не логируют
действия в локальное или каждое действие, а в памяти
удаленное хранилище(чаще всего сразу агрегируют эти действия
это файл). по:
2. Мега-кластер (например, Hadoop) а) типам операций
из сотни серверов забирает эти б) значениям классификаторов
терабайты (или петабайты) с в) 5 минутам
данными и агрегирует. 2. Раз в 5 минут каждый сервер
передаёт собранную
информацию в одну из четырех
промежуточных баз данных
(MS SQL)

12. Агрегация данных
• Таким образом, мы вместо 10 миллиардов
(10 000 000 000) записей за пять минут в час пик
получаем всего 10 миллионов (10 000 000).
• Задача загрузки данных в DWH стала
относительно простой.

13. Загрузка данных
Более 3000 серверов
Все 4 базы имеют
одинаковую структуру. Каждые 5 минут
Каждая содержит
300 таблиц Logs - 1 Logs - 2 Logs - 3 Logs - 4
Выгрузка в одном потоке Как можно чаще
требует 0.5 сек на таблицу
DWH 1 DWH 2
Одна половина …а вторая —
таблиц — сюда.
сюда…

14. Нормализация
Counter Registered HostName Group0 Group2 Calls DurationAvg
5 2012-04-20 12:45:00 bsrvd20-10 createPhotoAlbum customAlbum 2 0
Registered ID_Host ID_AlfaInsureName ID_AlfaInsureParam Calls DurationAvg
2012-04-20 12:45:00 34 11 6 2 0

15. Структура таблиц
• В каждой базе содержится по 150 таблиц с похожей
структурой, легко поддающейся автоматизации.
Registered ID_Host ID_AlfaInsureName ID_AlfaInsureParam Calls DurationAvg
2012-04-20 12:45:00 2006 1 2 2 0
• В каждой таблице:
1) колонка Registered
2) ссылки на классификаторы
3) измерения

16. Индексы
• Индексы на дату и на каждый классификатор (foreign key),
как «по учебнику» - не работают.
• Сейчас у нас у каждой таблицы один кластерный индекс
со структурой
(Registered, id_classifier1, id_classifier2…)

17. Агрегаты по дням
• Для каждой из 300 таблиц мы построили агрегаты по
дням.
• Количество записей в этих таблицах в 20 - 150 раз меньше,
чем в основных таблицах.

18. Базы с данными за один месяц
• Оперативные графики в 99% случаев используют данные
не старше одного месяца.
• Сделали базу, где храним данные за последний месяц.
График
Многократный прирост
1% производительности
Полный 31 день
архив

19. MS SQL partitioning and
compression
• удаление старых данных за 1 минуту вместо 2
часов
• данные на диске «сжались» в 3.5 раза
• подсчет графиков ускорился в несколько раз
• загрузка данных происходит на 20% медленнее

20. И все тормозит…
• На оперативных графиках обычно выводятся
данные за 5 дней.
• Один день данных одной таблицы по размеру
больше среднего занимает 0.5 GB. То есть для 5
дней надо считать с диска 2.5 GB данных.
• Дисковая подсистема обеспечивает скорость до
100 Mb/s. Получается 25 сек в эксклюзивном
режиме для таблиц больше среднего.
• Самый популярный дешборд состоит из 80
графиков.
• А если запустить дневной график за месяц или
год…

21. Решение!
• Представьте, что в момент X кто-то запрашивает некий
график.
• Через два часа другой пользователь запрашивает тот же
график.
• Как получить новый график из предыдущего?

22. DWH cache для 5 мин. графика
• Вместо чтения 2.5GB надо считывать в 60 раз меньше
данных. То есть всего 41Mb. При скорости 100Mb/s это
меньше 0.5 сек.
• Чем популярней график – тем он быстрее строится.
• 99% процентов графиков стали строиться очень быстро.
• 1% графиков строится относительно медленно.

23. DWH cache для дневного графика

24. DWH cache
• Система стала стабильной…

25. • … но не идеальной

26. На чём написано
• MS SQL 2008 R2 Enterprise Edition
• От использования MS SQL Integrity Services мы отказались
• Весь код загрузки и обработки данных написан на T-SQL
• Весь код подсчёта графиков также написан на T-SQL
• Весь код DWH-cache также написан на T-SQL
• Для построения (rendering) графиков(и отчётов в целом)
используем MS SQL Reporting Services

27. Неагрегированные данные
• Данные, в которых есть идентификатор пользователя и
точная дата со временем
• Например:
– логины (29.5 млрд записей за 2011 год), платежи, граф дружб,
дарение подарков, загруженные фотки и другая информация
• Из этих данных мы высчитываем:
– количество уникальных пользователей, которые сделали какие-то
действия и/или обладают каким-то свойством
– например, сколько девушек из Самары 18-23 лет подружилось с
юношами из Москвы старше 50 лет
• MS SQL 2008 R2 Enterprise Edition
• Всю обработку данных пишем на T-SQL
• Front-end – MS SQL 2008 R2 Reporting Services

28. OLAP
• Используем MS SQL 2008 R2 Analysis Services
• Опыт - один год
• Построили десять разных кубов
• Средний объем куба – 1 млрд записей в таблице фактов
• Объем самого большого куба – 4.5 млрд записей
• В каждом кубе присутствует мера – distinct count
• Мера distinct count вынуждает ограничивать объём куба
• С мерами count и sum проблем нет
• Мешает ограничение размера одного измерения

29. Ресурсы
• Статистикой занимается 4 разработчика
– Начал разработку один человек
– Разработка первой версии заняла 3 месяца
– Каждый год добавляем по одному разработчику
• Сервера – 30 (типичный сервер – 2 6-core CPU,
80GB RAM, 6-10TB Disk array):
– 4 сервера для Reporting Services
– 2 сервера для front-end
– 7 серверов для данных 5-минутных и дневных графиков
– 4 сервера для промежуточных баз данных
– 6 серверов для статистики об объектах (userid)
– 7 серверов для OLAP

30. Спасибо за внимание!
Александр Шарак
Руководитель отдела статистики
Одноклассники
aleksandr.sharak@odnoklassniki.ru

31. Пожалуйста, поставьте
оценку моему докладу.
Ваше мнение очень важно.
Спасибо!