Планирование реализации Power BI: планирование рабочей области на уровне рабочей области

  • Статья

Примечание.

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

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

  • Администраторы Структуры: администраторы, ответственные за надзор за Структурой в организации.
  • Центр превосходства, ИТ-отдела и группы бизнес-аналитики: команды, которые также отвечают за надзор за данными и бизнес-аналитикой и поддержкой пользователей самообслуживания во всей организации.
  • Создатели контента и владельцы: создатели самообслуживания, которые должны создавать, публиковать и управлять содержимым в рабочих областях.

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

Примечание.

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

Назначение рабочей области

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

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

  • Рабочая область конца финансового месяца:Рабочая область конца финансового месяца содержит отчеты о сверках и закрытии в конце месяца. Эта рабочая область считается неофициальной рабочей областью для поддержки совместных усилий. Приложение Power BI не требуется для просмотра содержимого, так как основное использование этой рабочей области — это совместная работа небольшой группы людей, которые тесно работают вместе. Большинство участников группы имеют разрешение на изменение содержимого в этой рабочей области.
  • Рабочая область финансовых отчетов:рабочая область "Финансовые отчеты" содержит завершенные отчеты уровня презентации. Эта рабочая область содержит содержимое, широко распределенное по всей организации для многих зрителей (включая руководителей) с помощью приложения Power BI. Рабочая область тесно управляется.

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

Намерение для совместной работы

Основная цель рабочей области на портале Fabric — упростить совместную работу нескольких пользователей. Существует множество способов совместной работы в рабочей области:

  • Разработка на основе команд: несколько пользователей могут совместно создавать, тестировать и публиковать содержимое. Один пользователь может работать над проектированием lakehouse. Другой пользователь может работать над проектированием семантической модели (ранее известной как набор данных), а другие пользователи могут сосредоточиться на создании отчетов.
  • Тестирование и проверка. Пользователям может потребоваться выполнить проверку данных для нового содержимого. Эксперты по темам из бизнес-подразделения могут потребоваться выполнить приемочное тестирование пользователей (UAT), или группе по качеству данных может потребоваться проверить точность семантической модели.
  • Усовершенствования: заинтересованные лица и потребители содержимого могут предложить улучшения содержимого по мере изменения обстоятельств.
  • Передача владения: другой человек или команда могут взять на себя ответственность за содержимое, созданное кем-то другим.

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

  • Бизнес-аналитика самостоятельного бизнес-аналитики: контент принадлежит и управляется создателями контента в бизнес-подразделении или отделе. В этом сценарии большая часть совместной работы в рабочей области возникает среди пользователей в этом бизнес-подразделении.
  • Управляемая самостоятельная бизнес-аналитика: данные принадлежат и управляются централизованной командой, а различные создатели контента из бизнес-подразделений несут ответственность за отчеты и панели мониторинга. В этом сценарии, скорее всего, потребуется несколько рабочих областей для безопасной совместной работы нескольких групп людей.
  • Корпоративная бизнес-аналитика: контент принадлежит централизованной команде, например ИТ, корпоративной бизнес-аналитике или Центру передовых знаний (COE). В этом сценарии усилия по совместной работе в рабочей области выполняются среди пользователей в централизованной команде.

Контрольный список . При рассмотрении намерений для совместной работы в рабочей области ключевые решения и действия включают:

  • Рассмотрите ожидания для совместной работы: определите, как требуется совместная работа с рабочей областью и кто участвует в одной команде или в пределах организации.
  • Учитывайте ожидания владения содержимым и управления ими. Подумайте о том, как различные подходы к управлению контентом (самостоятельное управление бизнесом, управляемые самообслуживания бизнес-аналитики и корпоративная БИЗНЕС) влияют на то, как вы разрабатываете и используете рабочие области.

Совет

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

Намерение просмотра содержимого

Вторичная цель рабочей области — распространять содержимое потребителям, которые должны просматривать содержимое. Для просмотра содержимого основной рабочей нагрузкой Fabric является Power BI.

Существует несколько различных способов подхода к распределению содержимого в служба Power BI:

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

