Как сравнить Power BI и Qlik с точки зрения TCO (Совокупная стоимость владения)

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

Ниже представлены ключевые отличия с точки зрения совокупной стоимости владения.

Лицензии/программное обеспечение

И Power BI и Qlik – это современные инновационные инструменты визуальной аналитики со множеством интересных возможностей для создания потрясающих информационных панелей и отчетов. Оба продукта предлагают широкие возможности для дизайна отчетов. Однако, все же ключевое отличие с точки зрения UIX заключается в том, что у Qlik есть очень мощный ассоциативный механизм, также называемый «power of grey», с которым вы сможете найти и открыть новые идеи в ваших данных. Учитывая то, что Power BI гораздо более иерархическая (детализированная) система, вам нужно будет приложить больше усилий, чтобы извлечь новые идеи или найти то, что вы ищете. Тем не менее, когда вы начинаете небольшой BI проект (мало данных и мало пользователей) и сравниваете инструменты с точки зрения визуальной аналитики, различия не существенны. А вот с точки зрения TCO (стоимость владения) вы увидите существенную разницу и поймете, что Power BI намного дешевле, чем Qlik.

Актуальная цена Power BI составляет 8,40 ЕВРО за одного пользователя (Power BI Pro)*

Актуальная цена Qlik составляет 36,25 ЕВРО за одного пользователя в месяц (Qlik Analyzer)**

*Power BI Pro ограничивает размер приложения до 1 ГБ. Чтобы преодолеть это ограничение, вам необходимо будет подписаться на Premium, максимальное ограничение по которому составляет уже 10 ГБ (от 4212,30 Евро в месяц). Чтобы преодолеть и это ограничение, вам нужно использовать прямой запрос, а это будет иметь огромное влияние на производительность.

**В Qlik есть разные типы лицензий, такие как Analyzer, Professional и Capacity, поэтому общие затраты на пользователя отличаются в зависимости от обстоятельств.

Внутренняя архитектура

Ещё одно существенное отличие этих продуктов заключается в том, что в Power BI используется только облачная стратегия. Это означает, что Power BI всегда работает на платформе Microsoft Azure. Облако предлагает множество преимуществ с точки зрения масштабируемости, гибкости и интеграции с другими сервисами. Однако при работе с конфиденциальными данными вы захотите сохранить контроль над своими данными. Кроме того, с точки зрения стратегии архитектуры его иногда необходимо устанавливать в вашем помещении, в частном облаке или в общедоступном облаке (AWS, Google и т. д.). Qlik в этом отношении очень гибкий и дает вам полностью гибридные и мультиоблачные возможности.

С точки зрения совокупной стоимости владения это будет означать, что, если вы еще не инвестировали в Microsoft Azure и хотите внедрить Power BI, в ваш проект нужно добавить дополнительные расходы на Microsoft Azure, а это повысит совокупную стоимость владения. Я лично считаю, что Microsoft Azure – отличная платформа со множеством возможностей, весьма гибкая для развития вашей ИТ-инфраструктуры. Тем не менее, после нескольких проектов я понял, что она требует обширных знаний для работы со всем функционалом. Поэтому имейте в виду, что для этого вам понадобятся дополнительные (внешние) ресурсы.

С точки зрения затрат мы видели, что использовать Azure не очень дешево и что стоимость использования продуктов Microsoft, особенно систем хранения (Azure SQL, Azure DWH), может быть очень высокой и непредсказуемой. И неудивительно, что каждая дополнительная служба в Azure оплачивается, и, когда вы узнаете об этом, то начинаете понимать, что это очень дорогая среда. Подход Microsoft к своему позиционированию заключается в том, чтобы доминировать на рынке облачных вычислений, поэтому стратегия Power BI основывается на привязке к Microsoft Azure. Мульти-облачная стратегия Qlik предназначена для адаптации к облачной стратегии клиента без привязки к конкретному поставщику.

Реализация

Еще одно отличие – сложность продукта. Power BI пользуется очень большой популярностью среди клиентов, которые уже используют Office 365 и Microsoft Azure. Преимущества Power BI заключаются в том, что он уже включен в O365, требует небольших затрат и позволяет сразу же приступить к анализу. Кроме того, у вас есть хорошие возможности для совместного использования и хорошее ИТ-внедрение, это – общая зона комфорта.

По моим личным наблюдениям, я вижу высокий уровень принятия в пользовательской базе Advanced Excel, поэтому мы видим, что многие финансовые отделы переходят на Power BI, благодаря их опыту с Excel, простоте использования, отсутствию прямой необходимости в техподдержке, возможностям модификации и удобным функциям отчетов/информационных панелей. Хотя Qlik всегда выступал за самообслуживание в бизнес аналитике, лично я считаю, что многие пользователи видят это иначе, чем Power BI. Конечно, когда вы познакомитесь с продуктом Qlik, пройдя определенный курс обучения (проб и ошибок), то увидите много преимуществ по сравнению с функциями в Power BI. Все же я считаю, что начальное самообслуживание с Power BI лучше.

Вернемся к сложности продукта. Мы видим, что Power BI это не просто еще один инструмент. Это комбинация нескольких инструментов и сервисов для визуализации с самообслуживанием и распространения контента.

Как поставщик готовых стеков, Microsoft, кроме всего прочего, предлагает множество других компонентов, которые могут понадобиться при развертывании проекта Power BI, такие как (Azure) SQL Server, службы Reporting Services, службы Analysis Services, Azure SQL DW и многие другие. Таким образом, с точки зрения совокупной стоимости владения это может означать, что стоимость будет намного выше, если эти продукты понадобятся, а также для получения навыков работы с ними.

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

Также я вижу, что Qlik вкладывает значительные средства в новые функции (машинное обучение, индекс больших данных, когнитивные способности, расширенный интеллект, анализ речи и т. д.). Все они реализованы в продукте Qlik Enterprise. Microsoft также инвестирует в эти темы, но это все новые (платные) продукты или услуги на платформе Azure.

Выводы

  1. Power BI изначально намного дешевле, чем Qlik, особенно для небольших проектов.
  2. Типичное решение Power BI не всегда стоит 8,40 евро за пользователя в месяц, оно представляет собой сложную совокупность многих продуктов, что приводит к более высокой сложности всей системы, большим затратам и большему количеству отказов; У Qlik интегрированное предложение продукта и гибридное облако.
  3. В решении Power BI понадобятся дополнительные компоненты, но вы можете заметить это через год работы или сразу после покупки, однако в любом случае, это приведет к непредвиденным расходам в будущем.
  4. Стоимость лицензии за первый год составляет небольшую долю от совокупной стоимости владения, поэтому клиент должен оценивать именно совокупную стоимость владения для принятия решения.
  5. При масштабах развертывания, от 25-30 пользователей и выше, стоимость владения Qlik в перерасчете на одного пользователя ниже, чем Power BI.
  6. Power BI – очень хороший инструмент визуальной аналитики, который идеально подходит для тех компаний, которые уже вложили средства в Microsoft Azure. Суммарная стоимость владения делится с другими используемыми ресурсами.

