1 / 31

Система внутренней статистики odnoklassniki.ru

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

mills
Télécharger la présentation

Система внутренней статистики odnoklassniki.ru

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  14. Нормализация

  15. Структура таблиц • В каждой базе содержится по 150 таблиц с похожей структурой, легко поддающейся автоматизации. • В каждой таблице:1) колонка Registered2) ссылки на классификаторы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.5GB данных. • Дисковая подсистема обеспечивает скорость до 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 Diskarray): • 4 сервера для Reporting Services • 2 сервера для front-end • 7 серверов для данных 5-минутных и дневных графиков • 4 сервера для промежуточных баз данных • 6 серверов для статистики об объектах (userid) • 7 серверов для OLAP

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

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

More Related