Еще одной ключевой областью стратегии внедрения Fabric является доставка содержимого область. Способы поддержки распространения содержимого рабочей области будут отличаться в зависимости от область доставки содержимого:

  • Личная бизнес-аналитика: содержимое предназначено для использования создателем. Так как общий доступ к содержимому другим пользователям не является целью, личная бизнес-аналитика выполняется в личной рабочей области (описано в следующем разделе).
  • Team BI: содержимое предоставляется относительно небольшому количеству коллег, которые тесно работают вместе. В этом сценарии большинство рабочих областей являются неофициальными, совместными рабочими областями.
  • Отделальная бизнес-аналитика: содержимое распространяется для многих потребителей, которые принадлежат крупному отделу или подразделению. В этом сценарии рабочая область в первую очередь предназначена для совместной работы. В сценариях бизнес-аналитики отделов содержимое обычно просматривается в приложении Power BI (вместо непосредственного просмотра в рабочей области).
  • Корпоративная бизнес-аналитика. Содержимое предоставляется широко через границы организации к наибольшему количеству целевых потребителей. В этом сценарии рабочая область в первую очередь предназначена для совместной работы. В сценариях корпоративной бизнес-аналитики содержимое обычно просматривается в приложении Power BI (вместо непосредственного просмотра в рабочей области).

Совет

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

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

  • Рассмотрите ожидания просмотра содержимого. Определите, как потребители будут просматривать содержимое, опубликованное в рабочей области. Рассмотрите, произойдет ли просмотр непосредственно в рабочей области или с помощью другого метода.
  • Определите, кому будет доставлено содержимое: рассмотрите, кто является целевой аудиторией. Кроме того, рассмотрите режим лицензии рабочей области, особенно если ожидается значительное количество зрителей содержимого.
  • Оцените потребности приложения Power BI. Рассмотрим, что такое назначение рабочей области в соответствии с требованиями к распространению содержимого. Если требуется приложение Power BI, оно может повлиять на решение о создании рабочей области.
  • Учитывайте ожидания доставки содержимого область. Рассмотрим, как различные область доставки контента (личные бизнес-аналитики, командная бизнес-аналитика, отдел и корпоративная бизнес-аналитика) влияют на то, как вы разрабатываете и используете рабочие области.

Совет

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

Соответствующее использование личных рабочих областей

Существует два типа рабочих областей:

  • Личные рабочие области: у каждого пользователя есть личная рабочая область. Личную рабочую область можно использовать для публикации определенных типов содержимого на портале Fabric. Его основной целью является поддержка сценариев использования личных бизнес-аналитики .
  • Рабочие области: основная цель рабочей области — поддерживать совместную работу между несколькими пользователями. Во-вторых, рабочую область также можно использовать для просмотра содержимого.

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

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

Личная рабочая область ограничена своими параметрами для совместного использования содержимого с другими пользователями. Невозможно опубликовать приложение Power BI из личной рабочей области (и приложения Power BI являются важным механизмом распространения содержимого в организации). Разрешения для каждого элемента (ссылки или прямой доступ) являются единственным способом совместного использования содержимого личной рабочей области с другими пользователями. Таким образом, широкое использование разрешений для каждого элемента включает в себя больше усилий и повышает риск ошибки. Дополнительные сведения см. в разделе "Отчеты о планировании безопасности потребителей".

Контрольный список . При рассмотрении ваших ожиданий использования личных рабочих областей ключевые решения и действия включают:

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

Примечание.

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

Владение рабочей областью

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

Ясность в отношении владения особенно актуальна, когда обязанности по созданию и управлению данными децентрализованы (или распределены) между отделами и подразделениями. Эта концепция также иногда называется архитектурой сетки данных. Дополнительные сведения о сетке данных см. в разделе "Что такое сетка данных?".

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

Совет

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

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

Совет

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

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

  • Получите полное представление о том, как работает владение контентом: убедитесь, что вы глубоко понимаете, как происходит владение контентом и управление ими во всей организации. Убедитесь, что, скорее всего, не будет единообразно применяться ко всей организации. Понимание потребностей децентрализованного или распределенного владения.
  • Определите и задокументируйте роли и обязанности. Убедитесь, что вы определяете и документируете четкие роли и обязанности для пользователей, работающих в рабочих областях. Сделайте эту информацию доступной в мероприятиях по подключению, учебных материалах и централизованном портале.
  • Создайте матрицу ответственности: сопоставьте, кто должен обрабатывать каждую функцию при создании, обслуживании, публикации, защите и поддержке содержимого. Убедитесь, что эта информация готова при планировании ролей доступа к рабочей области.
  • Рассмотрим сценарии совместного владения или владения несколькими командами: определите, когда существует сценарий, в котором было бы полезно разделить рабочие области, чтобы обеспечить четкость обязанностей.
  • Создание документации по управлению рабочими областями. Обучить администраторов рабочей области и участников о том, как управлять параметрами рабочей области и доступом. Включите обязанности для администраторов рабочих областей, членов и участник. Сделайте информацию доступной на централизованном портале и учебных материалах.

