Оптимизация производительности приложения
Производительность приложения можно улучшить, уменьшив его размер, упростив модели данных, а также с помощью стратегического использования анализа множеств. В этом разделе будут рассмотрены факторы, влияющие на производительность, что поможет избежать проблем с производительностью, и способы оценки и мониторинга производительности приложения.
Сложность приложения
Существуют широкие категории, с помощью которых можно диагностировать проблемы. Наиболее сложные приложения обладают самой низкой производительностью.
Простые приложения:
- не включают сложный анализ множеств или операторов If();
- не включают большие таблицы;
- используют простую модель данных;
- содержат простые вычисления;
- могут иметь большие объемы данных.
Умеренные приложения:
- имеют модель данных со многими таблицами, но следуют рекомендациям;
- используют анализ множеств и несколько операторов If();
- имеют большие или широкие таблицы на листах (15 столбцов или больше).
Сложные приложения:
-
имеют очень сложную модель данных;
- подключаются к большим объемам данных;
- содержат сложные вычисления, диаграммы и таблицы.
Сведения о применении
Необходимо учитывать аппаратную среду в связи с размером приложения, потому что это влияет на производительность Qlik Sense развертывания. Например, если не оптимизировать приложения, они могут потребовать больше аппаратных ресурсов.
Мониторинг размера приложения поможет вам:
- понять текущую производительность;
- Понять влияние развертывания нового приложения на производительность.
- Понять влияние изменения существующего приложения на производительность.
- решить проблемы с производительностью;
- планировать расширение в будущем.
Qlik предлагает инструменты, которые помогут вам оценить ваши приложения. Для получения дополнительной информации см. Производительность и масштабируемость в Qlik Sense Enterprise (только английский язык).
Ниже приводятся основные элементы приложения, которые могут влиять на производительность.
| Функция | Описание |
|---|---|
| Размер приложения на диске (МБ) | Размер приложения можно найти в QMC. Перейдите в раздел Приложения и откройте Селектор столбцов справа рядом с разделом Действия. Щелкните переключатель рядом с параметром Размер файла (МБ). При использовании Qlik Sense Desktop размер приложения можно найти в Windows Explorer. Папка по умолчанию: %USERPROFILE%\Documents\Qlik\Sense\Apps. В папке Apps перечислены все имена приложений и размеры файлов. |
|
Размер приложения в ОЗУ (ГБ) |
Для определения базового RAM объема занимаемого приложением места, можно выполнить следующие действия:
При использовании Qlik Sense June 2018 или более поздней версии можно применять App Metadata Analyzer для нахождения этого показателя. Для получения дополнительной информации см. Application Metadata Analyzer (только английский язык). |
|
Общее количество строк приложения (M) |
Для вычисления общего количества строк можно использовать системные поля. Создайте KPI с мерой Sum($Rows). Для получения дополнительной информации см. Системные поля. |
| Общее количество полей приложения | Для вычисления общего количества полей можно использовать системные поля. Создайте KPI с меройSum($Fields). Для получения дополнительной информации см. Системные поля. |
| Общее количество таблиц приложения | Для вычисления общего количества таблиц можно использовать системные поля. Создайте KPI с мерой Count(DISTINCT $Table). Для получения дополнительной информации см. Системные поля. |
Мониторинг приложения
Консоль управления Qlik (QMC) предоставляет приложения для мониторинга производительности и использования системы на Qlik Sense Enterprise on Windows:
-
Приложение Operations Monitor предоставляет информацию об использовании аппаратного обеспечения, такую как использование памяти и CPU сервера, активные пользователи и операции по задачам перезагрузки. Оно также дает сводку и подробную информацию об ошибках, предупреждениях и операциях в журнале в серверной среде Qlik Sense.
-
Приложение License Monitor отслеживает использование лицензий и упрощает мониторинг изменений в выделении лицензий.
- Приложение Log Monitor представляет почти все доступные данные журналов и включает анализ тенденций, а также поиск и устранение неисправностей.
- Приложение Sessions Monitor показывает данные журналов об использовании приложений.
- Приложение Reloads Monitor предоставляет подробную информацию о перезагрузке данных как из QMC, так и приложений, открытых в хабе.
- Приложение Sense System Performance Analyzer показывает производительность Qlik Sense на всех узлах.
- Приложение Sense Connector Logs Analyzer предоставляет аналитические данные в отношении использования и ошибок определенных коннекторов Qlik.
- Приложение App Metadata Analyzer предлагает всеобъемлющую информацию обо всех ваших Qlik Sense приложениях, включая уровень детализации модели данных приложения и использование ресурсов.
Для получения дополнительной информации см. Мониторинг сайта Qlik Sense Enterprise on Windows (только английский язык).
Большие объемы данных
При подключении к большим объемам данных можно использовать следующие стратегии архитектуры.
Сегментация
Можно сегментировать QVDs по измерениям, таким как период времени, регион или уровень агрегирования. Например:
- В одном файле QVD могут содержаться данные за два последние года.
- В другом файле QVD могут содержаться исторические данные старше двух лет.
-
В третьем файле QVD могут содержаться все данные, агрегированные на более высоком уровне. Например, данные за месяц вместо даты или данные по стране вместо отдельных клиентов.
- Один большой файл QVD может включать в себя все данные, которые используются только лишь небольшим подмножеством пользователей.
Приложения можно сегментировать похожим способом. Меньшие приложения будут отвечать аналитическим потребностям большинства пользователей. Это позволяет экономить память.
Можно также иметь несколько приложений, ориентированных на разные регионы. Таким образом, пользователи не будут открывать приложение с данными, которые им не интересны или к которым у них нет прав доступа. Данные, которые нельзя получить через доступ к разделу по-прежнему влияют на память.
Генерация приложений по запросу (ODAG)
Приложения по запросу Qlik Sense предоставляют пользователям агрегированные представления хранилищ больших данных. Они могут определять и загружать необходимые подмножества данных для подробного анализа.
С точки зрения пользователя есть два приложения:
- корзина интернет-магазина с агрегированными данными;
- Пустое шаблонное приложение, используемое для отображения подробных данных.
Пользователь делает выборки в приложении корзины покупок. После достижения порога создается пользовательский LOAD скрипт, который заполняет шаблонное приложение запрошенными подробными данными. Для получения дополнительной информации см. Управление большими данными с помощью приложений On-demand.
Цепочка приложений
Цепочка приложений (известная как цепочка документов в QlikView) означает, что существует агрегированное приложение, которое пользователи регулярно используют. Если пользователю нужно больше подробных данных, выборки могут быть переданы из агрегированного приложения в подробное приложение, чтобы можно было просмотреть данные с меньшим уровнем детализации. Это позволяет экономить память, потому что пользователи не загружают ненужные подробные данные. Для формирования цепочки приложений можно добавить на лист объекты кнопок. Для получения дополнительной информации см. Цепочка приложений.
Цепочки приложений также поддерживаются посредством APIs. Например, можно использовать API для интеграции приложений чтобы создать пользовательскую цепочку приложений. Для получения дополнительной информации см. раздел API для интеграции приложений (только английский язык).
Производительность модели данных
Ниже приводятся индикаторы, которые могут повлиять на производительность модели данных. Каждый из них представляет собой рекомендацию, которая позволит повысить удобство использования приложения.
| Действие | Описание |
|---|---|
|
Удалите синтетические ключи |
Qlik Sense создает синтетические ключи, если в нескольких таблицах данных есть два общих поля или более. Это может означать, что в скрипте или модели данных есть ошибка. Для диагностики синтетических ключей см. Синтетические ключи. |
|
Удалите циклические ссылки из модели данных |
Циклические ссылки возникают, когда у двух полей есть несколько связей. Qlik Sense попытается разрешить их, изменив подключение к одной из таблиц. Однако все предупреждения о циклических ссылках должны быть исправлены, см. Представление о циклических ссылках и их исправление. |
|
Используйте соответствующую детализацию данных |
Следует загружать только необходимые данные. Например: группе пользователей нужны лишь данные, разделенные по неделям, месяцам и годам. Можно загрузить агрегированные данные или агрегировать данные в скрипте загрузки, чтобы сэкономить память. Если пользователю действительно нужно визуализировать данные на более низком уровне детализации, можно использовать ODAG или цепочку документов. |
|
Используйте QVDs, если возможно |
QVD — это файл, в котором содержится таблица данных, экспортируемых из программы Qlik Sense. Этот формат файла оптимизирован для скорости при чтении данных из скрипта, но при этом очень компактен. Чтение данных из файла QVD обычно в 10–100 раз быстрее, чем чтение из других источников данных. Для получения дополнительной информации см.: Работа с файлами QVD. |
|
Файлы QVD оптимизируются при загрузке |
Файлы QVD можно читать в двух режимах: стандартном (быстром) и оптимизированном (сверхбыстром). Выбор режима выполняется обработчиком скриптов автоматически. В отношении оптимизированных загрузок существуют некоторые ограничения. Поля можно переименовывать, однако при наличии какого-либо из этих операторов запустится стандартная загрузка:
|
|
Используйте инкрементальную загрузку |
Если ваше приложение подключается к большому объему данных из постоянно обновляющихся баз данных, перезагрузка всего набора данных может занять много времени. Вместо этого следует использовать инкрементальную загрузку для получения новых или измененных записей из базы данных. Дополнительные сведения см. в разделе Загрузка новых и обновленных записей с помощью инкрементальной загрузки. |
|
Используйте консолидированную модель Snowflake |
При использовании модели данных Snowflake («снежинка») можно сократить количество таблиц данных, объединяя их при помощи префикса Join или другого сопоставления. Это особенно важно для больших таблиц фактов. Согласно общему правилу рекомендуется иметь только одну большую таблицу. Для получения дополнительной информации см. Объединять или не объединять. |
|
Используйте денормализованные таблицы, в которых немного полей |
Если имеются две таблицы с немногими полями, их можно объединить для повышения производительности. Для получения дополнительной информации см. Следующие этапы написания скриптов. |
|
Используйте денормализованные таблицы поиска (листа) с сопоставлением загрузок |
Не следует использовать префикс Join , если необходимо только добавить одно поле из одной таблицы в другую. Рекомендуется использовать функцию поиска ApplyMap, см. Не объединяйте — используйте вместо этого ApplyMap. |
|
Удалите или отделите метки времени от поля даты |
При наличии метки времени поля даты могут занимать пространство, так как строковое представление больше и количество уникальных значений больше. Если точность для анализа не нужна, можно округлить метку времени, например, до ближайшего часа с помощью Timestamp(Floor(YourTimestamp,1/24)) или удалить компонент времени полностью с помощью Date(Floor(YourTimestamp)). Если метка времени нужна, ее можно отделить от даты. Можно использовать ту же функцию Floor(), а затем создать новое поле с извлеченным временем, используя что-то вроде: Time(Frac(YourTimestamp)). |
|
Удалите ненужные поля из модели данных |
В модели данных следует загружать только необходимые поля. Избегайте использования Load * и SELECT. Убедитесь, что сохранены:
|
|
Избегайте использования таблиц-связей, если объем данных большой |
По возможности следует использовать таблицы-связи. Однако при больших объемах данных производительность объединенных таблиц может быть выше, чем у таблиц-связей. |
|
Разбивайте объединенные измерения на новые поля |
Рекомендуется разбивать объединенные измерения на отдельные поля. Это уменьшает количество уникальных вхождений значений в полях. Это подобно тому, как можно оптимизировать метки времени. |
|
Используйте оператор AutoNumber, если возможно |
Вы можете создать оптимизированную загрузку, загрузив данные из QVD файла сначала, а затем используя оператор AutoNumber для преобразования значений в ключи символов. Для получения дополнительной информации, см. AutoNumber. |
|
Избегайте использования островков данных |
Островки данных могут быть полезны, но они обычно влияют на производительность. При создании островков для значений выборки используйте переменные. |
|
Сохраняйте файлы QVD согласно инкрементальным периодам времени |
Рекомендуется сохранять файлы QVD согласно сегментам, таким как один месяц. Эти меньшие ежемесячные QVD могут затем поддерживать множество различных приложений, которым, возможно, не потребуются все данные. |
Производительность листа
Ниже приводятся рекомендации, позволяющие повысить производительность листов и визуализаций.
| Действие | Описание |
|---|---|
|
Избегайте использования функции If(), если возможно |
Если функция If() будет использоваться в функции агрегирования, она будет работать на уровне записи и будет вычисляться много раз. Например, если в агрегировании 1000 записей, то условие If() будет вычислено 1000 раз. Это может лавинообразно нарастать при вложении операторов. Вместо этого рекомендуется использовать анализ множеств. Фильтр анализа множеств применяется перед агрегированием, что приводит к сокращению времени ответа. Также эти ответы можно кэшировать с помощью анализа множеств, а If() — нет. Кроме того, можно рассмотреть другие функции и изменения в модели данных. |
| Полей из различных таблиц в таблице агрегирования следует по возможности избегать. |
Вычисление агрегирования выполняется за два шага:
Однопоточная часть может значительно снизить производительность. Один пример: если в агрегировании, например Sum(Quantity*ListPrice), есть несколько полей. Если Quantity находится в таблице фактов, а ListPrice — в основной таблице продуктов, подсистема сначала должна соединить эти две таблицы для нахождения комбинаций, а потом она сможет начать суммировать продукт. Соединение — однопоточная часть, а суммирование — многопоточная. Если оба поля находятся в одной таблице, соединение не требуется и агрегирование вычисляется значительно быстрее. |
|
Сократите до минимума использование функции Aggr() и вложенной функции Aggr() |
Функция Aggr() существенно влияет на производительность. Неправильное использование может стать причиной неточных результатов. Например, в таблице с измерениями, которые отличаются от измерений в функции Aggr(). Для получения дополнительной информации см. Когда не следует использовать AGGR? |
|
Используйте анализ множеств, если возможно |
Можно использовать анализ множеств для определения множества значений данных, отличных от обычного множества, определяемого текущими выборками. Для получения дополнительной информации см. Анализ множеств. |
|
Избегайте сравнения строк, если возможно |
Сравнение строк не так эффективно, как анализ множеств. Например, следует избегать Match(), MixMatch(), WildMatch() и Pick(). Вместо этого создайте флаги в скрипте или используйте анализ множеств. Для получения дополнительной информации см. Условные функции и Производительность условных агрегирований. |
|
Используйте условия вычисления для объектов, содержащих интенсивные вычисления |
Например, рассмотрим визуализацию со многими записями и отсутствием выборок. Рекомендуется добавить условия вычисления к объектам, чтобы они визуализировались только после того, как сделаны определенные выборки. Это предотвращает создание очень больших гиперкубов. Например: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. В этом сценарии визуализация не будет выполнена, если пользователь не выберет одну страну или не создаст другую выборку, в которой возможна только одна страна. |
|
Вычисляйте меры предварительно в скрипте, если возможно |
Любую меру, которая находится на самом низком уровне детализации модели данных, следует вычислять в скрипте. Например, если в одной и той же записи в таблице есть Sales и Cost, можно получить маржу путем вычисления Sales - Cost AS Margin. Можно также заранее агрегировать другие значения, если известно, что они не изменятся в зависимости от выборки или они привязаны к другому уровню детализации. |
|
Используйте таблицы, которые имеют меньше 15 столбцов и условия вычисления |
Таблицу с 15 столбцами можно считать широкой. Если таблицы состоят из многих записей, рекомендуется использовать условия вычисления для объекта таблицы, чтобы он визуализировался только после того, как сделаны определенные выборки или выполнены критерии. Если таблица очень широкая, следует:
|
|
Не создавайте слишком много объектов на листе |
Объекты вычисляются при переходе пользователя на лист. При выполнении любой выборки на листе каждый объект будет вычислен повторно, если то текущее состояние отсутствует в кэше. Если на листе много диаграмм, пользователь почти при каждой выборке должен ждать, пока каждый объект не будет вычислен. Это создает значительную нагрузку на подсистему. Рекомендуется следовать концепции Dashboard/Analysis/Reporting (DAR) для разработки чистого и минималистичного приложения. Для получения дополнительной информации см. методологию DAR. |
|
Применяйте числовые флажки в скрипте для использования в анализе множеств |
Анализ множеств с флагами может быть эффективнее, чем использование сравнений строк или умножения. |
| Основные элементы позволяют перетаскивать управляемые показатели и гарантируют кэширование выражений. Например, Sum(Sales) отличается от SUM(Sales). Выражения кэшируются с учетом написания и регистра и должны соответствовать дословно, чтобы их можно было использовать повторно. |