В первом посте об аналитической системе Sports.ru и Tribuna.com мы рассказали о том, как используем нашу инфраструктуру в повседневной жизни: наполняем контентом рекомендательную систему, наблюдаем за бизнес-метриками, ищем среди пользовательского контента бриллианты, находим ответы на вопросы “Как работает лучше?” и “Почему?”, нарезаем пользователей для почтовых рассылок и строим красивые отчеты о деятельности компании. Всю техническую часть повествования мы скромно спрятали за этой схемой:



Читатели законно потребовали продолжить повествование со смешными котиками, а olegbunin пригласил рассказать о всем, что было скрыто, на РИТ++. Что ж, изложим некоторые технические детали – в продолжении веселого поста.

Год назад мы отказались от всех публичных счетчиков в пользу закрытых сервисов и собственной инфраструктуры обработки данных. Собирая на Олимпиаде по 10 млн. хитов в сутки, мы нащупали предел доброты Google Analytics, за которым бесплатное обслуживание уже не возможно. Но теперь у нас есть свой лунапарк со сверткой и графиками, поэтому мы можем легко снизить интенсивность использования GA, сохранив за ним только аудиторские функции. О том, как мы собираем данные и как используем их в своей работе – в простыне с веселыми картинками внутри.

В качестве вступительного слова

На Хабре и других источниках уже было описание HP Vertica, но, в основном, вся информация сводилась к теории. До недавнего времени в реальной промышленной эксплуатации Vertica использовалась (так как мы называем ее Вертика, предлагаю назначить женский род) в Штатах и немного в Европе, на Хабре же о ней писали ребята с LifeStreet Media. Уже прошло полтора года работы с Vertica, наше хранилище данных содержит десятки терабайт данных. В минуту сервер данных обрабатывает тысячи запросов, многие из которых содержат десятки миллиардов записей. Загрузка данных идет не переставая в реалтайме объемами порядка 150 гб в сутки … В общем я подумал, что стоит восполнить пробел и поделиться ощущениями от езды на реально современных новых технологиях под BigData.

Кому это будет полезно

Думаю, это будет полезно для разработчиков, архитекторов и интеграторов, которые сталкиваются с задачами хранения и аналитической обработки больших данных по объему, содержанию и сложности анализа. Тем более, у Vertica сейчас наконец то есть вменяемая бесплатная полноценная версия Community Edition. Она позволяет развернуть кластер из 3 серверов и загрузить в хранилище данных до 1 тб сырых данных. С учетом производительности и легкости развертывания решений на Vertica, считаю это предложение достойным для того, чтобы его рассмотреть при выборе хранилища данных для компаний, у которых объем данных впишется в 1 тб.

В один абзац о том, как мы выбирали

Кратко без повода к холивару:
При выборе сервера хранилищ данных нас интересовали принципы ценообразования, высокая производительность и масштабируемость работы с большими объемами данных, возможность загрузки данных в реалтайм с множества разных источников данных, легкость стартапа проекта своими силами и минимальная стоимость сопровождения: в итоге по всем этим показателям лучше всего для нас выступила Vertica, победив IBM Netezza и EMC GreenPlum. Последние не смогли полностью удовлетворить всем нашим требованиям. Это могло вылиться в дополнительные издержки на разработку и сопровождение нашего проекта, имеющего не сильно большой бюджет.

Как выглядит Verica с точки зрения архитектора

Архитектор — это самый важный для хранилища данных человек в Vertica. Именно в первую очередь от него зависит успешность и производительность функционирования хранилища данных. У архитектора две сложных задачи: грамотно подобрать техническую начинку кластера Vertica и правильно спроектировать физическую модель базы данных.

На что влияет техническая архитектура

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.

Спустя полтора года разработки вышел финальный релиз фреймворка Kango.
С помощью Kango можно создавать расширения сразу под 5 браузеров (Chrome, Firefox, Opera, Safari, Internet Explorer) используя общий JavaScript код.