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

Среди клиентов Visiology такие компании, как Роскосмос, Алроса, Русгидро, Русская медная компания, Россети, СберМегаМаркет, Газпром Недра и др.

При реализации проектов интеграторы часто используют продукты Visiology совместно с low-code платформой Loginom. С помощью Loginom выполняется подготовка и обогащение данных, расчет показателей, обучение моделей. Затем на базе платформы Visiology информация визуализируется и строятся аналитические дашборды.

Совместное использование этих двух платформ для анализа и визуализации данных реализуется просто, т.к. для Loginom имеется готовый коннектор к Visiology.

Что нужно учитывать в масштабных BI-проектах?

Часто при реализации масштабных BI-проектов, включающих этапы ETL-подготовки и визуализации возникает вопрос: выдержит ли система значительную нагрузку при обработке больших данных. Этот вопрос можно разбить на несколько специализированных:

1. Как подобрать конфигурацию серверов?
2. Сколько конкурентных пользователей выдержит система?
3. Какой максимальный объем данных можно загрузить?
4. Как оценить масштабируемость системы?
5. Как оценить стабильность системы при продолжительной нагрузке?
6. Как понять, продолжит ли система корректно работать при обновлении?
7. Будет ли система выдерживать пики нагрузки?

Прежде чем начинать боевое применение системы, необходимо получить представление о ее продуктивности, работоспособности и надежности.

Особенности BI-проектов

Тестирование нагрузки в BI-проектах отличается, например, от тестирования транзакционных или любых других систем. Поэтому процесс имеет свою специфику.

Во-первых, чем больше кейсов self-service, тем сложнее предсказать нагрузку. Во-вторых, необходимо учитывать множество труднопредсказуемых факторов:

1. количество строк/объем данных в ГБ;
2. число пользователей;
3. уникальность данных;
4. сложность модели и связей;
5. сложность аналитических запросов;
6. разнообразие дашбордов;
7. число уникальных запросов/фильтраций;
8. трудоемкость и частота загрузки данных;
9. количество уникальных ролей доступа и т.д.

Тестирование производительности

Тестирование производительности — сложный проект, который занимает от двух недель до нескольких месяцев. Для его успешного проведения в команде специалистов обязательно должны быть архитектор, аналитик, специалист по тестированию производительности, специалист по конкретной BI-платформе — либо представитель вендора.

После формирования команды тестирования начинается анализ требований. Первоначально определяется целевая аудитория («read-only» пользователи, аналитик self-service, администратор…). Затем необходимо выявить стандартный профиль нагрузки, понять, какие запросы, транзакции, сценарии работы обычно использует большинство.

Далее происходит формирование целевых метрик нагрузочного тестирования. Например, время отклика (responce time): максимальное, минимальное, среднее, медиана, перцентиль. К базовым метрикам относятся также количество запросов в единицу времени (throughput) и надежность или безошибочность (reliability). При определении метрик важно учитывать требования к мощности и производительности самого сервера: процессор (CPU), оперативная память (RAM) и т.д.

На финальном этапе анализа требований происходит выбор вида тестирования производительности: нагрузочное (имитирует работу определенного количества пользователей), на выносливость (определяет корректность работы в течение продолжительного времени), стресс-тестирование (выявляет предел возможности системы), объемное, тестирование масштабируемости, spike-тестирование (проверяет работу в пике нагрузки).

После завершения анализа требований начинается подготовка стенда и выбор инструментов тестирования. Стандартная схема стенда тестирования приведена на рисунке.

1 — генератор нагрузки; 2 — сервера, отвечающие за application-слой; 3 — сервера, отвечающие за in-memory базу данных; 4 — хранилище данных; 5 — сервера, которые занимаются процессами преобразования.

В качестве генераторов нагрузки могут применяться такие фреймворки, как Apache JMeter, Яндекс.Танк, Puppeteer, PhantomJS, HP LoadRunner и другие.

Для проведения нагрузочного тестирования в компании Visiology наиболее часто применяется Apache JMeter. Данный инструмент не использует браузер при тестировании, а работает на уровне HTTP, эмулируя запросы реальных пользователей по сети.

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

Типовые ошибки при тестировании производительности

При проведении тестирования могут быть допущены ошибки в самой процедуре. Наиболее типичные из них:

1. Тестируется только часть компонентов системы, либо какой-то конкретный модуль, например, запросы в базу данных.
2. Не учитывается процесс загрузки данных.
3. Тестируются все возможные сценарии во всех конфигурациях, что существенно повышает трудоемкость проекта.
4. Тестирование не воспроизводимо — каждый раз при запуске показывает разные результаты по одной и той же метрике, например, по времени отклика системы.
5. Не используются случайные величины, например, при тестировании одних и тех же данных запросы попадают в кэш, что влечет за собой искажение метрик на порядок.
6. Применяются автоматически сгенерированные данные, что искажает результат тестирования — реальные данные существенно отличаются от «синтетических».
7. Слишком малое время тестирования, например, полчаса. Практика показывает, что увеличение времени тестирования (в некоторых случаях до нескольких дней) позволяет получить более точный результат.
8. Не учитывается аутентификация, например, при наличии разных прав доступа у пользователей генерируется разная нагрузка на систему.
9. Не учитываются права данных, например, RLS — row-level-security — управление доступом на уровне строк данных; OLS — oracle label security — управление доступом на уровне объектов.

Помимо ошибок в крупных проектах могут быть следующие особенности:

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

Заключение

Loginom и Visiology как комплексный инструмент для обработки и визуализации данных успешно прошли нагрузочное тестирование.

При использовании Loginom специалисты компании Visiology отмечают, что платформа — оптимальное решение для крупных проектов, в которых требуется визуальный ETL при наличии сложного pipeline. Loginom позволяет отслеживать всю цепочку преобразования данных, оперативно выявлять ошибки, при необходимости быстро менять сценарий анализа.

Подробнее о нагрузочном тестировании при реализации крупных BI-проектов в выступлении Никиты Ильина, главного архитектора компании Visiology:

Если вы хотите применять Loginom в сочетании с Visiology для обработки и визуализации данных, свяжитесь с нами.

Другие материалы по теме:

Quality Assurance и автоматизированное тестирование Loginom. Выступление Георгия Киселева

Простой визуальный ETL для BI. Интеграция Loginom и Visiology. Вебинар