Организация рабочей области

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

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

Тема рабочей области и область

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

В некоторых случаях у вас уже могут быть некоторые полезные группы , установленные в идентификаторе Microsoft Entra (ранее известном как Azure Active Directory). Затем их можно использовать для управления доступом к ресурсам для определенной области темы и область. Однако для этого может потребоваться создать несколько новых групп. Дополнительные сведения см. в разделе доступа к рабочей области ниже.

Вариант 1. Рабочая область для каждой темы или проекта

Создание рабочей области для каждой темы или проекта позволяет сосредоточиться на своей цели. Это позволяет использовать сбалансированный подход.

Примеры: ежеквартальный анализ финансовых средств или анализа запуска продуктов

Ниже перечислены преимущества варианта 1.

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

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

Совет

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

Вариант 2. Рабочая область на отдел или команду

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

Примеры: Отдел финансов или Аналитика отдела продаж

Ниже перечислены преимущества варианта 2.

  • Начало работы с планированием является простым. Все содержимое, необходимое пользователям, работающим в этом отделе, будет находиться в одной рабочей области.
  • Пользователи легко знают, какую рабочую область следует использовать, так как все их содержимое публикуется в рабочей области, связанной с отделом или командой.
  • Управление ролями безопасности может быть простым, особенно если группы Microsoft Entra назначены ролям рабочей области (это рекомендуется).

К недостаткам варианта 2 относятся следующие:

  • Результат часто представляет собой широкую область рабочую область, содержащую множество элементов. Широко определенная рабочая область область может затруднить поиск определенных элементов пользователями.
  • Так как между рабочей областью и приложением Power BI существует связь "один к одному", широко определенная рабочая область может привести к приложениям, содержащим большое количество содержимого. Эта проблема может быть устранена путем исключения определенных элементов рабочей области из приложения и с хорошей структурой навигации приложения.
  • Когда пользователям из других отделов необходимо просмотреть определенные элементы рабочей области, управление разрешениями может стать более сложным. Существует риск того, что люди будут предполагать, что все в отделе рабочей области только для их глаз. Существует также риск того, что совместное использование отдельных элементов будет чрезмерно использовано для выполнения подробных разрешений на просмотр.
  • Если некоторым создателям содержимого требуется разрешение на изменение некоторых элементов (но не всех элементов), невозможно задать эти разрешения в одной рабочей области. Это связано с тем, что роли рабочей области, определяющие разрешения на изменение или просмотр, определяются на уровне рабочей области.
  • При наличии большого количества элементов рабочей области часто требуется использовать строгие соглашения об именовании для элементов, чтобы пользователи могли найти нужные элементы.
  • Широкие рабочие области с множеством элементов могут столкнуться с техническим ограничением количества элементов, которые могут храниться в рабочей области.

Совет

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

Вариант 3. Рабочая область для определенного отчета или приложения

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

Примеры: сводка по ежедневным продажам или исполнительные бонусы

Преимущества варианта 3:

  • Цель узко определенной рабочей области понятна.
  • Ультрачувствительное содержимое может и часто быть разделено на свою собственную рабочую область, чтобы управлять ими явно.
  • Более точные разрешения рабочей области применимы к нескольким элементам. Эта настройка полезна, если, например, пользователь может редактировать один отчет, но не другой.

Недостатки варианта 3:

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

Совет

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

Контрольный список. При рассмотрении темы и область содержимого рабочей области ключевые решения и действия включают:

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

Типы элементов рабочей области

Разделение рабочих областей данных из рабочих областей отчетов — это распространенная практика разъединения ресурсов данных из аналитических ресурсов.

  • Рабочая область данных предназначена для хранения и защиты элементов данных, таких как lakehouse, хранилище, конвейер данных, поток данных или семантическая модель.
  • Рабочая область отчетов сосредоточена больше на подчиненных аналитических действиях. Он предназначен для хранения и защиты таких элементов, как отчеты, панели мониторинга и метрики. Рабочие области отчетов в основном (но не обязательно исключительно) включают содержимое Power BI.

Совет

Каждый интерфейс Fabric позволяет создавать различные типы элементов. Эти элементы не всегда точно соответствуют концепции того, что считается данными и аналитическим контентом. Одним из примеров является записная книжка Fabric, которую можно использовать различными способами, например загрузку и преобразование данных в lakehouse, отправку запросов Spark SQL или анализ и визуализацию данных с помощью PySpark. Если рабочая область будет содержать смешанные рабочие нагрузки, рекомендуется сосредоточиться в первую очередь на назначении рабочей области и собственности на содержимое, как описано в этой статье.

