Сценарии использования Power BI: настраиваемая управляемая самостоятельная бизнес-аналитика

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется рабочей нагрузке Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

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

Примечание.

Этот настраиваемый сценарий самостоятельной бизнес-аналитики является вторым из сценариев самообслуживания бизнес-аналитики. Этот сценарий основывается на том, что можно сделать с помощью централизованной общей семантической модели (которая была представлена в сценарии управляемой бизнес-аналитики самообслуживания). Список всех сценариев можно найти в статье по сценариям использования Power BI.

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

Схема сценария

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

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

Совет

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

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

Элемент Description
Элемент 1. Создатель семантической модели A разрабатывает модель с помощью Power BI Desktop. Для семантической модели, предназначенной для повторного использования, обычно (но не требуется) для создателя, которая будет принадлежать централизованной команде, которая поддерживает пользователей через границы организации (например, ИТ, корпоративная бизнес-аналитика или Центр превосходства).
Элемент 2. Power BI Desktop подключается к данным из одного или нескольких источников данных.
Элемент 3. Разработка модели данных выполняется в Power BI Desktop. Дополнительные усилия по созданию хорошо разработанной и понятной модели, чтобы ее можно было использовать в качестве источника данных многими создателями отчетов самообслуживания. Создатели моделей могут использовать запросы DAX для разработки и изучения модели во время разработки.
Элемент 4. Когда модель будет готова, создатель модели A публикует свой файл Power BI Desktop (PBIX) или файл проекта Power BI (PBIP), содержащий только модель в служба Power BI.
Элемент 5. Семантическая модель публикуется в рабочей области, выделенной для хранения и защиты общих семантических моделей. Так как семантическая модель предназначена для повторного использования, она одобрена (сертифицирована или повышена по мере необходимости). Семантическая модель также помечена как обнаруживаемая для дальнейшего поощрения его повторного использования. Представление происхождения в служба Power BI можно использовать для отслеживания зависимостей, существующих между элементами Power BI.
Элемент 6. Обнаружение данных в концентраторе данных OneLake включено, так как семантическая модель помечена как обнаруживаемая. Возможность обнаружения позволяет видеть семантику модели в концентраторе данных OneLake другими создателями содержимого Power BI, которые ищут данные.
Элемент 7. Создатели содержимого используют концентратор данных OneLake в служба Power BI для поиска обнаруженных элементов данных, таких как семантические модели.
Элемент 8. Если создатели содержимого имеют разрешение, они могут запросить разрешение на сборку для элементов данных. Это запускает рабочий процесс для запроса разрешения на сборку от авторизованного утверждающего. После получения разрешения создатели содержимого могут повторно использовать элементы данных для создания новых решений.
Элемент 9. В Power BI Desktop создатель модели B создает динамическое подключение к исходной общей семантической модели, расположенной в служба Power BI. Поскольку намерение состоит в расширении и настройке исходной семантической модели, динамическое подключение преобразуется в модель DirectQuery. Это действие приводит к локальной модели в файле Power BI Desktop.
Элемент 10. Power BI Desktop подключается к данным из дополнительных источников данных. Цель состоит в том, чтобы расширить общую семантику модели, чтобы дополнительные аналитические требования соответствовали новой специализированной составной семантической модели.
Элемент 11. Связи создаются в Power BI Desktop между существующими таблицами (из общей семантической модели, также называемой удаленной моделью) и новыми таблицами, только что импортированными (хранящимися в локальной модели). Дополнительные вычисления и моделирование выполняются в Power BI Desktop для завершения разработки специализированной составной модели.
Элемент 12. После готовности создатель семантической модели B публикует PBIX-файл или PBIP-файл в служба Power BI.
Элемент 13. Новая специализированная составная семантическая модель публикуется в рабочей области, выделенной для хранения и защиты семантических моделей, принадлежащих и управляемых отделом.
Элемент 14. Специализированная семантическая модель остается подключенной к исходной общей семантической модели Power BI. Любые изменения исходной общей семантической модели будут влиять на подчиненные специализированные составные семантические модели, которые имеют зависимость от него.
Элемент 15. Другие создатели отчетов самообслуживания могут создавать новые отчеты, подключенные к специализированной составной семантической модели. Создатели отчетов могут использовать Power BI Desktop, Power BI построитель отчетов или Excel.
Элемент 16. Отчеты публикуются в рабочей области, выделенной для хранения и защиты отчетов и панелей мониторинга.
Элемент 17. Опубликованные отчеты остаются подключенными к специализированной семантической модели, хранящейся в другой рабочей области. Любые изменения в специализированной семантической модели влияют на все отчеты, подключенные к нему.
Элемент 18. Некоторым источникам данных может потребоваться локальный шлюз данных или шлюз виртуальной сети для обновления данных, например те, которые находятся в частной сети организации.
Элемент 19. Администраторы Структуры контролируют и отслеживают действия на портале Fabric.

Ключевые моменты

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

Общая семантическая модель

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

Примечание.

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

Расширение начальной общей семантической модели

Иногда создатели самообслуживания должны расширить существующую семантику модели, например дополнительные данные, относящиеся к своему отделу. В этом случае они могут использовать подключения DirectQuery к семантической модели Power BI. Эта функция обеспечивает идеальный баланс самообслуживания при использовании инвестиций в централизованно управляемые ресурсы данных. Схема сценария показывает подключение DirectQuery. Действие преобразования динамического подключения в подключение DirectQuery создает локальную модель, которая позволяет добавлять новые таблицы. Связи можно создавать между таблицами из исходной общей семантической модели (удаленной модели) и только что добавленных новых таблиц (локальная модель). Для настройки новой модели данных можно выполнить дополнительные вычисления и моделирование данных.

Совет

Этот сценарий выделяет повторное использованием общей семантической модели. Однако иногда возникают ситуации, когда моделиторы данных хотят ограничить создание нижней модели данных. В этом случае они могут включить свойство "Запретить подключения DirectQuery" в параметрах Power BI Desktop.

Подтверждение семантической модели

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

Совет

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

Обнаружение семантической модели

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

Примечание.

Если семантическая модель не настроена для обнаружения, найдите ее только пользователи Power BI с разрешением на сборку.

Запрос доступа к семантической модели

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

Публикация в отдельных рабочих областях

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

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

Анализ зависимостей и влияния

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

Установка шлюза

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

Примечание.

Для настраиваемых сценариев самообслуживания бизнес-аналитики централизованного шлюза данных в стандартном режиме настоятельно рекомендуется использовать шлюзы в личном режиме. В стандартном режиме шлюз данных поддерживает динамическое подключение и операции DirectQuery (помимо запланированных операций обновления данных).

Системный надзор

Журнал действий записывает действия пользователя, происходящие в служба Power BI. Администраторы Power BI могут использовать данные журнала действий, собранные для аудита, чтобы помочь им понять шаблоны использования и внедрение. Журнал действий также ценен для поддержки усилий по управлению, аудита безопасности и требований соответствия требованиям. С помощью настраиваемого сценария самообслуживания бизнес-аналитики особенно полезно отслеживать использование исходной общей семантической модели, а также зависимых семантических моделей.

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