Как сделать приложение Qlik таким, чтобы оно работало быстро и требовало как можно меньше ресурсов во время выполнения вычислений? Один из самых очевидных ответов – загрузка в модель данных только необходимых данных. Сегодня рассмотрим инструменты для этого на примере приложения Aaron Couron, Filtering Data.qvw.
Например, если наша цель – проанализировать данные колл-центра за последние 12 месяцев, нам не нужно загружать в модель данные с 2000 года. Или, допустим, в колл-центре есть сотрудники, которые уже уволились или ушли на пенсию. И если нам нужно проанализировать деятельность колл-центра за последний год, то весь список сотрудников колл-центра подгружать нет необходимости.
Итак, давайте разберем работу с моделью данных на примере приложения QlikView, которое может легко быть перестроено под Qlik Sense. Скачайте файл:
Почему нужно удалять данные из приложений Qlik?
Какое имеет значение, есть ли у нас в приложении есть дополнительные данные? На это есть несколько причин.
Пользовательский опыт
Добавление нерелевантных данных приводит к усложнению работы пользователя. Например, нам нужно загрузить в приложение по анализу закупок наших покупателей. Если имена покупателей также находятся в таблице Сотрудники, мы, вероятно не захотим загружать в приложение 2500 сотрудников, чтобы добавить имена 6 покупателей. Лучше добавить 6 имеющихся покупателей, чем весь список имен сотрудников – пользователм так будет гораздо проще работать с данными.
Скорость работы приложения
Не смотря на скорость выполнения вычислений и достаточно мощный движок Qlik, простая модель данных выполняет вычисления быстрее, а сервер потребляет меньше ОЗУ для этого приложения. Это особенно важно с увеличением объема данных (например, при анализе чеков в ритейле).
Какие инструменты пригодятся?
Обязательно скачайте QV Document Analyzer от Rob Wunderlich. Если вы его скачивали давно. Рекомендую обновить версию, ведь в него вносятся изменения с выходом новых версий QlikView.
QV Document Analyzer расскажет все о вашем приложении: сколько оно потребляет памяти и, сколько времени требуется для выполнения вычислений. Мы будем его использовать для оценки скорости вычислений и объема затрачиваемой памяти.
Сокращение строк
Посмотрите на ваши данные с точки зрения колонок и строк. Строки, очевидно, отсылают к количеству записей в каждой таблице, а колонки – к уникальным именам полей. Итак, начнем процедуру со строк.
Есть несколько функций, чтобы сократить строки в вашем приложении. Рассмотрим некоторые приемы.
Условия Where
Когда мы говорим о таблице фактов, нужно логически продумать, как ограничить количество строк. Первая таблица фактов в нашем примере – таблица продаж (Sale). Бизнес-требование здесь – аналитика данных только текущего года и полного предыдущего года. Поэтому объем данных мы ограничим через условие Where.
НА ЗАМЕТКУ! Поскольку условие Where используется в выражении выборки, мы используем синтаксис MSSQL, чтобы сократить запрос данных
Итак, используйте Where, если вам нужно сократить количество строк в факт-таблице.
Объединение таблиц: Left Keep
Таблица измерений – это таблица, которая обогащает таблицу фактов дополнительным контекстом. Таблица с информацией по клиентам, географическим данными или мастер-данными – это всё примеры таблиц измерений.
В таблице ниже мы используем функцию Left Keep, чтобы сократить количество данных, которые будут связаны с таблицей продаж. Поскольку это не Join, таблицы не будут слиты в одну. Поскольку это Left Keep, левая таблица (Sales) будет загружена полностью, а из правой таблицы (Item) будут загружены только необходимые значения:
Объединение таблиц: Where Exists
Функция Where Exists просит QlikView сравнить только что загруженные поля с предыдущими. Там, где найдено совпадение, вся строка загружается.
В первом примере ниже мы определяем одно поле сравнения – загружаем все строки, где есть код клиента (Customer Key), а остальные строки игнорируем:
В примере ниже видно, что мы ссылаемся на два поля. Первое – ранее существующее поле. А второе поле – то, которое загружаем.
НА ЗАМЕТКУ! Второй параметр в функции Where Exist не принимает алиасы, так что если вы использовали алиас в начале скрипта, то в параметре функции вам нужно указать изначальное имя поля. Кроме того, второй параметр можно создавать и через выражение, что бывает очень полезно.
Обычно функция Where Exists выполняется быстрее, чем Left Keep, да и не нужно думать, как Left Keep свяжет поля.
Результаты работы по сокращению строк
Сначала мы поработали с факт-таблицей, а затем с таблицей измерений. Пришло время понять, стоили ли наши усилия потраченного времени.
Используем QV Document Analyzer для сравнения документа до и после. Вот, что вышло:
Сокращаем колонки
Теперь перейдем к колонкам. На вкладке «Fields» в QV Document Analyzer мы увидим, что наш дэшборд не использует 53 загруженных поля. Возможно, некоторые из них действительно не нужны нам для работы. Для этого воспользуемся функцией Drop Field и укажем список полей «на вылет»:
.
Однако не все неиспользуемые сейчас поля стоит выкидыать из приложения – подумайте, возможно, какие-то поля могут пригодится вашим пользователям впоследствии для аналитики и расширения контекста.
НА ЗАМЕТКУ! Легко написать Drop Field, но некоторые поля лучше сразу и не подгружать – просто закоментите их в скрипте загрузки. Возможно, это чуть дольше, зато изначально ненужные данные не будут грузится в модель, занимая время и RAM.
Вот и пример закомментированных полей в скрипте загрузки:
Результаты работы с колонками
После оптимизации мы получили всего 23 поля. Вот, какая получилась модель данных!
Вновь запускаем наш QV Document Analyzer и видим, что сократился объем RAM. Время вычислений не изменилось с прошедшего теста, т.к. оно базируется на количестве строк:
А вот такой дэшборд у нас получился (для лучшего понимания примера):
Уделяйте время оптимизации приложения, используйте только те данные, которые вам необходимы.
Удачных вам разработок!
Свежие комментарии