Ниже перечислены преимущества разделения рабочих областей данных из рабочих областей отчетов:

  • Критически важные организационные данные, такие как одобренная модель lakehouse или семантическая модель, могут находиться в определенной рабочей области, предназначенной для повторного использования данных, доступных в масштабе предприятия. Ниже приведены распространенные примеры:
  • Управление доступом может быть централизованно для критически важных данных организации. Управление доступом отдельно для рабочей области данных по сравнению с рабочими областями отчетов полезно, если разные люди отвечают за данные и отчеты. При использовании управляемой самостоятельной бизнес-аналитики многие создатели отчетов и меньше создателей данных.
  • Ограничение того, кто может изменять семантические модели и управлять ими, сводит к минимуму риск непреднамеренных изменений, особенно критически важных элементов данных, которые повторно используются для многих целей или многих пользователей. Физическое разделение снижает вероятность непреднамеренного или неопровержденного изменения. Этот дополнительный уровень защиты полезен для сертифицированных семантических моделей, которые зависят от их качества и надежности.
  • Уточняются сценарии совместного владения. При доставке общих семантических моделей из централизованной бизнес-аналитики или ИТ-группы, а отчеты публикуются создателями контента самообслуживания (в бизнес-подразделениях), рекомендуется разделить семантические модели в отдельную рабочую область. Такой подход позволяет избежать неоднозначности сценариев совместного владения, так как ответственность и ответственность за рабочую область более четко определены.
  • Безопасность на уровне строк (RLS) применяется. При поощрении создателей работать в разных рабочих областях они не будут иметь ненужных разрешений на редактирование исходной семантической модели. Преимущество заключается в том, что безопасность на уровне объектов (OLS) будет применяться для создателей содержимого (а также для зрителей содержимого).

Недостатки для разделения рабочих областей данных из рабочих областей отчетов:

  • Соглашение об именовании рабочей области требуется для того, чтобы отличать рабочую область данных от рабочей области отчетов.
  • Необходимо дополнительное обучение пользователей, чтобы гарантировать, что авторы содержимого и потребители знают, где публиковать и находить содержимое.
  • Иногда сложно четко определить типы элементов, которые должны содержаться в рабочей области. Со временем рабочая область может содержать больше типов содержимого, чем изначально предназначено.
  • Использование отдельных рабочих областей приводит к большему количеству рабочих областей, которым требуется управлять и выполнять аудит. При планировании целей область и других аспектов (таких как разделение разработки, тестирования и рабочего содержимого) подход к проектированию рабочих областей может стать более сложным.
  • Для отслеживания и определения приоритетов запрашиваемых изменений в централизованных элементах данных могут потребоваться дополнительные процессы управления изменениями, особенно если создатели отчетов имеют требования, помимо того, что может обрабатывать составные модели и меры уровня отчетов.

Контрольный список . При рассмотрении типов элементов для хранения в рабочей области ключевые решения и действия включают:

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

Доступ к рабочей области

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

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

  • Каковы ожидания того, как будет выполняться совместная работа в рабочей области?
  • Будет ли рабочая область использоваться непосредственно для просмотра содержимого потребителями?
  • Кто будет отвечать за управление содержимым в рабочей области?
  • Кто будет просматривать содержимое, хранящееся в рабочей области?
  • Намерение назначить отдельных пользователей или групп ролям рабочей области?

Рекомендуется использовать группы для назначения ролей рабочей области всякий раз практически. Можно назначить различные типы групп. Группы безопасности, группы безопасности с поддержкой почты, группы распространения и группы Microsoft 365 поддерживаются для ролей рабочей области. Дополнительные сведения об использовании групп см. в разделе "Планирование безопасности на уровне клиента".

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

  • Администраторы рабочей области Fabric — ежеквартальные финансовые ресурсы
  • Члены рабочей области Fabric — ежеквартальные финансовые показатели
  • Участник рабочей области Fabric — квартальные финансовые показатели
  • Средства просмотра рабочих областей Fabric — ежеквартальные финансовые средства
  • Средства просмотра приложений Power BI — ежеквартальные финансовые средства

Совет

