Быстрее, больше, мощнее: построение высоконагруженных систем на базе «Форсайт. Аналитическая платформа»

Алексей Выскребенцев Генеральный директор компании «Аналитика»

А если уровень нагрузки только повышается? Что в этом случае может предложить российское аналитическое ПО? Опыт показывает, что поддержка высоких нагрузок — это задача, которая успешно решается при помощи отечественного BI-инструментария «Форсайт. Аналитическая платформа». Платформа поддерживает горизонтальное и вертикальное масштабирование, модель ROLAP позволяет не клонировать данные заказчика, а создавать метамодель данных, перекладывая нагрузку на СУБД.

Флагманский программный продукт компании «Форсайт» — это большая корпоративная платформа, в которую включено огромное количество возможностей, это выбор крупных компаний с высокими требованиями к скорости обработки данных и уровню защиты информации.

Для оптимизации производительности в платформе есть следующие возможности:

• Перекладка нагрузки на уровень СУБД.
• Использование технологий гибридного In-Memory кэш, позволяющего оптимизировать обращения к базе данных путем мэпирования определенного объема данных источника в оперативную память.

При правильном подборе СУБД, исходя из задач проекта, «Форсайт. Аналитическая платформа» позволяет значительно увеличить производительность. Но здесь важно помнить, что для обработки разных видов данных важно и нужно использовать разные типы СУБД. Как это лучше сделать? — Поделимся опытом партнера компании «Форсайт», компании «Аналитика», которая имеет значительный опыт работы с продуктом «Форсайт. Аналитическая платформа».

В статье рассмотрим кейс нашего заказчика, компании Агентство2 (А2), которая на базе «Форсайт. Аналитической платформы» воссоздала и улучшает систему медиаизмерений, которая позволяет анализировать поведение зрителей при просмотре телеканалов, программ и других медиасервисов, а также используется для планирования рекламных кампаний на ТВ. В отличие от большинства других систем подобного класса на рынке, система компании А2 работает не только с панельными данными (панель — это специально отобранные несколько тысяч домохозяйств, с приёмников которых собираются данные о телепросмотре), но и использует восстановление данных о телезрителях на миллионной базе цифровых приставок, применяя алгоритмы машинного обучения для восстановления профилей аудитории домохозяйств.

Система рассчитывает показатели просмотра, ведет статистику эфирных событий, оценивает пересечение аудиторий каналов, движение аудиторий между каналами. Вычислительной мощности системы достаточно, чтобы за считанные секунды анализировать большие объемы данных и рассчитывать необходимые для анализа и медиапланирования показатели.

Математические алгоритмы расчетов в системе таковы, что приходится оперировать сырыми данными, — рассказывает генеральный директор компании «Аналитика» Алексей Выскребенцев. — И когда мы работали только с панельными данными, у нас неплохо получалось рассчитывать статистики и на реляционной СУБД, несмотря на то, что объем данных был достаточно большим. Если мы говорим про кубы, то это порядка 50 млн строк в одной фактовой витрине в почасовой детализации с дневным инкрементом порядка 50 тыс. строк, до 145 млн. в поминутной детализации, порядка 25 измерений и порядка 30 параметров и 7 витрин на один куб. Если делать оценку в терабайтах, то «сырой» tablespace составляет порядка 8 ТБ. Объем данных подготовленных витрин порядка 5 терабайт. Мало того, что методики расчета нетривиальные, но и при различных сценарных условиях расчета, возникает большое число уникальных сочетаний расчетных вариантов, равное декартовому произведению всех измерений и параметров.

Заказчик, ориентируясь на мировые тренды медиаизмерений, поставил задачу — значительно увеличить объем данных, расширив выборку телезрителей. Задача заключалась в расширении числа обновленной панели за счет цифровых приставок и восстановление профилей зрителей за счет алгоритмов машинного обучения.

В итоге дневной инкремент в почасовой детализации увеличился до 11 млн строк на каждую витрину, а общий объем в витринах составляет порядка 5 млрд записей, а в поминутной составил порядка 250 млн. строк за сутки или 6 млрд записей с момента накопления, и система на реляционной СУБД не позволяла обеспечить нужную производительность. На кубе, в котором собирались данные за 1 час, средняя скорость выполнения запроса стала от 40 минут до 2 часов. СУБД оставалась прежней — Postgres Pro, и стало понятно, что задачу можно решить, только заменив СУБД.

Действительно, реляционная СУБД PostgreSQL быстро записывает небольшие порции измененных данных, но медленно считывает сложные аналитические запросы. Было решено попробовать перейти на колоночную СУБД ClickHouse.

Сделали небольшой прототип и предварительные замеры показывали, что прирост производительности при различных сценарных условиях может составить в 60-100 раз. При том же объеме данных, на тех же самых витринах, на тех же месячных сырых данных, без какой-либо оптимизации кубов, — делится Алексей Выскребенцев. — ClickHouse как раз хорошо работает с широкими витринами, когда все данные собраны в одной витрине, и очень быстро агрегирует. Для ClickHouse посчитать среднее количество на больших массивах — легко! Если вы работаете с одной витриной, то эта архитектура — ClickHouse плюс «Форсайт. Аналитическая платформа» — с точки зрения ROLAP показала самый лучший результат.

При переходе на Clickhouse была опробована и новая архитектура кубов, когда физически данные находятся в Clickhouse, а обращение идет через функции PostgreSQL за счет расширения PostgreSQL, что позволило обеспечить прирост производительности в среднем в 500 раз, и сложнейший расчет сейчас выполняется за 10-15 секунд, при том, что объем данных на несколько порядков вырос. Это действительно впечатляющий результат, который показывает, что при грамотном подходе к архитектуре решения «Форсайт. Аналитическая платформа» способна достигать высокой скорости при обработке больших данных.

Отмечу, что ключевое преимущество «Форсайт. Аналитическая платформа» для нас — это гибкость и множество инструментов оптимизации, обеспечивающих определенную гибкость для разработчика, на что, как правило, меньше обращают внимание вендоры решений класса Self Service, ориентированные прежде всего на неподготовленного пользователя, и при столкновении с большим объемом данных решение задачи, как правило, заходит в тупик, — добавляет Алексей Выскребенцев.