НАСТРОЙКА ПРАВИЛ БЕЗОПАСНОСТИ В QLIK SENSE QMC

Если вы уже знакомы с QlikView и собираетесь перейти на Qlik Sense, вы увидите много общего между ними. Скрипты и запись выражений у них одинаковые.

Однако, QMC сильно отличается. И одно из главных отличий – это подход к пользователям. Обычно QMC в QlikView использовалась только командой разработчиков. Однако в Qlik Sense вам необходимо отойти от этой концепции и перейти в такую среду, где есть гораздо больше людей, использующих отчеты, и которые имеют доступ к QMC.

Типичное бизнес-требование Qlik Sense:

  • Разработчик будет извлекать и преобразовывать данные, настраивать модели данных, создавать приложения Sense, создавать стандартные выражения, измерения и визуализации в основных элементах.
  • Затем пользователь будет использовать эту информацию, а суперпользователи захотят и дальше дорабатывать приложения, добавляя новые данные и визуализации. Они захотят опубликовать пересмотренные информационные панели, чтобы другие могли использовать эту информацию.

(Если второе утверждение заставило вас вздохнуть и покачать головой, то вам следует заставить себя идти в ногу со временем, ведь ситуация меняется, и если вы сейчас начнете немного отставать, то вскоре безнадежно отстанете!)

Надеюсь, вы уже знакомы с концепцией Потоков Ресурсов. Их можно рассматривать как папки в Qlik Sense Hub, в которых можно хранить приложения. Пользователям может быть предоставлен доступ к этим потокам с использованием правил безопасности в Qlik Sense QMC.

Правила безопасности могут определить намного больше. Общее правило: они могут определять все:

  • Доступ к Потокам Ресурсов
  • Возможность создать новое приложение
  • Возможность редактировать существующее приложение
  • и т.д.

Это все правила Hub.

Правила также можно создавать для того, чтобы назначать разным пользователям разные права, контролируя их действия в QMC. Опять же, вы можете уже знать о стандартных ролях; «Root Admin», «Content Admin» и т. д. Эти роли разрешают пользователю доступ к определенным областям QMC, хотя они предназначены по сути для всего. Если вы являетесь администратором контента, то можете публиковать, удалять, редактировать любое приложение, перезагружать задачу, ресурс подключения к данным для любого потока. Это хорошо, если вы придерживаетесь традиционной структуры бизнес аналитики центральной группы разработчиков. Если нет, вам придется создать правильные правила для вашего бизнеса.

Роли безопасности могут только предоставлять доступ, но не ограничивать его! При установке сервера Qlik Sense у вас будет довольно большое количество автоматически определенных правил. Большинство из них вы сохраните, а некоторые придется отредактировать или отключить.

В общем случае правило может читаться как предложение: «Разрешить запрашивающей стороне [действие] [ресурс] при условии, что [условия]».

Я управляю запрашивающей стороной с помощью настраиваемого свойства, которое я установил в QMC (есть и другие методы). Для каждого ресурса у меня есть два свойства, которые затем выделяются пользователям, например:

  • Finance – Пользователь
  • Finance – Администратор
  • Sales – Пользователь
  • Sales – Администратор

У меня есть второе Настраиваемое Свойство для Ресурсов (Ресурсы, которые я также отношу к ним: Приложения, Объекты приложений, Соединения данных, Задачи перезагрузки и Потоки), например:

  • Финансы
  • Продажи

У меня есть общие правила, которые предоставляют доступ, который не зависит от ресурса:

  • Доступ администратора к разделам QMC
  • Доступ администратора к созданию приложения
  • Доступ администратора к ресурсам, которым не назначено пользовательское свойство

Затем я установил ряд правил для каждого ресурса, который я подключил к сети, в настоящее время их шесть:

  • Доступ администратора ко всем приложениям, относящимся к группе ресурсов (Hub и QMC)
  • Доступ администратора ко всем объектам приложения, относящимся к группе ресурсов (QMC)
  • Доступ администратора ко всем соединениям данных, относящимся к группе ресурсов (Hub и QMC) – пример ниже
  • Доступ администратора ко всем задачам перезагрузки, относящимся к группе ресурсов (QMC).
  • Доступ администратора к потоку, связанному с группой ресурсов (Hub и QMC)
  • Доступ только для чтения к потоку, связанному с группой ресурсов (Hub)

Причина, по которой у меня так много правил, заключается в том, что вы не можете просто создать правило администратора, так как каждый ресурс имеет собственный набор типов разрешений; Создать, Прочитать, Обновить, Удалить, Экспортировать и т. д., И вы должны определить их индивидуально.

Вот пример правила, согласно которому администраторы определенного ресурса имеют полный доступ как в Hub, так и в QMC к соединениям данных для одного и того же ресурса:

Правило безопасности

Qlik Sense DataConnections_* – это фильтр ресурсов, который определяет область доступа. Вы можете иметь несколько фильтров ресурсов, разделенных запятой, хотя при тестировании это не всегда работает так как надо, так что если сомневаетесь, удалите их.

ХВАТИТ ХРАНИТЬ ВЫРАЖЕНИЯ QLIK SENSE В ПЕРЕМЕННЫХ!

Как разработчики, мы должны уделять больше внимания модели данных Qlik Sense, чем при разработке в QlikView, поскольку мы ожидаем, что пользователь будет искать больше информации и идей.

Мы также ожидаем, что они будут создавать собственные визуализации на лету, и для этого им нужна понятная модель данных, и с учетом этого нам нужно подумать о том, как мы предоставляем нашим пользователям Измерения, Меры и Визуализации в основных элементах.

В QlikView перед выпуском информационной панели принято помещать все выражения в переменные. На то есть ряд причин:

  • Управление метрикой – чтобы знать, что все экземпляры этого показателя будут согласованными, вам нужно всего лишь отредактировать переменную один раз, поскольку все они ссылаются на одну и ту же переменную.
  • Иерархическое управление метрикой – для таких мер, как маржа, вместо того, чтобы писать полное выражение, вы ссылаетесь на переменные нижнего уровня для продаж и затрат. Как и прежде, вам нужно только один раз обновить ее, чтобы знать, что все экземпляры этой меры будут согласованы.
  • Производительностьмалоизвестный параметр. Если у вас есть два выражения “=sum(Sales)” & =”sum( Sales )” (обратите внимание на лишние пробелы во втором выражении!), То механизм анализирует их как два отдельных выражения и, следовательно, для вычисления берет вдвое большую вычислительную мощность. Если бы они были написаны одинаково, то рассчитывались бы один раз, независимо от того, сколько раз они используются.

Зная все эти преимущества, с какой стати мы должны прекратить использовать выражения?