Создание перечисленных выше групп обеспечивает гибкость. Однако она включает создание и управление многими группами. Кроме того, управление большим количеством групп может быть сложной задачей, если группы создаются и поддерживаются ИТ-службой. Эта проблема может быть устранена путем включения самостоятельного управления группами для определенных вспомогательных участников. Эти члены могут включать в себя Центр превосходства (COE), чемпионов или доверенных пользователей, которые были обучены в управлении членством в роли для своего бизнес-подразделения. Дополнительные сведения см. в разделе "Планирование безопасности на уровне клиента".

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

  • Администраторы рабочей области данных Fabric — ежеквартальные финансовые ресурсы
  • Администраторы рабочей области создания отчетов Fabric — ежеквартальные финансовые ресурсы
  • Члены рабочей области данных Fabric — ежеквартальные финансовые показатели
  • Члены рабочей области отчетов Fabric — ежеквартальные финансовые показатели
  • Рабочая область данных Fabric участник — ежеквартальные финансовые показатели
  • Рабочая область отчетов Fabric участник — ежеквартальные финансовые показатели
  • Средства просмотра рабочих областей данных Fabric — ежеквартальные финансовые средства
  • Средства просмотра рабочих областей отчетов Fabric — квартальная финансовая информация
  • Средства просмотра приложений Power BI — ежеквартальные финансовые средства

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

  • Администраторы рабочей области данных Fabric — ежеквартальные финансовые средства [разработка]
  • Администраторы рабочей области данных Fabric — ежеквартальные финансовые показатели [тест]
  • Администраторы рабочей области данных Fabric — ежеквартальные финансовые ресурсы

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

Совет

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

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

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

Примечание.

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

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

  • Ознакомьтесь с ролями и обязанностями. Используйте сведения о ролях и обязанностях, подготовленных ранее для планирования ролей рабочей области.
  • Определите, кто будет иметь содержимое и управлять ими: убедитесь, что все элементы, которые вы ожидаете хранить в одной рабочей области, соответствуют людям, которые будут отвечать за владение и управление содержимым. Если существуют несоответствия, пересмотреть способ лучшей организации рабочих областей.
  • Определите, кто будет просматривать содержимое в рабочей области: определите, будут ли пользователи просматривать содержимое непосредственно из рабочей области.
  • Планирование ролей рабочей области. Определите, какие люди подходят для ролей Администратор, участника, участника и средства просмотра для каждой рабочей области.
  • Решите о назначении групп или отдельных ролей: определите, планируется ли назначать отдельных пользователей или групп ролям рабочей области. Проверьте наличие существующих групп, которые можно использовать для назначений ролей рабочей области.
  • Определите, нужно ли создавать новые группы: тщательно рассмотрите необходимость создания новой группы для каждой роли рабочей области. Помните, что это может привести к созданию и поддержанию многих групп. Определите, какой процесс заключается в создании новой рабочей области и способах создания связанных групп.
  • Настройте и проверьте назначения ролей рабочей области. Убедитесь, что у пользователей есть соответствующие параметры безопасности, которые они должны быть продуктивными при создании, редактировании и просмотре содержимого.

Домен рабочей области

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

Дополнительные сведения о планировании доменов в клиенте см. в разделе "Домены рабочей области".

Параметры рабочей области

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

Режим лицензии рабочей области

Каждая рабочая область имеет параметр режима лицензии. Для него можно задать значение Pro, Premium на пользователя, Емкость Premium, Embedded, Fabric или Пробная версия.

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

Тип лицензии важен для планирования рабочей области, так как определяет:

  • Функции. Поддерживаются различные функции. PPU включает дополнительные функции (например , конвейеры развертывания), которые недоступны в Pro. Многие другие функции Fabric (например, lakehouses) становятся доступными для рабочих областей, назначенных емкости Fabric.
  • Доступ к содержимому: тип лицензии определяет, кто может получить доступ к содержимому в рабочей области:
    • Доступ к рабочей области может получить только пользователи, имеющие лицензию PPU (помимо назначения роли рабочей области).
    • Если вы планируете доставлять содержимое пользователям с бесплатной лицензией, вам потребуется лицензия F64 или более поздней версии.
  • Расположение хранилища данных: когда необходимо хранить данные в определенном географическом регионе (за пределами домашнего региона), это становится возможным с рабочей областью, назначенной емкости (и, соответственно, емкость создается в этом регионе). Дополнительные сведения о расположении хранилища данных см. в разделе "Настройка клиента".

Контрольный список . При рассмотрении режима лицензии рабочей области ключевые решения и действия включают:

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

Управление жизненным циклом рабочей области

При совместной работе создателей содержимого для предоставления аналитических решений, важных для организации, существуют различные рекомендации по управлению жизненным циклом. Эти процессы также называются непрерывной интеграцией и непрерывной доставкой (CI/CD), которые являются одним из аспектов DevOps.

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

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

