Узнайте, как создать многоуровневую архитектуру QlikView

Правильная архитектура QlikView является одной из основ успешной реализации. Когда наши Qlik разработчики начинают работать, мы просто выполняем загрузку данных в приложение и наблюдаем отображение нескольких диаграмм на экране. Но очевидно, что по мере того, как мы расширяемся в рамках нашей среды, этот подход с одной остановкой больше не работает. Существует много вариантов многоуровневой архитектуры Qlik с соответствующими плюсами и минусами. Поэтому я подумал, что было бы хорошим решением выложить все варианты, чтобы вы могли решить, какие слои вы захотите в своей реализации. Эта статья может быть применена как к архитектуре QlikView, так и Qlik Sense.

Примечание о сохранении данных на уровнях

Обычно для приложений, которые служат для обработки данных в QVD (извлечение и преобразование), нет необходимости сохранять эти данные в QVW. Это означает, что в конце этих скриптов вы должны удалить таблицы из приложения. Это позволит очень быстро сохранить ваши приложения и ускорит открытие приложения для следующей перезагрузки.
Обычно я собираю метаданные и показываю их на главной странице, но, как правило, в этих приложениях нет других визуализаций. Конечные пользователи никогда не должны их видеть.

Уровень выделения

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

Экстракция данных не должна быть столь же болезненной, как удаление зубов.
Это, как правило, первый слой, который я создаю, потому что он обладает замечательным преимуществом, позволяющим сделать разработку более эффективной. Так как QVD загружаются намного быстрее, чем данные из базы данных, я могу создать QVD один раз, а затем полагаться на QVD для моей первичной разработки, возвращая соединения только в базу данных, прежде чем продвигать приложение в производство. Как правило, я использую 2 набора строк сценария источника данных для каждой загрузки и просто комментирую и раскомментировываю по мере необходимости.

Экстрагирующий слой также является основным способом масштабирования Qlik. Уровень извлечения предоставляет нам дубликат таблиц базы данных, которые мы можем затем загружать столько раз, сколько хотим в последующие приложения Qlik, без необходимости возвращаться к исходной базе данных. Добавление логики дополнительной загрузки делает уровень экстракции еще более эффективным, ограничивая доступ к базе данных только самыми последними или измененными записями. Это ваше основное оружие в войне с масштабируемостью. Я считаю, что у всех реализаций должен быть этот слой.

Вход: исходные источники данных
Выход: Извлеченные QVD
Плюсы: Скорость разработки, механизм масштабирования, изоляция соединений базы данных
Минусы: Очень незначительный — время до начала установки приложений и задач, многоступенчатый процесс обновления данных

Трансформационный слой

Сделайте ваш код прекрасным.
Трансформационный слой — это способ массирования данных для прямого анализа. Здесь вы переименуете поля, применяете бизнес-логику, выполняете некоторые размерные объединения и, возможно, агрегируете таблицы фактов с различной степенью детализации. Как правило, мы будем загружать данные из наших экстрактов QVD, завершать наши шаги преобразования и сохранять полученные таблицы в преобразованные QVD.
На этом уровне архитектуры Qlik Sense я обычно добавляю в любые источники данных не-базы данных, а не включаю их в процесс извлечения. Это малоцелесообразно, например, для извлечения данных из электронной таблицы в QVD. Нет причин, по которым мы не можем начать с этих видов источников в трансформационном слое.
Мы должны также немного рассказать о детализации. В основном, когда дело доходит до транзакционных данных, мы загружаем все строки в QlikView, потому что мы хотим иметь возможность вести сводку вплоть до мельчайших деталей. Однако многие панели лучше обслуживаются с агрегированным уровнем данных. К этой категории могут относиться панели Executive Multi-Subject. Поэтому, если фактически таблицы должны иметь версии, которые агрегируются на один уровень, это также должно быть сделано на уровне преобразования.
Основным преимуществом уровня трансформации является то, что мы можем использовать один набор бизнес-логики и условных обозначений для управления всей реализацией. Лучше применять логику один раз, чем повторять разработку в восьми разных скриптах Qlik. И поскольку все переименование выполняется в одном месте, мы можем помочь устранить путаницу в отношении соглашений об именах, которые естественно будут отличаться в приложениях.

Вход: Извлеченные QVD
Выход: Трансформированные QVD, агрегированные QVD
Плюсы: Эффективность обслуживания, механизм масштабируемости, универсальные определения бизнеса
Минусы: Первоначальное время для настройки приложений и задач, процесс обновления данных Multi-Step

Слой DataMart

Традиционно пользовательский интерфейс является последним слоем. Здесь мы загружаем преобразованные QVD и создаем наши панели UI с графиками и диаграммами, запрошенными клиентом. Концепция уровня Data Mart просто отделять часть модели данных от пользовательского интерфейса. Мы загрузим трансформированные QVD и создадим необходимые связанные ключи, при желании применим autonumber, добавим наш календарь и любые другие несвязанные таблицы. Это создает законченную модель данных для приложения, о чем свидетельствует средство просмотра таблиц. Но пользовательский интерфейс не будет добавлен. Обратите внимание, что в этом слое мы сохраняем данные в QVW.
Вместо этого мы создаем еще один QVW, который Binary Loads Data Mart использует для создания пользовательского интерфейса, со всеми необходимыми диаграммами и графиками, и профессиональным внешним видом, который все мы привыкли получать в Qlik.

Это довольно актуально.
Для этого уровня имеются специфические для конкретного случая преимущества. Во-первых, он служит изоляцией для разработки от деятельности дизайнера. Используя этот метод, мы не должны предоставлять разрешения на чтение или подключение к QVD разработчикам Qlik. Во-вторых, мы можем повторно использовать общие модели данных Qlik в нескольких приложениях. Одна модель данных может поддерживать представление руководителя и представление аналитика.
Мое мнение о слое DataMart заключается в том, что некоторые организации могут эффективно использовать это, в то время как другие могут не видеть преимущества.

Вход: Трансформированные QVD
Выход: Модель данных QVW
Плюсы: Изолирует разработку модели данных от дизайна панели, возможность повторного использования модели данных
Минусы: могут ли перевесить плюсы? — Первоначальное время для настройки приложений и задач, процесс обновления данных Multi-Step

Архитектура QlikView: все вместе

Ниже приведены некоторые рисунки, которые помогут вам визуализировать различные слои во всей архитектуре. Если вы хотите удалить уровень, вы просто объедините две строки QVW в одну, исключая любые строки QVD между ними, если они есть.


Финальные мысли

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

Найти решение у бизнес-партнера QlikTech (QlikView) в России.

Форум разработчиков QlikView и Qlik Sense. Получите ответы на все вопросы по QlikView и Qlik Sense!

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

64 queries in 0,394 seconds