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

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

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

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

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

Дешборд

Собственная WEB-аппликация для работы с дешбордами

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

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

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

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

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

Нормализация CounterRegisteredHostNameGroup0Group2CallsDurationAvg :45:00bsrvd20-10createPhotoAlbumcustomAlbum20 RegisteredID_HostID_AlfaInsureNameID_AlfaInsureParamCallsDurationAvg :45:

Структура таблиц В каждой базе содержится по 150 таблиц с похожей структурой, легко поддающейся автоматизации. В каждой таблице: 1) колонка Registered 2) ссылки на классификаторы 3) измерения RegisteredID_HostID_AlfaInsureNameID_AlfaInsureParamCallsDurationAvg :45:

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

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

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

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

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

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

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

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

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

… но не идеальной

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

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

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

Ресурсы Статистикой занимается 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

Спасибо за внимание! Александр Шарак Руководитель отдела статистики Одноклассники

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