В Fabric существует два основных компонента управления жизненным циклом.

  • Управление версиями интеграции content:Git позволяет владельцам и создателям контента создавать версии своей работы. Его можно использовать с веб-разработкой в рабочей области или при разработке в клиентском средстве, например Power BI Desktop. Управление версиями (также известное как управление версиями) достигается путем отслеживания всех редакций проекта с помощью ветвей , связанных с локальными и удаленными репозиториями в Azure DevOps. Изменения фиксируются через регулярные интервалы в ветвях в удаленный репозиторий. Когда создатель содержимого завершил проверки и утверждения, их ветвь объединяется с последней версией решения в главной удаленный репозиторий (после разрешения конфликтов слиянием). Интеграцию Git можно указать для каждой рабочей области на портале Fabric, если эта функция включена в параметрах клиента.
  • Продвижение конвейеров содержимого:развертывания в основном ориентировано на управление выпусками, чтобы поддерживать стабильную среду для пользователей. Вы можете назначить рабочую область этапу (разработке, тестированию или рабочей среде) в конвейере развертывания. Затем вы можете легко и систематически продвигать или развертывать содержимое на следующем этапе.

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

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

  • Определите, как пользователям требуется использовать управление версиями: анализ того, как работают собственные и расширенные создатели контента, чтобы определить, подходит ли управление версиями файлов с помощью OneDrive для бизнеса или SharePoint. Введите интеграцию Git для расширенных пользователей, которым требуется больше возможностей. Подготовьтесь к поддержке обоих типов пользователей.
  • Определите, как пользователям нужно повысить уровень содержимого. Анализ того, как работают ваши создатели самообслуживания и расширенных создателей контента, чтобы определить, подходят ли конвейеры развертывания для продвижения контента.
  • Определите, следует ли включить интеграцию Git: рассмотрите, подходит ли интеграция Git с рабочими областями для работы создателей содержимого. Задайте пользователям возможность синхронизировать элементы рабочей области с параметрами клиента Git для согласования с этим решением. Просмотрите все параметры клиента интеграции Git и задайте их в соответствии с вашими рекомендациями по управлению.
  • Сделайте подтверждение концепции: провести техническое доказательство концепции, чтобы уточнить, как вы планируете совместно работать с рабочими областями Git и конвейерами развертывания.
  • Определите, какие рабочие области должны иметь интеграцию с Git: рассмотрим, как работают создатели контента, и какие рабочие области должны быть назначены ветви разработки, тестирования или рабочей (выпуска).
  • Проверка лицензий. Убедитесь, что у вас есть лицензия на емкость, доступная для использования интеграции Git. Убедитесь, что каждая рабочая область назначена емкости Fabric или емкости Power BI Premium.
  • Настройте Azure DevOps: обратитесь к администратору, чтобы настроить проекты, репозитории и ветви Azure DevOps, необходимые для каждой рабочей области. Назначьте соответствующий доступ к каждому репозиторию.
  • Подключение рабочих областей: Подключение каждой рабочей области в соответствующий репозиторий Azure DevOps.
  • Рассмотрите возможность развертывания в рабочей среде: примите решения о том, как и кто должен иметь возможность обновлять рабочее содержимое. Убедитесь, что эти решения соответствуют способу обработки владения рабочей областью в вашей организации.
  • Обучите создателей контента: убедитесь, что все создатели содержимого понимают, когда следует использовать функции и методики управления жизненным циклом. Узнайте о рабочем процессе и о том, как различные рабочие области влияют на процессы управления жизненным циклом.

Интеграция рабочей области с ADLS 2-го поколения

Можно подключить рабочую область к учетной записи Azure Data Lake Storage 2-го поколения (ADLS 2-го поколения). Это можно сделать двумя причинами.

  • служба хранилища данных потоков данных Power BI: Если вы решили использовать собственное озеро данных, доступ к данным для потоков данных Power BI (1-го поколения) можно получить непосредственно в Azure. Прямой доступ к хранилищу потоков данных в ADLS 2-го поколения полезен, если вы хотите, чтобы другие пользователи или процессы просматривали или получают доступ к данным. Особенно полезно, если ваша цель заключается в повторном использовании потоков данных за пределами Power BI. Существует два варианта назначения хранилища:
    • Хранилище уровня клиента, которое полезно при централизованном развертывании всех данных для потоков данных Power BI в одну учетную запись ADLS 2-го поколения.
    • Хранилище уровня рабочей области, которое полезно, если бизнес-подразделения управляют собственным озером данных или имеют определенные требования к месту расположения данных.
  • Резервное копирование и восстановление для семантических моделей Power BI:функция резервного копирования и восстановления семантической модели Power BI поддерживается для рабочих областей, назначенных емкости или PPU. Эта функция использует ту же учетную запись ADLS 2-го поколения, которая используется для хранения данных потоков данных Power BI (описано в предыдущей точке маркера). Резервные копии семантической модели полезны для:
    • Соответствие требованиям к хранению данных
    • Хранение стандартных резервных копий в рамках стратегии аварийного восстановления
    • Хранение резервных копий в другом регионе
    • Перенос модели данных

