Оптимизация загрузки виджетов в AW BI: практические советы

Информационные панели в AW BI позволяют быстро визуализировать данные. Однако при работе с огромными объемами данных, надо учитывать особенности системы, влияющие на производительность, стабильность и удобство ее использования. В этой статье мы делимся практическими рекомендациями, которые помогли нам сократить время загрузки дашборда с почти 25 секунд до 6 секунд!

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

Итоговая модель содержала:

• 37 столбцов;
• Около 360 млн. строк
• И занимала 26 Гб дискового пространства.

После добавления 12 виджетов (8 на первой странице и 4 на второй) и всех фильтров на дашборд, время его отклика увеличилось до 25 секунд.

Каждый раз при отображении виджета AW BI формирует SQL-запрос к внутреннему хранилищу – базе данных ClickHouse. Этот запрос включает все заданные агрегации, фильтры и сортировки, после чего возвращает итоговый набор данных, необходимый для построения визуализации. При открытии дашборда подобные запросы отправляются одновременно для каждого виджета, что особенно критично при большом объеме данных и сложной логике выборки. В результате возрастает нагрузка на систему, что напрямую влияет на скорость отклика и общее время загрузки дашборда.

Если в основной модели, на основе которой строится виджет, используются поля-справочники напрямую (такие поля используются для создания фильтров и фильтрации данных), то это приводит к значительному замедлению построения виджета!
В нашем случае, в модели было 4 поля-справочника, которые использовались в виджетах для фильтрации по году, месяцу, магазинам и категориям товаров.
Более эффективным подходом в таком случае будет создать отдельные модели справочников, на основе которых создать необходимые фильтры, а затем настроить связь этих фильтров с необходимыми виджетами. А в основной модели не использовать никакие поля как справочники.
В результате было принято решение добавить три модели: “Календарь”, “Справочник магазинов” и “Справочник Товарные Группы”, содержащие все необходимые поля-справочники для фильтров.

Такой подход позволил уменьшить время отображения виджета примерно до 12 секунд!

Далее был проведен анализ запросов, которые отправляются в ClickHouse при построении виджета. Выяснилось, что при настройке фильтра, если необходимо по умолчанию отобразить все элементы, то “Фильтр по умолчанию” надо оставить пустым:

Выбор всех элементов (особенно, если их много, например в нашем случае фильтр магазинов содержал 200 элементов, а фильтр категорий 321 элемент) по умолчанию приведет к значительному усложнению запроса (в предложении WHERE будет перечислен длинный список всех выбранных элементов), что вызывает задержки при отправке, выполнении запроса и отображении виджета. Если значение по умолчанию не задавать, то все-равно отобразятся все элементы, но виджет будет загружаться быстрее (предложения WHERE в запросе не будет вообще). Таким образом нам удалось сократить время загрузки виджета еще на 1-2 секунды.

Если же, все-таки, при загрузке виджетов возникают проблемы, можно проанализировать логи выполнения запросов напрямую во внутреннем хранилище ClickHouse, подключившись через любой инструмент для работы с БД (например DBeaver). Параметры для подключения: CLICK_PORT, CLICK_DB, CLICK_USER, CLICK_PASS указаны в конфигурационном файле (по умолчанию расположение /opt/aw/app/.env).

Также был пересмотрен подход с единой моделью для построения всех виджетов, так как при загрузке все виджеты обращаются к одной таблице, что тоже ведет к задержкам. Мы протестировали вариант с двумя отдельными моделями меньшего объема:

• Модель 1 – 110 млн. строк, 8 Гб;
• Модель 2 – 173 млн. строк, 13 Гб.

Такой подход ускорил загрузку виджетов еще на 1-2 сек.

Работа с большими объемами данных требует внимания к деталям, особенно когда речь идёт о производительности и ресурсах сервера. При работе с AW BI важно понимать, что происходит “под капотом”. Небольшие оптимизации, вроде отдельного хранения справочников и правильной настройки фильтров, позволяют значительно ускорить работу виджетов и дашбордов!