Работа с анализатором метаданных приложений («App Metadata Analyzer»)
- Обнаружение аномалий
- Видимость/стандартизация моделей данных (например, для контроля выпускаемых в промышленную эксплуатацию приложений)
- Оптимизация моделей данных
- Видимость/проверка балансировки нагрузки
Цель
Использование анализатора метаданных приложений (см. раздел «Анализатор метаданных приложений («App Metadata Analyzer»)») обеспечивает:
- Понимание состава всех моделей данных на всем сайте Qlik.
- Отслеживание приложений с синтетическими ключами, островками данных и циклическими ссылками.
- Отслеживание объема RAM, требуемого для при первом открытии приложения – это помогает выполнять сайзинг оборудования и балансировку нагрузки.
- Отслеживание того, какие поля можно удалить/оптимизировать – анализатор отображает их размер и долю от всех полей в приложении.
- Возможность применения пороговых значений на уровне приложения, таких как: общее количество записей, общее количество полей, общее количество таблиц, размер на диске и т. д., что позволяет использовать механизмы, подобные стробированию, для обеспечения стандартов моделирования данных и передовых методов на сайте Qlik Sense.
Демо-видео
Предварительное условие
Если анализатор метаданных приложений еще не импортирован на сайт, перейдите в подраздел «Где найти приложение» (см. раздел «Анализатор Метаданных Приложений («App Metadata Analyzer»)»), чтобы получить инструкции о получении приложения.
Проверка того, что анализатор метаданных приложений настроен и работает
В хабе перейдите к потоку «Monitoring apps» («Приложения мониторинга») или к тому потоку, в который было опубликовано приложение анализатора метаданных и нажмите кнопку «Details» («Подробности» – значок информации) у приложения «App Metadata Analyzer». Убедитесь, что данные приложения актуальны.
Если анализатор метаданных приложений устарел, обратитесь к разделу «Анализатор Метаданных Приложений («App Metadata Analyzer»)» для получения сведений о настройке и устранению неполадок.
Примечание
Поскольку анализатор метаданных приложений не импортируется в QMC по умолчанию, рекомендуется запускать для него еженощную задачу обновления данных. При желании приложение, конечно, можно перезагружать чаще, но рекомендуется делать это каждую ночь.
Установка пороговых значений
Перейдите в редактор загрузки данных и выберите вкладку конфигурации («Configuration»). На этой вкладке можно установить дополнительные переменные для настройки пороговых значений. Убедитесь, что для этих параметров установлены значения, которые организация не хочет превышать. Например, если не требуется иметь в приложениях таблицы данных с более чем 100M записей, тогда для vTableRecordCountThreshold можно установить значение 100000000.
С помощью этих переменных будут найдены приложения, которые нарушают установленные пороговые значения, и приложения могут быть помечены и легко выбраны в процессе анализа.
Работа с оповещениями
В версии 2.2.1 и более поздних версиях анализатора метаданных приложений был добавлен новый лист «Alerting», а также две новые переменные в скрипте загрузки. Цель этого листа и добавленного функционала – максимально упростить интеграцию с Qlik Alerting. Эта новая возможность и представление позволяют администратору Qlik легко видеть, какие приложения превышают пороговые значения (и сколько их), и быстро получать об этом предупреждения. Это также позволяет администратору отключать оповещения для определенных приложений и отмечать другие как находящиеся на рассмотрении, для которых требуется другая частота уведомлений.
Настройка тегов (опционально)
Перейдите в Редактор загрузки данных и выберите вкладку конфигурации («Configuration»). На этой вкладке необязательные переменные могут содержать имена тегов в QMC.
vu_ignore_alert_tag_name: эта переменная содержит имя тега, которым администратор Qlik может пометить приложение, о котором он не хочет получать оповещения.
vu_review_alert_tag_name: эта переменная содержит имя тега, которым администратор Qlik может пометить приложение, которое «в настоящее время находится на рассмотрении», например, администратор Qlik обнаружил проблемное приложение и получил подтверждение, что разработчик работает над решением проблем. Это позволяет администратору не получать многократных оповещений об этих помеченных приложениях.
По умолчанию для этих переменных используются строковые значения, которые, если они не найдены в QRS, не влияют на приложение. Проще говоря, если теги не используются, будут приходить оповещения обо всех приложениях.
Предлагаемый рабочий процесс и руководство по настройке
Администратору Qlik не обязательно иметь Qlik Alerting, чтобы использовать этот новый лист. Администратор может просто периодически заходить на этот лист и проверять приложения вместо того, чтобы получать предупреждения о приложениях.
Руководство по настройке Qlik Alerting с анализатором метаданных приложения с предложенными рабочими процессами и примерами можно найти на странице сообщества Qlik в анализаторе метаданных приложений (Windows), а именно здесь: Qlik Alerting with the App Metadata Analyzer for QSEoW.
Постановка целей
Это приложение может использоваться для множества различных целей, в зависимости от среды, в которой оно выполняется (Разр., Тест., Прод. и т. д.). Решите, каковы общие цели приложения для администратора.
Предлагаемые цели на каждом уровне
-
Разработка
- Использовать, чтобы получить представление/ясность в отношении того, что делают разработчики/обеспечить соблюдение пороговых значений.
- Использование в качестве стробирующего механизма для более высоких уровней. Приложения должны соответствовать стандартам моделирования данных и существовать ниже желаемых пороговых значений, если не предоставлено обоснование исключения.
- Определить разработчиков, которые могут быть кандидатами на обучение на курсах моделирования данных. То есть те, у которых есть много приложений с синтетическими ключами, очень много полей/много таблиц и т. д. Это может быть актуально для организаций, у которых много разработчиков.
- Тест
- Использование для оптимизации. См. Раздел «Оптимизация» ниже.
- Использование для оптимизации. См. раздел «Оптимизация» ниже.
- Определить приложения-кандидатов для балансировки нагрузки. См. Раздел о балансировке нагрузки в статье «Пересмотр/обновление плана производительных мощностей».
- Прод
Оптимизация
Цель этого подраздела – оптимизировать модели данных приложений, отдавая приоритет приложениям с большим объемом базовой оперативной памяти (объем оперативной памяти, который приложение занимает на сервере при первом открытии без каких-либо пользователей).
Выявление приложений, использующих большой объем RAM при первом открытии.
Перейдите на лист информационной панели («Dashboard»).
Взгляните на таблицу объема памяти приложений («App Memory Footprint (MB)»). В этом примере есть приложение, которое занимает ~ 63 ГБ ОЗУ.
Отдавайте предпочтение крупным и широко используемым приложениям. Обратитесь к разделу «Анализ использования приложений», чтобы узнать, как просмотреть работу пользователей с приложением, а затем по описанным там сценариям проверьте каждое большое приложение.
Выявление полей для оптимизации
Для каждого большого приложения, указанного выше, найдите поля, которые занимают большой объем оперативной памяти. См. таблицу объема памяти для полей (« Field Memory Footprint (MB)»). В этой таблице показаны таблицы символов (для подробного ознакомления с таблицами символов и таблицами данных см. Эту статью на сайте сообщества Qlik). Если значения в этой таблице большие, это обычно означает, что значения поля длинные и неуникальные. Возьмем, к примеру, поле комментария – длинные текстовые значения с очень большим числом элементов. Важно убедиться, что такие поля оптимизированы/необходимы для анализа, так как именно они могут быстро добавить веса приложениям.
Можно ли оптимизировать эти поля или потенциально удалить их, если они не используются? Или, например, есть ли поля, содержащие временные метки? Такие поля можно разделить на несколько полей для уменьшения количества элементов?
Чтобы проверить, не используются ли поля, рекомендуется использовать анализатор приложений Роба Вундерлиха. Этот инструмент используется для переноса отдельного приложения в RAM и его анализа, а затем предоставления подробных результатов в виде приложения Qlik. Это отличный помощник для анализатора метаданных приложений, поскольку анализатор метаданных приложений позволяет выявлять потенциальные приложения, которые могут использовать оптимизацию, а затем анализатор приложений может детализировать низкоуровневые детали этого приложения. Он также может оптимизировать пользовательский интерфейс приложения, что не рассматривается в этой статье.
Выявление таблиц для оптимизации
Для каждого большого приложения, указанного выше, найдите таблицы, которые занимают большой объем оперативной памяти. Взгляните на таблицу «Table Memory Footprint (MB)» на листе «Dashboard». В этой таблице показаны таблицы данных (статья в сообществе Qlik). Чем больше записей/столбцов в таблице, тем выше объем памяти, занимаемой таблицей.
Сколько полей существует в этих таблицах? Если в таблице много полей (например, сотни), вполне вероятно, что разработчик использует подход SELECT * FROM, и, вероятно, есть много полей, которые не используются для анализа в приложении. Это еще одна отличная возможность использовать анализатор приложений Роба Вундерлиха для удаления многих полей.
Также стоит учитывать общее количество записей в таблицах. На приемлемом ли они уровне? Возможно ли, что таблицу или часть таблицы можно агрегировать, или можно использовать альтернативные подходы, такие как сегментация приложений, объединение приложений в цепочку или создание приложений по запросу?
Примечание
При работе с большими объемами данных существует множество стратегий при проектировании архитектуры ваших приложений. Вот три стратегии:
Сегментация: сегментация QVD и QVF по временным фреймам или другим параметрам, например регионам. У вас может быть QVF, который просматривает последние два года, и еще один, который просматривает на годы назад, и один большой QVF, содержащий все данные, которые используются только при необходимости небольшой группой пользователей. Другой подход может заключаться в том, чтобы несколько приложений были ориентированы на разные регионы, чтобы пользователь не открывал приложение с данными, которые им не интересны или которые они не имеют права видеть (данные, которые не могут быть просмотрены из-за ограничений секции доступа, по-прежнему влияют на память). С помощью этого метода большинство пользователей будет использовать более легкое приложение (самые свежие данные), экономя память, поскольку это все, что им обычно нужно.
ODAG: ODAG означает создание приложений по запросу и представляет собой метод, в котором у вас есть два приложения, например:
1. корзина для покупок (агрегированные данные),
2. пустой шаблон приложения для отображения деталей.
Рабочий процесс таков, что пользователь должен сначала сделать выбор в приложении корзины покупок (этот критерий полностью настраиваемый), и после того, как пороговое значение будет достигнуто, создается настраиваемый сценарий LOAD, который затем заполняет приложение-шаблон любой запрошенной детализацией.
Цепочка документов: цепочка документов – это когда у вас есть агрегированное приложение, которого обычно достаточно для пользователя, но когда пользователю действительно нужны детали, выбор может быть передан из агрегированного приложения в приложение подробностей, чтобы они могли просматривать более низкий уровень детализации. Это сокращает объем занимаемой каждым пользователем оперативной памяти, тем самым освобождая ее для остальных пользователей. Хотя механизм цепочки документов напрямую доступен в QlikView, в Qlik Sense он поддерживается через API и, соответственно, через расширения.
Более подробную информацию об оптимизации приложений и моделей данных можно найти на веб-сайте Набора инструментов для диагностики.
Вместе оба этих показателя (таблицы ОЗУ и поля ОЗУ) составляют базовую площадь ОЗУ.
Выявление синтетических ключей и островков данных
Перейдите к листу анализа пороговых значений («Threshold Analysis»).
На каждом листе слева внизу есть две таблицы:
Если есть синтетические ключи, в большинстве случаев это признак проблемы в модели данных, и эти проблемы нужно исправить. Конечно, есть сценарии, когда синтетические ключи безвредны и фактически являются самым оптимальным вариантом, но обычно это не так. Для получения дополнительной информации см. статью Блог о дизайне Qlik: синтетические ключи.
Если есть островки данных, их также следует по возможности избегать и попытаться исправить в модели. Дополнительные сведения см. В статье Роба Вундерлиха «Влияние островов данных на кэш и процессор».
Повторите процесс для островов данных, выбрав «Has Synthetic Keys» (имеет таблицу островков) и просмотрев связанные приложения и таблицы островков.
Обзор балансировки нагрузки
Если на сайте Qlik Sense есть более двух узлов, используемых для работы конечных пользователей, стоит подумать о «закреплении» (балансировке нагрузки) больших приложений на выделенных движках (требуется более двух для обеспечения отказоустойчивости).
Обратитесь к разделу балансировки нагрузки в статье «Пересмотр/обновление плана производительных мощностей», где объясняется этот процесс.
Дополнительные сведения о балансировке нагрузки ресурсов и инструкции о том, как это сделать, см. В разделе «Разделение больших приложений Qlik» статьи «Обзор закрепления приложений/балансировки нагрузки».