Внимание

Настройка подключений Azure на портале администрирования Fabric не означает, что все потоки данных для всего клиента хранятся по умолчанию в учетной записи ADLS 2-го поколения. Чтобы использовать явную учетную запись хранения (вместо внутреннего хранилища), каждая рабочая область должна быть явно подключена. Важно задать подключения к рабочей области Azure перед созданием потоков данных Power BI в рабочей области.

Контрольный список . При рассмотрении интеграции рабочей области с ADLS 2-го поколения ключевые решения и действия включают:

  • Определите, будет ли рабочая область использоваться способами, требующими служба хранилища Azure. Рассмотрите, будет ли использовать сценарий создания собственного озера данных для хранения потоков данных и (или) требуется ли использовать функции резервного копирования и восстановления семантической модели.
  • Определите, какая учетная запись служба хранилища Azure будет использоваться: выберите учетную запись служба хранилища Azure с включенным иерархическим пространством имен (ADLS 2-го поколения) для хранения данных на уровне клиента или резервных копий семантической модели. Убедитесь, что у вас есть доступные сведения о служба хранилища Azure учетной записи.
  • Настройте учетную запись хранения на уровне клиента: на портале администрирования Fabric задайте учетную запись хранения ADLS уровня клиента 2-го поколения.
  • Определите, могут ли администраторы рабочих областей подключать учетную запись хранения: обсуждение потребностей децентрализованных команд и то, поддерживают ли отдельные команды свои собственные служба хранилища Azure учетные записи. Определите, следует ли включить эту возможность.
  • Настройте параметр администратора для хранилища на уровне рабочей области: на портале администрирования Fabric включите параметр, позволяющий администраторам рабочей области подключать собственную учетную запись хранения.
  • Задайте подключения уровня рабочей области служба хранилища Azure. Укажите учетную запись служба хранилища Azure для каждой отдельной рабочей области. Перед созданием потоков данных Power BI в рабочей области необходимо задать учетную запись хранения. Если вы планируете использовать резервные копии семантической модели, убедитесь, что для режима лицензии рабочей области задана емкость или PPU.
  • Обновите документацию по управлению рабочей областью. Убедитесь, что документация по управлению рабочей областью содержит сведения о том, как правильно назначать учетные записи хранения ADLS 2-го поколения. Сделайте информацию доступной на централизованном портале и учебных материалах.

Интеграция рабочей области с Azure Log Analytics

Azure Log Analytics — это служба в Azure Monitor. Azure Log Analytics можно использовать для просмотра диагностических данных, созданных подсистемой служб Analysis Services, в которой размещаются семантические модели Power BI. Журналы уровня рабочей области полезны для анализа производительности и тенденций, выполнения анализа обновлений данных, анализа операций конечной точки XMLA и многого другого. Azure Log Analytics доступен только для рабочих областей, назначенных емкости или PPU.

Примечание.

Хотя имена похожи, данные, отправленные в Azure Log Analytics, отличаются от данных, захваченных журналом действий Power BI. Данные, отправленные в Azure Log Analytics, связаны с событиями , созданными подсистемой служб Analysis Services (например, события начала запроса и завершения запроса). И наоборот, журнал действий связан с отслеживанием действий пользователей (например, просмотр отчетов или изменение событий отчета ).

Дополнительные сведения о журналах событий семантической модели см. в разделе "Аудит на уровне данных".

Дополнительные сведения о настройке Azure Log Analytics для использования с Power BI см. в статье "Настройка Azure Log Analytics для Power BI". Не забудьте понять необходимые условия, необходимые для обеспечения работы интеграции.