А все из-за пользовательского опыта, если мы используем переменные, когда пользователь хочет отредактировать мастер-меру, у него не будет отличного исходного места для начала работы…

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

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

Теперь пользователь может точно видеть, что происходит, даже с добавлением Set Analysis. Большинство пользователей должны иметь возможность редактировать меру или, возможно, сделать еще шаг вперед, используя эту и другие меры в качестве отправной точки для чего-то нового, выбирая информацию из каждого и создавая новый расчет для самостоятельного обнаружения данных.

Как я собираюсь справиться со всей этой дополнительной работой!

Как мы будем управлять этим с точки зрения разработчика? Вот потенциальные проблемы:

  1. Быстрое заполнение и, что еще важнее, автоматическое обновление основных элементов с учетом изменений в расчетах.
  2. Сокращение дублирования, которое позволит мерам ссылаться на самих себя.

Во-первых, как и большинство разработчиков при работе с переменными, мы по-прежнему можем обрабатывать создание и обновление Мастер-элементов с помощью внешнего файла, такого как рабочая книга. Быстрый поиск «Master» в Qlik Branch Garden приводит к появлению ряда расширений, которые автоматизируют процесс (показано ниже). Это достигается за счет использования мощных API-интерфейсов Qlik.

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

Последнее, что вам нужно учитывать, это Иерархическое Метрическое Управление. Как-то во время разговора мне задали вопрос о Мастер-данных, которые ссылаются друг на друга. В настоящее время это невозможно, хотя я верю, что это вопрос времени. Несмотря на это, я не думаю, что данная мера необходима или вызывает проблему, так как мне пришлось решать аналогичную проблему много лет назад в QlikView!

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

Все еще не убедил?

Проблема также в том, как переменные хранятся, когда вы не удаляете их физически. Одним из стандартных предварительных тестов в QlikView было удаление всех переменных, запуск сценария (который должен воссоздать все необходимые переменные) и проверка того, что все в порядке. Часто я обнаруживал проблемы, когда старые переменные удалялись из сценария или контрольного листа, но не удалялись из приложения, и это становилось ошибкой в вычислениях или ставало причиной некорректной функциональности. Не используя API в QlikSense, вы должны вручную удалить все переменные (это может занять много времени). По этой самой причине я бы использовал переменные только там, где это абсолютно необходимо, поддерживая абсолютный минимум списка.

ФУНКЦИИ JOIN, CONCATENATE И APPLYMAP

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

Это отлично подходит для проверки данных и для первоначальной разработки пользовательского интерфейса информационной панели, хотя, вы, вероятно, захотите превратить эту структуру в схему «Звезда».

Qlik предлагает несколько способов соединения данных в таблице: Соединения (Join), Конкатенация (Concatenate) и функция ApplyMap – это те методы, о которых я собираюсь рассказать.

Join

Соединяя данные, вы берете два потока информации и соединяете их в одну строку данных, определенную Ключом, который определяется любым количеством полей с одинаковыми именами из обеих таблиц.

Если мы сосредоточимся на левом соединении (оно самое распространенное), то вторая загруженная таблица соединяется с первой. Любые совпадающие строки (как определено ключом) будут загружены из второй таблицы, а строки, которые не совпадают, не будут загружены.

Мы ясно увидим это, посмотрев на результаты левого соединения этих двух таблиц.

Table A

Left Join (Table A)

Результат
  • ID 4 не существует во второй таблице, поэтому поле B является нулевым значением
  • ID 5 не имеет соответствующей записи в первой таблице, поэтому оно не загружается

Это простой пример, и отсюда мы можем быстро начать объединять данные. Однако, есть еще кое-что, и это становится понятным не сразу. Если есть дублирование ключей, соединение проходит по-другому.

Table A

Left Join (Table A)

Результат

Здесь мы можем увидеть потенциальную проблему. Исходные данные таблицы A имеют значение FieldA – «20» для ID2. Теперь, поскольку во второй таблице было дублирование ID2, в выходных данных показаны две записи для ID2 и обе со значением FieldA, равным 20. Если бы вы просуммировали это в Qlik, то получили бы 40 – неверно!

Поэтому важно, чтобы вы понимали данные, которые вы связываете, и обеспечивали целостность конечного результата.

В Qlik есть четыре основных типа соединения:

  • Левое соединение (Left Join): все идентификаторы должны присутствовать в первой таблице.
  • Правое соединения (Right Join): все идентификаторы должны присутствовать во второй таблице.
  • Внутреннее соединение (Inner Join): связывает те данные, у которых идентификатор есть в обеих таблицах.
  • Внешнее соединение (Outer Join): хранит те данные из обеих таблиц, где их можно связать (так же, как соединение).

ApplyMap

Функция ApplyMap имеет явные преимущества, хотя при чрезмерном использовании может вызвать путаницу в скрипте информационной панели из-за того, что она ведет себя почти как подпрограмма (поэтому используйте ее осторожно).

  • Скорость (по сравнению с левым соединением)
  • Отсутствие обработки
  • Целостность данных

Ее часто используют в примерах Qlik, чтобы привести в порядок данные, например, различные варианты написания одного и того же слова. Кроме того, функция ApplyMap может использоваться для присоединения к одному полю.

Если мы возьмем первый пример Левого соединения и используем вместо него функцию Applymap, мы можем обработать нулевое значение, оставленное в выходной таблице.

Результат

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

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

Concatenate

Join и ApplyMap связывают данные в соответствующих строках (как определено ключом). Конкатенация складывает таблицы друг над другом разделяя поля, которые названы единообразно

Таблица конкатенации

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

Советы и стратегии по переходу на корпоративную реализацию Qlik

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

СОЗДАЙТЕ СВОЮ СТРАТЕГИЮ БИЗНЕС АНАЛИТИКИ

Представьте себе восхождение на гору. Прежде чем вы начнете подъем на более существенную высоту, где меньше кислорода и низкая температура, вы должны акклиматизироваться. Для этого альпинисты используют базовый лагерь. Мы тоже предлагаем нашим клиентам пройти через «базовый лагерь», чтобы создать минимальный уровень комфорта в использовании Qlik в компании. При переходе от внедрения в отделах к внедрению во всей компании у вас возникнут конкурирующие интересы, поскольку некоторые аспекты реализации выполняются быстрее, чем другие. Один отдел получит быстрый выигрыш, который создаст основу для будущего развития, а вот другой отдел вынужден будет ждать чего-то более сложного, например, информационной панели для руководителей, которая требует интеграции многих источников данных. «Базовый лагерь» предоставляет возможность оценить бизнес-причины использования Qlik, а также расставить приоритеты и учесть потребности и проекты каждого отдела.

