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

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

Примечание.

Эта статья является частью серии статей по планированию реализации Power BI . Серия посвящена планированию реализации интерфейса Power BI в Microsoft Fabric. Посмотрите введение к серии.

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

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

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

Примечание.

Концепция рабочей области, возникшей в Power BI. В платформе Fabric назначение рабочего пространства расширяется. Рабочая область 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 может повлиять на решение о создании рабочей области.
  • Учитывайте ожидания по объему доставки контента: Рассмотрите, как различные объемы доставки контента (персональный BI, командный BI, департамента BI и корпоративный BI) будут влиять на то, как вы разрабатываете и используете рабочие области.

Совет

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в схеме внедрения Fabric:

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

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

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

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

Совет

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

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

Совет

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

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

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

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

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

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

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

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

В некоторых случаях у вас уже могут быть некоторые полезные группы, установленные в идентификаторе Microsoft Entra. Группы можно использовать для управления доступом к ресурсам для определенной тематики и сферы. Однако для полной реализации этого подхода может потребоваться создать новые группы. Дополнительные сведения см. в разделе "Доступ к рабочей области".

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

Ниже приведены некоторые примеры:

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

На следующей схеме показано, как можно разделить рабочие области по типу элемента.

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

Совет

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

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

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

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

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

Этап разработки рабочей области

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

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

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

Ниже приведен пример этой настройки:

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

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

Ниже приведен пример:

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

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

  • Частные рабочие пространства для создателей, чтобы работать без отвлекающих факторов. Эта настройка является распространенной практикой совместной работы с контентом с помощью интеграции Git, так как каждый создатель контента работает на отдельном копировании (ветвь) содержимого, чтобы избежать нарушения работы друг друга. Затем создатели могут открыть пул-реквест, чтобы объединить изменения с другой ветвью, которая синхронизируется в рабочую область разработки, которую создатели могут просматривать, но не изменять или публиковать содержимое.
  • Предварительные рабочие области для создателей для выполнения определенных тестов перед выпуском содержимого. Эти тесты могут включать тестирование производительности или тестирование вспомогательных ресурсов, таких как шлюзы данных и приложения.
  • Изолированные рабочие области для создателей, чтобы свободно экспериментировать и проводить импровизированные исследования. Рабочие области песочницы обычно очищаются с определённой регулярностью (часто автоматически, например, с помощью API или блокнотов). Содержимое, которое создатели хотят сохранить из рабочей области песочницы, можно скопировать в личную или частную рабочую область для получения дополнительных возможностей разработки.

Совет

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

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

Преимущества разделения рабочих областей по этапу разработки:

  • Вы можете поддерживать более сложные и структурированные процессы разработки, в том числе:

    • Пайплайны развертывания для копирования содержимого между стадиями
    • Интеграция Git и стратегии ветвления для развертывания и релиза
    • Ноутбуки для оркестрации или автоматизации определенных задач в процессе управления контентом.

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

  • У вас есть более эффективное управление доступом к содержимому.

Недостатки разделения рабочих областей по этапу разработки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

  • Администраторы рабочей области данных Fabric — ежеквартальные финансовые отчёты
  • Рабочая область отчетности администраторов Fabric — Ежеквартальные финансовые отчеты
  • Рабочая область данных Fabric члены — ежеквартальные финансовые показатели
  • Члены рабочей области Fabric для отчетов — ежеквартальные финансовые показатели
  • Участники пространства данных Fabric— ежеквартальные финансовые показатели
  • Рабочая область отчетности Fabric - участники - квартальные финансовые показатели
  • Просмотрщики рабочих пространств данныхFabric — ежеквартальные финансовые отчеты
  • Просмотрщики Fabric отчетоврабочих областей – квартальная финансовая отчетность
  • Просмотрщики приложений Power BI — ежеквартальные отчеты о финансах

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

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

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

Совет

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

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

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

Примечание.

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

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

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

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

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

Для получения дополнительной информации о планировании доменов в вашем клиенте см. раздел «Домены рабочей области».

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

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

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

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

Внимание

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

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

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

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

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

    • Доступ к рабочей области получают только пользователи, которые имеют лицензию PPU в дополнение к назначению роли в рабочей области.
    • Чтобы предоставлять контент зрителям, имеющим бесплатную лицензию, вам потребуется лицензия F64 или выше.

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

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

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

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

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

Рекомендации по управлению жизненным циклом включают в себя:

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

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

  • Управление версиями содержимого: интеграция 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.
  • Обдумайте, кто должен выполнять развертывание в рабочей среде: примите решения о том, кто может обновлять рабочее содержимое и как. Убедитесь, что эти решения соответствуют тому, как в вашей организации управляется владение рабочими пространствами.
  • Обучите создателей контента: убедитесь, что все создатели содержимого понимают, когда следует использовать функции и методики управления жизненным циклом. Узнайте о рабочем процессе и о том, как различные рабочие области влияют на процессы управления жизненным циклом.

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

Можно подключить рабочую область к учетной записи Azure Data Lake Storage 2-го поколения. Вы можете использовать этот подход по двум причинам:

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

    • Хранилище уровня клиента, которое полезно, если требуется централизировать все данные для потоков данных Power BI в одну учетную запись Data Lake Storage 2-го поколения.
    • Хранилище на уровне рабочей области, которое полезно, если бизнес-подразделения управляют собственным озером данных или имеют определенные требования к расположению данных.

  • Резервное копирование и восстановление для семантических моделей Power BI: функция резервного копирования и восстановления семантической модели Power BI поддерживается для рабочих областей, назначенных емкости или PPU. Эта функция использует ту же учетную запись Data Lake Storage Gen2, которая используется для хранения данных Power BI dataflows (описано выше). Резервные копии семантической модели полезны для:

    • Соответствие требованиям к хранению данных
    • Хранение стандартных резервных копий в рамках стратегии аварийного восстановления
    • Хранение резервных копий в другом регионе
    • Перенос модели данных

Внимание

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

Контрольный список ключевых решений и действий при планировании интеграции рабочей области с Data Lake Storage 2-го поколения:

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

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

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

Примечание.

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

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

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

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

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

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

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

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

  • Описание рабочей области. Хорошее описание рабочей области содержит краткое, но конкретное объяснение типа контента в рабочей области. Для описания можно использовать до 4 000 символов:

    • Назначение рабочей области
    • Целевая аудитория
    • Тип содержимого, опубликованного в рабочей области
    • Считается ли рабочая область управляемой
    • Включает ли рабочая область разработку, тестирование или рабочие данные
    • Кто обращается за вопросами или поддержкой

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

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

    Рассмотрите возможность использования образа для идентификации пользователей:

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

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

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

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

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

Другие технические факторы могут повлиять на настройку рабочей области:

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

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

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

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

Дополнительные соображения, действия, критерии принятия решений и рекомендации, которые помогут вам в принятии решений по внедрению Power BI, см. в следующей статье:

  • Last updated on