Контрольный список . При рассмотрении интеграции рабочей области с Azure Log Analytics ключевые решения и действия включают:

  • Определите, могут ли администраторы рабочих областей подключаться к Log Analytics: определите, разрешено ли использовать Azure Log Analytics для анализа журналов на уровне рабочей области. Если доступ ограничен только определенными людьми, решите, какую группу следует использовать.
  • Настройте параметр клиента для подключений Log Analytics: на портале администрирования Fabric задайте параметр клиента в соответствии с решением, для которого администраторы рабочей области устанавливают подключения.
  • Задайте рабочую область Log Analytics для каждой рабочей области: в параметрах рабочей области укажите сведения о Azure Log Analytics для каждой рабочей области. Чтобы записать журналы на уровне рабочей области, убедитесь, что для режима лицензии рабочей области задана емкость или PPU.
  • Обновите документацию по управлению рабочей областью. Убедитесь, что документация по управлению рабочей областью содержит сведения о назначении рабочей области Azure Log Analytics.

Другие свойства рабочей области

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

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

  • Описание рабочей области. Хорошее описание рабочей области содержит краткое, но конкретное объяснение того, какой тип содержимого можно найти в рабочей области. Для описания можно использовать до 4000 символов:
    • Назначение рабочей области
    • Целевая аудитория
    • Тип содержимого, опубликованного в рабочей области
    • Считается ли рабочая область управляемой
    • Включает ли рабочая область разработку, тестирование или рабочие данные
    • Кто, чтобы связаться, должны быть какие-либо вопросы (иногда важно отображать эту информацию как можно чаще, в дополнение к списку контактов, описанному далее).
  • Контакты рабочей области: список контактов рабочей области включает администраторов рабочей области по умолчанию. Если у вас есть технические владельцы контента, которые отличаются от экспертов по темам, может оказаться полезным указать другие контакты. Другие контакты могут быть группами или отдельными лицами, которые могут отвечать на вопросы о содержимом рабочей области.
  • Образ рабочей области. Согласованное использование образов рабочей области может быть полезно для пользователей при сканировании списка рабочих областей. Рассмотрите возможность использования образа, чтобы помочь пользователям определить:
    • Область домена или темы
    • Какой бизнес-подразделение или команда владеет и управляет содержимым
    • Независимо от того, является ли она рабочей областью данных (которая предназначена для хранения повторно используемых элементов, таких как lakehouse, хранилище, конвейер данных, поток данных или семантическая модель).
    • Будь то рабочая область отчетов (которая предназначена для хранения аналитических элементов, таких как отчеты, панели мониторинга или метрики)
  • Параметры модели данных: позволяет членам рабочей области, администраторам и пользователям с разрешением на сборку для семантических моделей изменять модели данных Power BI с помощью веб-интерфейса. Этот параметр используется вместе с пользователями, которые могут изменять модели данных в параметре клиента служба Power BI. Этот параметр должен соответствовать вашим решениям и процессам по созданию, управлению и развертыванию содержимого. Кроме того, рассмотрим метод управления версиями , как описано ранее в этой статье.

Контрольный список . При рассмотрении других свойств рабочей области ключевые решения и действия включают:

  • Укажите описание рабочей области: убедитесь, что в описании рабочей области есть полезное и тщательное описание.
  • Используйте полезный образ для рабочей области: задайте согласованный образ для рабочей области, которая визуально поможет пользователям понять свою тему, которая владеет содержимым в рабочей области и /или тип контента, хранящегося в рабочей области.
  • Определите контакты для рабочей области: проверьте, должны ли администраторы рабочей области быть контактами рабочей области, или следует ли указывать конкретных пользователей или групп.
  • Укажите параметры модели данных. Рассмотрим, какие рабочие области могут разрешать редактирование модели данных на основе веб-сайтов. Задайте пользователям возможность изменять модели данных в параметре клиента служба Power BI в соответствии с вашими предпочтениями, которые могут изменять содержимое и управлять ими.

Другие технические факторы

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

  • Если вы интегрируете содержимое с другими инструментами и службами, могут возникнуть последствия лицензирования. Например, если вы внедряете визуальный элемент Power Apps в отчет Power BI, вам потребуется соответствующие лицензии Power Apps.
  • Существуют ограничения на хранилище рабочей области, которые применяются к объему данных, которые можно хранить в рабочей области Pro. Если использование емкости или PPU не является вариантом, рассмотрите возможность работы в пределах ограничений хранилища во время планирования рабочей области.
  • При установке приложения-шаблона из AppSource он создаст новую рабочую область, которая будет иметь узкий предмет и область.

Контрольный список . При рассмотрении других технических факторов ключевые решения и действия включают:

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

Связанный контент

Дополнительные рекомендации, действия, критерии принятия решений и рекомендации по внедрению Power BI см. в статье о планировании реализации Power BI.