Вот некоторые из элементов, которые мы хотели бы рассмотреть с нашими клиентами при разработке стратегии:

  • Задачи. Мы начинаем с того, что задаем вопросы типа «Почему? Чего пытается достичь ваш бизнес? Как мы собираемся использовать эти данные для улучшения нашего бизнеса?» Это помогает нам оценить приоритеты перед созданием решения. Мы всегда начинаем с заботы о клиентах.
  • Обзор решения. Мы гарантируем, что клиенты понимают возможности Qlik и то, как он может помочь их бизнесу.
  • Лучшие практики. Мы также обучаем лучшим практикам, таким как денормализация исходных таблиц и перемещение сложных вычислений из пользовательского интерфейса в скрипт загрузки, чтобы пользователи сразу начинали с надлежащих методов и не делали лишней работы.
  • Управление. Мы обсуждаем, как разработать такую структуру управления, которая позволит вам включить аналитику самообслуживания, а также обеспечить контроль, надежность и безопасность данных.
  • Архитектура данных. Мы обсуждаем следующие вещи: где вы будете хранить свои данные, как они организованы и интегрированы, у кого будет доступ, как обеспечить безопасность и ряд других.
  • Расширения. Вы можете реализовать Qlik как готовое решение, но расширения позволяют вам использовать его и такими способами, которых нет в стандартной реализации. Общие расширения включают QlikMaps, расширенные объекты КПЭ и те, которые записывают пользовательские данные обратно в базу данных из пользовательского интерфейса Qlik.
  • Обучение. Мы обсудим план обучения для всех ваших пользователей Qlik. Обучение повышает производительность, снижает затраты на обслуживание, увеличивает скорость внедрения и учит пользователей, как максимально использовать возможности Qlik. Кроме того, чем больше вы знаете, тем меньше вы должны полагаться на консультанта.

Чтобы облегчить принятие инструмента, в который вы инвестируете, нужно начинать с построения стратегии. Рассматривая эти аспекты реализации заранее, вы получите общее видение того, что Qlik предложит вам и для чего будет использоваться.

СОЗДАТЬ МАТРИЦУ ПРИОРИТИЗАЦИИ БИЗНЕС АНАЛИТИКИ

При реализации решений для обработки данных и аналитики вы захотите согласовать цели Бизнес аналитики (БА) с вашими корпоративными целями. Например, общая цель БА – создать такое решение для данных, которое является «единственным источником правды», чтобы все лица, принимающие решения в компании, смотрели на непротиворечивые и точные данные. Увеличение продаж на 10% может быть корпоративной целью. Один из способов достичь обеих целей – повысить возможности продаж, чтобы лица, принимающие решения во всей компании, могли анализировать эффективность продаж.

После того, как вы согласовали цели БА со своими корпоративными целями и создали список желаемого поведения своего решения, вы оцениваете эти проекты с двух точек зрения:

  1. Как такое поведение повлияет на бизнес? Этого влияния будет достаточно?
  2. Какова целесообразность такого решения? Сколько времени и ресурсов уйдет на эту функциональность?

Вместе с нашими клиентами мы часто используем инструмент под названием BI Prioritization Matrix (Матрица приоритетов БА), который помогает им составлять и расставлять приоритеты ключевых инициатив БА для определения технической осуществимости и реальной стоимости для бизнеса каждого элемента и того, как они соотносятся с общими корпоративными целями.

Матрица приоритетов БА помогает вам составить дорожную карту для своих приоритетов и распознавать вещи, которые вы можете легко реализовать.

ОПРЕДЕЛЕНИЕ ЦЕНТРАЛИЗОВАННЫХ МЕТРИК

Как только у вас будет готов план, вы захотите внедрить платформу БА таким образом, чтобы ее можно было масштабировать, и она была пригодна для корпоративного использования. Одна из типичных проблем при работе с Qlik – определение централизованной библиотеки для основных элементов, которую могут использовать несколько приложений. Один из методов, который помогает в этом – Governed Metrics Service, расширение серверной среды Qlik Sense. Она позволяет вам определять свои метрики извне, загружать их в Qlik Sense и применять их к любым/всем выбранным вами приложениям. Это обеспечивает согласованность (помните «Единый источник правды?») И сокращает время на администрирование, поскольку вам не нужно дублировать сложные основные элементы в приложениях.

Внешние показатели хранятся в архитектуре этого продукта (электронная таблица Excel, таблица базы данных и т. д.); на этом построен QVD; на сервере установлен инструмент управления управляемыми метриками, и это тот интерфейс, который вы используете для применения библиотеки метрик в приложениях.

Governed Metrics Service (Служба управляемых метрик)

ЗАБЛАГОВРЕМЕННО ПРОВЕРЬТЕ МАСШТАБИРУЕМОСТЬ ВАШЕЙ СИСТЕМЫ

Если вы запустите систему, она будет вынуждена справляться с нагрузкой; но сможет ли ваше оборудование справиться с этим? Вы должны протестировать масштабируемость на ранних этапах процесса, чтобы устранить неопределенность относительно большего объема памяти или быстрых процессоров. The Scalability Toolkit поможет вам выполнить регрессионное тестирование с помощью автоматических тестов. Инструментарий позволяет настроить гипотетический сценарий типичного и нетипичного использования приложения, а затем выполнить сценарий, чтобы получить метрики и выходные данные для анализа. Например, вы можете оценить, как возросшее количество пользователей повлияет на использование ОЗУ и время отклика. Важно протестировать производительность, выявить слабые места и внести соответствующие изменения, прежде чем пользователи начнут взаимодействовать с системой.

АДМИНИСТРИРОВАНИЕ QLIK УТИЛИТАМИ QMC

Qlik Sense поставляется вместе с консолью управления Qlik, которая работает хорошо, но есть возможность расширить функциональность с помощью утилит QMC, проекта с открытым исходным кодом, который помогает в администрировании Qlik. Вот несколько примеров функций QMC, которые упрощают этот процесс:

  • App Mover: без этого инструмента вы будете делать несколько шагов: экспорт приложения, создание имени, сохранение и импорт, предоставление соответствующих разрешений и многое другое. App Mover упрощает этот процесс, перемещая приложение и всю связанную информацию из одной среды в другую.
  • Object Approver: при ручном перемещении в другую среду объекты можно пропустить. Этот инструмент упрощает утверждение и перемещение всех объектов.
  • Security Rules Manager: воссоздание правил в разных средах утомительно и может привести к ошибкам. Этот инструмент позволяет легко экспортировать и импортировать правила между средами.
  • Custom Property Bulk Loader позволяет вам вносить групповые изменения в различные компоненты вашей реализации Qlik вместо одного объекта за раз.

АВТОМАТИЧЕСКИЙ КОНТРОЛЬ ВЕРСИИ С IN4BI

In4BI доступен для Qlik Sense и QlikView. Это инструмент, который позволяет разработчикам работать с одним и тем же документом параллельно с формализованным процессом проверки и некоторыми дополнительными функциями управления. Администраторы выступают в качестве диспетчеров и контролируют продвижение приложений между средами, обеспечивая соответствие требованиям и контрольным спискам. Кроме того, номера версий присваиваются автоматически, чтобы избежать путаницы среди разработчиков.

РАССМОТРИТЕ ВОЗМОЖНОСТЬ ИСПОЛЬЗОВАНИЯ QLIK В ОБЛАКЕ

Весьма вероятно, что часть вашей рабочей системы уже находится в облаке, например, один из ваших компонентов Qlik или другие данные исходной системы (например, данные CRM на Salesforce.com), которые вы загружаете в свою систему. Запуск Qlik в облаке должен стать серьезным фактором при переходе от решения для отдельных отделов к решению для всей компании. Размещение компонентов на сервере Qlik в облаке дает вам ряд преимуществ:

  • Упрощенное масштабирование или оптимизация: добавьте больше вычислительных ресурсов, таких как RAM, CPU и IO, без необходимости дополнительных затрат времени и усилий на установку, связанных с физическими серверами. Вместо этого вы просто добавляете пространство, отметив соответствующий флажок, в результате вы получите мгновенные преимущества. Также есть возможность автоматически запускать и останавливать экземпляры в зависимости от ваших задач с помощью недорогих инструментов для самостоятельной работы.
  • Устойчивость и защита от сбоев. В облаке у вас есть кластеры серверов в различных центрах обработки данных. Так, например, если один центр обработки данных выходит из строя, остальные будут все еще активны. Крайне маловероятно, что два или более центра обработки данных, поддерживающих облачную среду, выйдут из строя одновременно.

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

Безопасность Qlik Sense

Одно из основных отличий Qlik Sense и QlikView – это подход к обеспечению безопасности доступа пользователей к ресурсам и данным.

Доступ к ресурсу (потокам, приложениям, объектам приложений, соединениям для передачи данных) требует наличия правил безопасности.

Проще говоря, правило безопасности позволяет пользователю выполнять действие с ресурсом при условии, что условие правила выполняется.

Пользователь не имеет доступа к каким-либо ресурсам, если только правило безопасности не дает ему доступ к ресурсу для выполнения этого действия.

Иерархии

Правило безопасности Qlik Sense включает поток, который содержит различные приложения. Листы и диаграммы – это объекты в приложении.

В правило безопасности входят четыре отдельных элемента: фильтр ресурсов, условие, операторы и действия.

Фильтром ресурсов может быть либо App*, либо App_*. Есть небольшая, но весьма существенная разница в использовании «*» или «_*».

«App*» означает приложения и объекты в иерархии.

«App_*» означает только на уровне приложения или типа ресурса приложения.

Пользовательские свойства

Пользовательские свойства позволяют назначать собственные значения пользователям и ресурсам.

После того, как значения созданы и назначены, вы можете создать условие правила, используя символ «@» для пользовательских свойств.

Пример: если вы создаете настраиваемое свойство «AppADGroup» и добавляете финансовое значение, то можете создать условие правила, чтобы разрешить членам финансовой группы AD доступ к приложению.

user.group = resource.@AppADGroup

Вы можете не только использовать атрибуты из активного каталога, LDAP, но также пользовательские свойства для сравнения назначенных атрибутов пользователя с атрибутами, назначенными ресурсам для предоставления или запрета доступа.

Если правила перекрываются

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

Поэтому чтобы обеспечить надлежащий доступ, всегда рекомендуется проверять правила безопасности.

Сокращение объема данных

И QlikView, и Qlik Sense используют Section Access (Доступ к разделу) для динамического сокращения данных.

Section Access может выполнять сокращение данных на уровне строк и столбцов для пользователя или группы.

Section Access в  QlikView и Qlik Sense

Вы можете использовать скрипт Section Access QlikView в приложении Qlik Sense. Однако из-за имеющихся различий в работе Section Access в QlikView и Qlik Sense вам, возможно, придется настроить скрипт, чтобы он работал как следует.

QlikView против Qlik Sense

ABC-классификация

Шаблон ABC-классификации – это усовершенствованный шаблон статической сегментации, также известный как анализ Парето, поскольку он основан на принципе Парето. Результирующий ABC класс вычисляется во время процесса, поэтому он является статическим и использует вычисленные столбцы для хранения результата классификации. Вы можете использовать этот шаблон для оценки основных бизнес-параметров компании, как правило, с точки зрения лучших продуктов или лучших клиентов.

Пример базового шаблона

Предположим, вы хотите оценить важность того, или иного продукта для дохода вашей компании с помощью ABC-анализа. Вы должны отнести каждый продукт к определенному классу (A, B или C), для которого верно следующее:

  • Продукты класса А составляют 70% доходов.
  • Продукты класса B обеспечивают 20% доходов.
  • Продукты класса C составляют оставшиеся 10% доходов.

В таблице Products («Продукты») создается вычисляемый столбец, который содержит класс ABC, используемый в качестве атрибута группировки в отчетах. Таблица Products («Продукты») связана с таблицей Sales («Продажи»).

Рисунок 1. Таблица Products («Продукты») связана с таблицей Sales («Продажи»)

Чтобы реализовать ABC-классификацию, необходимо создать еще несколько вычисляемых столбцов в таблице Products («Продукты»). Все эти столбцы, кроме ABC Class («АВС-класс»), будут скрыты от клиентских инструментов:

  • ProductSales: общая сумма продаж для продукта (текущая строка).
  • CumulatedSales: общая сумма продаж для всех продуктов одного класса (текущая строка).
  • CumulatedPercentage: значение RunningTotalSales, выраженное в процентах от общей суммы продаж.
  • ABC Class: класс продукта, который может быть A, B или C.

Вы определяете вычисляемые столбцы, используя следующие формулы DAX:

  
 [ProductSales] =
 CALCULATE ( SUM ( Sales[SalesAmount] ) )
  
 [CumulatedSales] = 
 CALCULATE (
     SUM ( Products[ProductSales] ),
     ALL ( Products ),
     Products[ProductSales] >= EARLIER ( Products[ProductSales] )
 )
  
 [CumulatedPercentage] =
 Products[CumulatedSales] / SUM ( Products[ProductSales] )
  
 [ABC Class] =
 SWITCH (
     TRUE (),
     Products[CumulatedPercentage] <= 0.7, "A",
     Products[CumulatedPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 2. В вычисляемых столбцах таблицы Products («Продукты») реализована ABC-классификация

Вы можете использовать новый столбец ABC Class («АВС класс») в качестве фильтра в сводных таблицах, как показано на рисунках 3 и 4.

Рисунок 3. У каждой модели продукта могут быть продажи в классах A, B и C


Рисунок 4. Слайсер фильтрует только продукты класса А

ABC-классификация используется для создания статической сегментации объектов в модели данных. Если у сущности, которую вы хотите классифицировать, нет детализации в таблице, вы должны использовать слегка отличающиеся формулы, как описано в разделе «Полный шаблон».

Примеры использования

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

Управление запасами

Вы можете использовать ABC-классификацию в качестве метода категоризации запасов, чтобы лучше управлять запасами и снизить затраты на инвентаризацию. Элементы в классе A являются самыми важными для бизнеса, и вам следует чаще анализировать их стоимость, тогда как элементы в классе C менее важны, а элементы в классе B находятся в промежуточном состоянии. Например, вы можете увеличить доступность товара и договориться о более выгодных ценах на товары класса A, сократив время и ресурсы, затрачиваемые на товары в классах B и C.

Мера, используемая в качестве цели для ABC-классификации в управлении запасами, может включать несколько критериев, которые учитывают объем (продаж), прибыльность (маржинальная прибыль от инвестиций в запасы) и скорость (количество заказов на товар).

Сегментация покупателей

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

Маркетинговая сегментация

Вы можете использовать ABC классификацию для сегментации продуктов для распределения маркетингового бюджета, который используется для продвижения и стимулирования продаж продуктов. Меры, которые используют в качестве цели для классификации – это обычно доход и маржа, в то время как рассматриваемой единицей может быть номер SKU продукта или группа признаков (например, категория, модель, цвет и т.д.).

Полный шаблон

Вы рассчитываете ABC-классификацию для объекта с помощью следующего шаблона, используя эти маркеры:

  • <granularity_table> – это таблица, которая определяет уровень подразделения сущностей, которые вы хотите классифицировать. Например, это может быть таблица Products («Продукты»), если вы хотите классифицировать продукты.
  • <granularity_attribute> – это атрибут, который вы хотите использовать в качестве цели классификации (то, что объединяет сущности в меньшее количество элементов). Например, это может быть Products[ProductModel], столбец Product Model («Модель продукта») таблицы Products («Продукты»).
  • <measure> – это значение, которое нужно вычислить для каждого объекта <granularity_table> для ABC классификации.
 [EntityMeasure] =
 CALCULATE ( <measure> )
  
 [CumulatedPercentage] =
 CALCULATE (
     <measure>,
     ALL ( <granularity_table> ),
     <granularity_table>[EntityMeasure]
         >= EARLIER ( <granularity_table>[EntityMeasure] )
 )
     / CALCULATE ( <measure>, ALL ( <granularity_table> ) )
  
 [ABC Class] =
 SWITCH (
     TRUE (),
     <granularity_table>[CumulatedPercentage] <= 0.7, "A",
     <granularity_table>[CumulatedPercentage] <= 0.9, "B",
     "C"
 ) 

Например, вы можете внедрить вычисляемый столбец ABC Product («АВС Продукт») в модели с таблицами Products («Продукты») и Sales («Продажи») следующим образом:

 [ProductSales] =
 CALCULATE ( [Sales Amount] )
  
 [ProductPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ProductSales] >= EARLIER ( Products[ProductSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Products ) )
  
 [ABC Product] =
 SWITCH (
     TRUE (),
     Products[ProductPercentage] <= 0.7, "A",
     Products[ProductPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 5. ABC-столбец Product («Продукт») оценивает каждую строку в таблице Products («Продукты»)

Если вы хотите рассчитать ABC-классификацию для атрибута сущности, следует использовать немного другой шаблон только для вычисляемого столбца EntityMeasure («Мера сущности»):

 [EntityMeasure] =
 CALCULATE (
     <measure>,
     ALL ( <granularity_table> ),
     <granularity_table>[<granularity_attribute>] 
         = EARLIER( <granularity_table>[<granularity_attribute>] )
 ) 

Например, вы внедряете вычисляемый столбец ABC Model (АВС Модель») в той же модели с таблицами Products («Продукты») и Sales («Продажи») следующим образом:

 [ModelSales] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ProductModel] = EARLIER ( Products[ProductModel] )
 )
  
 [ModelPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ModelSales] >= EARLIER ( Products[ModelSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Products ) )
  
 [ABC Model] =
 SWITCH (
     TRUE (),
     Products[ModelPercentage] <= 0.7, "A",
     Products[ModelPercentage] <= 0.9, "B",
     "C"
 ) 

Все продукты, которые принадлежат к одной и той же модели, имеют одинаковую классификацию ABC Model (АВС Модель»).

Рисунок 6. Столбец ABC Model («АВС Модель») рассчитывает одинаковое значение для всех продуктов одной модели.

Чтобы использовать ABC-классификацию для одной денормализованной таблицы, необходимо немного изменить определение EntityMeasure следующим образом:

 [EntityMeasure] =
 CALCULATE (
     <measure>,
     ALLEXCEPT ( <granularity_table>, <granularity_table>[<granularity_attribute>] )
 ) 

Например, вы могли бы реализовать вычисляемые столбцы ABC Product («АВС Продукт») и ABC Model («АВС Модель») в модели с одной денормализованной таблицей продаж следующим образом:

 [ProductSales] =
 CALCULATE (
     [Sales Amount],
     ALLEXCEPT ( Sales, Sales[Product] )
 )
  
 [ProductPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Sales ),
     Sales[ProductSales]
         >= EARLIER ( Sales[ProductSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Sales ) )
  
 [ABC Product] =
 SWITCH (
     TRUE,
     Sales[ProductPercentage] <= 0.7, "A",
     Sales[ProductPercentage] <= 0.9, "B",
     "C"
 )
  
 [ModelSales] =
 CALCULATE (
     [Sales Amount],
     ALLEXCEPT ( Sales, Sales[Model] )
 )
  
 [ModelPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Sales ),
     Sales[ModelSales]
         >= EARLIER ( Sales[ModelSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Sales ) )
  
 [ABC Model] =
 SWITCH (
     TRUE (),
     Products[ModelPercentage] <= 0.7, "A",
     Products[ModelPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 7. Столбец ABC Product («АВС Продукт»), реализованный в единой денормализованной таблице.

Рисунок 8. Столбец ABC Model («АВС Модель»), реализованный в единой денормализованной таблице.

3 совета по ускорению отчетов в Power BI

Хотите, чтобы ваши информационные панели Power BI работали быстрее? Следуйте этим рекомендациям.

Лучшие практики использования отношений Fact/Dim в табличных моделях основаны на дизайне Kimball DW. Этот дизайн интегрирован в вычислительный механизм VertiPaq таким образом, чтобы максимизировать производительность по большим наборам данных и многим измерениям, и может использоваться как бизнес-пользователями, так и продвинутыми техническими ресурсами.

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

СОВЕТ №1 ХРАНИТЕ ДАННЫЕ В ЦЕЛОЧИСЛЕННЫХ ЗНАЧЕНИЯХ

Движок VertiPaq построен под целые числа и оптимизирован под них. Из этого следует ряд правил по созданию моделей с максимальным быстродействием и максимальной эффективностью:

  • Таблицы фактов должны содержать только целочисленные значения.
  • Все объединения должны базироваться на целочисленных значениях.
  • Даты объединяются в виде целых чисел в формате ГГГГММДД, они хорошо оптимизированы и настроены для проведения очень сложной и комплексной аналитики временных рядов.
  • Размеры строковых значений (даже в измерениях) должны быть максимально уменьшены – 255 – хорошо, 127 – лучше, 31-63 – еще лучше.

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

СОВЕТ №2 РАЗМЕРНЫЕ СВЯЗИ

Лучшая производительность будет зависеть от того, как измерения распределяются в памяти, а вычисления хранятся в кэше на основе объединений, и при оптимизации этого кэша и можно получить самую высокую производительность. Кэш использует понятия HOT и COLD для оптимизации хранения данных – данные HOT получают самый быстрый ответ, а для данных COLD требуется немного больше времени. Чтобы максимизировать то, что может остаться в HOT-кэше, мы следуем следующим рекомендациям:

  • Объединения целочисленных значений.
  • Минимизация мощности измерений.
  • Самая высокая производительность достигается при сохранении мощности DIM ниже 127k (выше этого значения производительности начнет ухудшаться).
  • Перемещение атрибутов 2 типа в таблицы фактов и разделение их по измерениям.

СОВЕТ №3 ИЗМЕРЕНИЕ ДАТЫ

Измерение даты в механизме VertiPaq было специально настроено для аналитики на основе времени, так чтобы не существовало другого механизма, который предлагает такой же уровень динамического анализа на основе времени как для бизнес-пользователей, так и для исследователей данных. Если вы не знакомы с тем, что табличная модель может делать с аналитикой, основанной на времени, я настоятельно рекомендую ознакомиться со статьями Марко Руссо, посвященными анализу времени.

  • Измерение даты на основе целочисленного объединения Datekey для ГГГГММДД.
  • Динамические вычисления и расчеты по DateDim, а также особенности и функции в измерении.
  • Стандартный DateDim значительно упрощает включение этих функций.

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

Архитектура Power BI – описание 7 компонентов с пояснениями принципа работы

Чтобы полностью изучить технологию, вы должны хорошо понимать ее архитектуру. Если вы не знаете архитектуру технологии, то не сможете ею управлять. В этой учебной статье по архитектуре Power BI мы собираемся начать с самых азов, а затем постепенно продвинемся вверх, узнаем о компонентах Power BI и о том, как они работают. Мы также разберем принцип работы фронтенд и бэкенд Power BI, которые обеспечивают все его уникальные функции и возможности для анализа данных.

Давайте начнем и постараемся сформировать полное понимание концепции.

Архитектура Power BI

Power BI – это бизнес-пакет, включающий несколько технологий, которые работают вместе. Чтобы обеспечить первоклассные решения для бизнес-аналитики, технология Microsoft Power BI состоит из группы компонентов, таких как:

  • Power Query (для объединения и преобразования данных)
  • Power BI Desktop (инструмент для разработки сопутствующих услуг)
  • Power BI Mobile (для телефонов Android, iOS, Windows)
  • Power Pivot (для моделирования табличных данных в памяти)
  • Power View (для просмотра визуализаций данных)
  • Power Map (для визуализации трехмерных геопространственных данных)
  • Power Q&A (для вопросов и ответов с использованием естественного языка)

Проще говоря, пользователь Power BI получает данные из различных источников данных, таких как файлы, Azure, онлайн-сервисы, DirectQuery или со шлюзов. Затем он работает с этими данными в клиентском инструменте разработки, таком как Power BI Desktop. Здесь импортированные данные очищаются и преобразуются в соответствии с требованиями пользователя.

Как только данные будут преобразованы и отформатированы, они готовы для использования при создании визуализаций в отчете. Отчет – это набор визуализаций, таких как графики, диаграммы, таблицы, фильтры и слайсеры.

Двигаясь по цепочке процессов, вы можете публиковать отчеты, созданные в Power BI Desktop, на двух видах платформ: Power BI Service и Power BI Report Server.

Power BI Service – это общедоступная облачная платформа, а Power BI Report Server – это локальная платформа, защищенная брандмауэром.

На этих платформах вы можете создавать информационные панели, прикрепляя визуализации к опубликованным отчетам. Кроме того, вы можете делиться своими панелями и отчетами и сотрудничать с другими пользователями из вашей организации или за ее пределами, используя такие инструменты взаимодействия, как веб-браузер, Power BI на iPad, планшеты, ноутбуки, телефоны и т.д.

Компоненты архитектуры Power BI

Давайте подробнее узнаем о компонентах архитектуры Power BI.

1. Источники данных

Широкий спектр источников данных является важной характеристикой Power BI. Вы можете импортировать данные из файлов вашей системы, облачных сетевых источников данных или напрямую подключаться к действующим соединениям. При импорте данных из локальных или онлайн-сервисов есть ограничение объема в 1 ГБ. Вот некоторые из часто используемых источников данных в Power BI:

  • Excel
  • Text/CSV
  • XML
  • JSON
  • Oracle Database
  • IBM DB2 Database
  • MySQL Database
  • PostgreSQL Database
  • Sybase Database
  • Teradata Database
  • SAP HANA Database
  • SAP Business Warehouse server
  • Amazon Redshift
  • Impala
  • Google BigQuery (Бета-версия)
  • Azure SQL Database
  • Salesforce Reports
  • Google Analytics
  • Facebook
  • GitHub

2. Power BI Desktop

Power BI Desktop – это инструмент на стороне клиента, известный как вспомогательный инструмент разработки.

Это ПО для ПК с инструментами и функциями для подключения к источникам данных, преобразования данных, моделирования данных и создания отчетов.

Вы можете бесплатно загрузить и установить Power BI Desktop. Используя функции Power BI Desktop, можно выполнять очистку данных, создавать бизнес-метрики и модели данных, определять отношения между данными, определять иерархии, создавать визуальные эффекты и публиковать отчеты.

3. Power BI Service

Power BI Service – это веб-платформа, на которой вы можете обмениваться отчетами, созданными в Power BI Desktop, сотрудничать с другими пользователями и создавать информационные панели.

Он доступен в трех версиях:

  • Бесплатная версия
  • Pro версия
  • Премиум версия

Power BI Service также известен как «Power BI.com», «Power BI Workspace», «Сайт Power BI» и «Веб-портал Power BI». Этот компонент также предлагает расширенные функции, такие как вопросы и ответы на естественном языке и оповещения.

4. Power BI Report Server

Power BI Report Server похож на Power BI Service. Единственное различие между ними состоит в том, что Power BI Report Server является локальной платформой. Он используется организациями, которые не хотят публиковать свои отчеты в облаке и обеспокоены безопасностью своих данных.

Power BI Report Server позволяет создавать информационные панели и обмениваться отчетами с другими пользователями с соблюдением надлежащих протоколов безопасности. Чтобы воспользоваться этой услугой, вам нужна лицензия Power BI Premium.

5. Power BI Gateway

Этот компонент используется для подключения и доступа к локальным данным в защищенных сетях. Power BI Gateways обычно используются в организациях, где данные хранятся в безопасном режиме под наблюдением. Шлюзы помогают извлекать такие данные по защищенным каналам на платформы Power BI для анализа и составления отчетов.

6. Power BI Mobile

Power BI Mobile – это встроенное приложение Power BI, которое работает на мобильных устройствах iOS, Android и Windows. Приложение используется для просмотра отчетов и информационных панелей.

7. Power BI Embedded

Power BI Embedded предлагает API-интерфейсы, которые используются для встраивания визуальных элементов в пользовательские приложения.

Функционирование архитектуры Power BI

Теперь, когда мы поняли, как работают отдельные компоненты Power BI, давайте узнаем, как все эти компоненты функционируют в связке. Мы разберем архитектуру Power BI с помощью следующей диаграммы.

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

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

Локальные базы данных

Power BI Desktop – это сопутствующий инструмент разработки и публикации. Вы можете импортировать данные из источников данных в Power BI Desktop и использовать их для создания отчетов, а затем публиковать их в Power BI Service или Power BI Report Server.

Вы также можете публиковать книги Excel непосредственно с помощью Power BI Publisher для Excel на сервере отчетов Power BI. Инструменты SQL Server Data и Report Publisher помогают создавать наборы данных, КПЭ, мобильные отчеты, отчеты с разбивкой по страницам и т.д. Отчеты всех типов публикуются на сервере Power BI Report Server, откуда и передаются конечным пользователям.

Облачные базы данных

Важным компонентом в архитектуре Power BI является шлюз Power BI Gateway. Power BI Gateway действует как безопасный канал для передачи данных из локальных источников данных в облачные приложения или сайты.

На облачной стороне архитектуры находится множество компонентов. Полный пакет Power BI содержит потоки данных, наборы данных, информационные панели, отчеты, Power BI Embedded, Power BI Premium и т.д. Вы можете встраивать свои отчеты и информационные панели в Teams, SharePoint, пользовательские приложения и т.д. Они хорошо подсоединяются к инструментам Power BI через прямые подключения.

Наконец, есть аутентифицированные пользователи, которые делятся опубликованными отчетами и информационной панелью и сотрудничают друг с другом, чтобы принимать обоснованные решения на основе полученных данных. Есть различные типы пользователей, которые используют отчеты и информационные панели Power BI и подключаются через веб-браузеры, Excel, сторонние инструменты и мобильные устройства (iOS, Windows, приложения Android).

Power BI Service

Как мы узнали из предыдущих разделов, все отчеты, которые вы создаете в Power BI Desktop, публикуются на облачной платформе, известной как Power BI Service.

Пользователи могут получать доступ к отчетам и панелям из Power BI Service, используя клиентские платформы, такие как веб-сайты, мобильные устройства и т.д. Это означает, что каждый клиент, который хочет получить доступ к контенту, созданному в Power BI, должен взаимодействовать с Power BI Service. Поэтому нам стоит «заглянуть под капот» и узнать, как работает Power BI Service.

Архитектура Power BI Service состоит из двух частей:

  • фронтенд
  • бэкенд

Кластер фронтенд

Внешний интерфейс, также называемый интерфейсным веб-кластером, действует как посредник между клиентами и внутренним сервером. Внешние службы используются для установления начального соединения и проверки подлинности клиентов с помощью Azure Active Directory. Azure Active Directory хранит идентификационные данные пользователей.

Наряду с этим Azure Traffic Manager используется для направления пользовательских запросов в ближайший центр обработки данных после проверки подлинности. После проверки подлинности клиента/пользователя, Azure Content Delivery Network (CDN) распространяет статическое содержимое/файлы Power BI пользователям.

Кластер бэкенд

Сервисы Power BI на стороне сервера заботятся о визуализациях, наборах данных, хранилище, отчетах, подключениях к данным, обновлении данных и других взаимодействиях с Power BI. Для бэкенда веб-клиент имеет только две прямые точки взаимодействия – Azure API Management и Gateway Role. Эти два компонента отвечают за балансировку нагрузки, аутентификацию, авторизацию, маршрутизацию и т.д.

Работа Power BI Service

  • Power BI хранит свои данные в двух основных хранилищах: Аzure block storage и Azure SQL database. В блочном хранилище Azure содержатся наборы данных, загруженные пользователями, а все метаданные и системные данные хранятся в базе данных SQL Azure.
  • После того как Azure API Management аутентифицирует пользовательский запрос, он отправляет его в Gateway Role. Gateway Role обрабатывает запросы и направляет их к подходящим компонентам, таким как Presentation Role, Background Job Processing Role, Data Role и Data Movement Role.
  • Для примера, Presentation Role обрабатывает все связанные с визуализацией запросы, например, для информационных панелей и отчетов.
  • Для всех запросов, связанных с данными, Gateway Role отправляет запрос в Data Role или Data Movement Role.
  • Бэкенд Power BI Service использует Azure Service Bus для подключения локальных источников данных к облаку. Azure Service Bus получает все запросы на выборку данных из локального источника данных. Затем сервис обрабатывает заявку и выполняет запрос на локальном источнике данных для извлечения данных из него в облачную службу.
  • Azure Service Fabric управляет всеми микросервисами и компонентами, связанными с запуском Power BI.
  • Azure AD Cache помогает создавать отчеты в режиме реального времени, используя данные, хранящиеся в оперативной памяти системы Power BI.

Резюме

На этом мы завершаем наше краткое руководство по архитектуре Power BI. Здесь мы узнали обо всех важных компонентах архитектуры Power BI, увидели, как они работают совместно, а также узнали о функционировании Power BI Service и описали, как она работает.

Список задач для перехода в облако

Этот контрольный список задач от Cloud Analytics Migration поможет вам подготовиться к переносу ваших аналитических систем в облако.

В этом списке мы подробно излагаем следующие технические и нетехнические факторы, которые следует учитывать при определении вашей уникальной стратегии перехода в облако.

  • Определите свои бизнес-цели. Как облако вписывается в вашу бизнес-стратегию?
  • Определите свой бюджет – начальные инвестиции, одобрение OpEx/CapEx и другое.
  • Оцените свое текущее аналитическое решение – что уже находится в облаке, что находится у вас в локальном доступе и т. д.
  • Планирование облачной среды. Какие части будут в облаке?
  • Определите те отделы, которые затронет перенос – кто руководит работой, кто использует ее результат и т. д.
  • Проверьте ваши данные – количество, источники и типы данных.
  • Учтите безопасность и конфиденциальность – уникальные требования, стратегии резервного копирования и многое другое.
  • Планирование пути переноса – переходы в облако будут более успешны, если у вас есть план.


77 queries in 1,189 seconds