通过

Power BI 实现计划：工作区级工作区计划

  • 项目

备注

本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。

本文介绍了 Fabric 工作区级别规划，重点介绍了 Power BI 体验。 主要面向以下对象：

  • Fabric 管理员：负责监督组织的 Fabric 的管理员。
  • 卓越中心、IT 和 BI 团队：同样负责监督数据和 BI 并为整个组织的自助服务用户提供支持的团队。
  • 内容创建者和所有者：需要创建、发布和管理工作区中内容的自助式创建者。

为了有效地使用工作区，需要做出许多战术决策。 各个工作区级决策应尽可能与租户级决策保持一致。

注意

工作区的概念源自 Power BI。 有了 Fabric，工作区的用途变得更加广泛。 结果就是工作区现在可以包含一个或多个不同 Fabric 体验中的项（也称为“工作负载”）。 尽管内容范围已经变得比 Power BI 更广，但这些文章中所述的大多数工作区规划活动都可应用于 Fabric 工作区规划。

工作区用途

计划工作区时，请务必不仅要考虑工作区将存储的内容类型，还要考虑工作区可用于支持的活动。

请查看以下两个与财务相关的工作区示例。 尽管它们都专用于同一团队，但每个工作区都有不同的用途：

  • 财务月末工作区：财务月末工作区包含对帐和月末结算报表。 此工作区被视为非正式工作区，用于支持协作工作。 对于内容查看者来说，Power BI 应用不是必需的，因为此工作区的主要用途是供一小群密切合作的人员进行协作。 大多数团队成员都有权编辑此工作区中的内容。
  • 财务报表工作区：财务报表工作区包含最终的演示级报表。 此工作区包含通过使用 Power BI 应用在整个组织中广泛分发给许多查看者（包括高级管理人员）的内容。 工作区受到严格治理。

有了这两个示例，接下来看看工作区用途的两个特定方面：“协作意向”和“查看意向”。

协作意向

Fabric 门户中工作区的主要目标是促进多人之间的协作。 在工作区中可通过多种方式进行协作：

  • 基于团队的开发：多人可以协同生成、测试和发布内容。 一名用户可以处理湖屋设计。 另一名用户可以处理语义模型（以前称为数据集）的设计，而其他用户可以专注于生成报表。
  • 测试和验证：用户可能需要对新内容执行数据验证。 业务单位的主题专家可能需要执行用户验收测试 (UAT)，或者数据质量团队可能需要验证语义模型的准确性。
  • 增强功能：随着情况的变化，内容的利益干系人和使用者可能会建议对内容进行增强。
  • 所有权转让：另一个人或团队可能承担他人创建的内容的责任。

Fabric 采用路线图的关键领域之一是内容所有权和管理。 工作区中将进行的协作类型因用于内容所有权和管理的方法而异：

  • 业务导向型自助式 BI：内容归业务单位或部门内的内容创建者所有和管理。 在此方案中，工作区中的大多数协作都在该业务单位内的用户之间进行。
  • 托管的自助式 BI：数据归集中式团队所有和管理，而自业务单位中的各种内容创建者负责报表和仪表板。 在此方案中，很可能需要多个工作区才能安全地促进多个团队的协作。
  • 企业 BI：内容归集中式团队（如 IT、企业 BI 或卓越中心 (COE)）所有和管理。 在此方案中，工作区中的协作工作在集中式团队中的用户之间进行。

清单 - 考虑工作区中协作的意向时，关键决策和操作包括：

  • 考虑协作预期：确定工作区协作需要如何进行，以及参与单个团队或跨组织边界的人员。
  • 考虑对内容所有权和管理预期：考虑不同的内容所有权和管理方法（业务导向型自助式 BI、托管的自助式 BI 和企业 BI）将如何影响设计和使用工作区的方式。

提示

如果单个方法无法满足需求，请做好准备，灵活地针对不同的工作区使用不同的内容所有权和管理策略。 策略可以基于方案，也可以基于所涉及的团队成员。

内容查看意向

工作区的次要目标是将内容分发给需要查看内容的使用者。 对于内容查看器，主要的 Fabric 工作负载是 Power BI。

可通过几种不同的方法在 Power BI 服务中处理内容分发：

  • 可以使用 Power BI 应用查看报表：可以将存储在非个人工作区中的内容发布到Power BI 应用。 与直接在工作区中查看报表相比，Power BI 应用的用户体验更加友好。 因此，使用 Power BI 应用通常是向使用者分发内容的最佳选项。 Power BI 应用的受众非常灵活。 但有时，希望如何通过应用分发内容的目标是决定如何在工作区中或跨工作区组织内容的一个因素。 有关保护 Power BI 应用的详细信息，请参阅报表使用者安全性计划。
  • 可以直接在工作区中查看报表：这种方法通常适用于非正式的协作工作区。 工作区角色定义谁可以查看或编辑工作区中包含的内容。 有关工作区角色的详细信息，请参阅内容创建者安全性计划。
  • 可以共享报表：需要为工作区中的单个项提供只读访问权限时，使用每项权限（链接或直接访问）非常有用。 比起共享，建议更频繁地使用应用权限和工作区角色，因为后者更易于维护。 有关详细信息，请参阅报表使用者安全性计划。
  • 可以将报表嵌入另一个应用程序并进行查看：有时，目的是让使用者查看嵌入在另一个应用程序中的 Power BI 内容。 当用户需要留在应用程序中以提高效率并保持其工作流时，嵌入内容非常有用。

Fabric 采用路线图的另一个关键领域是内容交付范围。 工作区支持内容分发的方式因内容交付范围而异：

  • 个人 BI：内容供创作者使用。 由于目标不是与他人共享内容，因此个人 BI 是在个人工作区中完成的（在下一主题中介绍）。
  • 团队 BI：与数量相对较少且密切合作的同事共享内容。 在此方案中，大多数工作区都是非正式的协作工作区。
  • 部门 BI：向许多使用者分发内容，这些使用者可能是大型部门或业务部门成员。 在此方案中，工作区主要用于协作工作。 在部门 BI 方案中，通常在 Power BI 应用中查看内容（而不是直接在工作区中查看）。
  • 企业 BI：跨组织级边界交付内容，目标使用者的数量最多。 在此方案中，工作区主要用于协作工作。 对于企业 BI 方案，通常在 Power BI 应用中查看内容（而不是直接在工作区中查看）。

提示

计划工作区时，请在确定工作区许可证模式时考虑受众的需求。 分配给工作区的许可证类型将影响可用功能，包括谁可以查看或管理工作区内容。

清单 - 考虑对工作区内容查看方式的预期时，关键决策和操作包括：

  • 考虑对查看内容的预期：确定希望使用者如何查看已发布到工作区的内容。 考虑是直接在工作区中查看还是使用其他方法查看。
  • 确定内容将交付的对象：考虑目标受众是谁。 还要考虑工作区许可证模式，尤其是预期有大量内容查看者时。
  • 评估 Power BI 应用的需求：考虑工作区的用途是什么，因为它与内容分发要求相关。 需要 Power BI 应用时，它会影响有关创建工作区的决策。
  • 考虑对内容交付范围的预期：考虑不同的内容交付范围（个人 BI、团队 BI、部门 BI 和企业 BI）将如何影响你设计和使用工作区的方式。

提示

做好准备，灵活一些。 可以根据方案以及所涉及的团队成员对工作区使用不同的内容查看策略。 此外，在合理的情况下，不要害怕对工作区使用不同的内容交付范围方法。

适当使用个人工作区

有两种类型的工作区：

  • 个人工作区：每个用户都有一个个人工作区。 个人工作区可用于将某些类型的内容发布到 Fabric 门户。 其主要目的是支持个人 BI 使用方案。
  • 工作区：工作区的主要目的是支持多个用户之间的协作。 其次，工作区也可用于查看内容。

将个人工作区用于学习个人 BI、临时内容或测试目的之外的任何操作都可能存在风险，因为个人工作区中的内容由一个人管理和维护。 此外，个人工作区不支持与他人协作。

要允许创建任何类型的 Fabric 项（例如，湖屋或仓库 ），必须将工作区添加到Fabric 容量。 对于标准工作区和个人工作区都是如此。 因此，可以通过其容量分配来治理谁能够在个人工作区中创建某些类型的项。

个人工作区在与他人共享内容的选项方面存在限制。 无法从个人工作区发布 Power BI 应用（Power BI 应用是向组织分发内容的重要机制）。 每项权限（链接或直接访问）是与他人共享个人工作区内容的唯一方式。 因此，广泛使用每项权限涉及更多的工作并会增加出错的风险。 有关详细信息，请参阅报表使用者安全性计划。

清单 - 考虑对个人工作区使用方式的预期时，关键决策和操作包括：

  • 了解个人工作区的当前使用情况：与用户进行对话并查看活动活动数据，确保了解用户正在使用其个人工作区执行的操作。
  • 确定应如何使用个人工作区：确定应该（和不应该）如何在组织中使用个人工作区。 专注在风险和易用性以及内容协作和查看需求间进行平衡。
  • 视情况重新定位个人工作区内容：对于关键内容，视情况将内容从个人工作区移至标准工作区。
  • 创建和发布有关个人工作区的文档：为用户创建有关如何有效使用个人工作区的有用文档或常见问题解答。 在集中式门户和培训材料中提供信息。

注意

有关详细信息，请参阅以下 Fabric 采用路线图主题：集中式门户、培训和文档。

工作区所有权

计划工作区时要考虑的最重要的事情之一是确定所有权和管理权角色和职责。 目标是明确谁负责创建、维护、发布、保护和支持每个工作区中的内容。

当创建和管理数据的责任分散或分布在部门和业务部门之间时，明确所有权尤其重要。 此概念有时也称为数据网格体系结构。 有关数据网格的详细信息，请参阅什么是数据网格？。

在 Fabric 中，通过工作区启用分散式或分布式所有权。 组织的不同领域可以独立工作，同时仍为OneLake中的相同基础数据结构做出贡献。 每个工作区都可以有自己的管理员、访问控制和容量分配（用于计费、地理数据位置和性能监视）。

提示

在 Fabric 中支持工作区所有权的另一种方法是使用域，本文稍后对此进行了介绍。

当协作意向涉及分散和单个业务部门以外的多个团队时，管理工作区可能会变得更复杂。 通常，创建单独的工作区以清楚地描述哪个团队负责哪些内容会很有帮助。 使用多个工作区可以明确所有权和管理职责，并且有助于根据最小权限原则设置安全性。 有关更多安全注意事项，请参阅内容创建者安全规划。

提示

与问责制和职责相关的决定应与定义工作区访问权限的相关操作直接关联，本文稍后将对此进行介绍。

清单 - 考虑工作区所有权职责时，关键决策和操作包括：

  • 全面了解内容所有权的工作原理：确保深入了解整个组织中内容所有权和管理的发生方式。 要认识到不可能有一种适用于整个组织的万能方法。 了解分散式或分布式所有权需求。
  • 定义和记录角色和职责：确保为在工作区中协作的人员定义并记录明确的角色和职责。 在入职活动、培训材料和集中式门户中提供此信息。
  • 创建职责矩阵：确定在创建、维护、发布、保护和支持内容时每个职能的负责人。 开始计划工作区访问角色时，请准备好这些信息。
  • 考虑共同所有权或多团队所有权方案：确定何时创建有助于分离工作区以明确职责的方案。
  • 创建工作区管理文档：向工作区管理员和成员介绍如何管理工作区设置和访问权限。 包括工作区管理员、成员和参与者的职责。 在集中式门户和培训材料中提供信息。

工作区组织

如何组织工作区是工作区计划最重要的方面之一。

根据协作需求的不同，不同的业务单位和部门使用工作区的方式可能略有不同。 需要新的工作区时，建议考虑本部分所述的因素。

工作区主题和范围

以下选项提供了一些有关如何按主题和范围组织工作区的建议。

在某些情况下，你可能已在 Microsoft Entra ID（前 Azure Active Directory）中建立了一些有用的组。 你可以使用它们来管理对已定义主题区域和范围的资源的访问。 但是，可能需要创建一些新组来满足此目的。 有关注意事项，请参阅下面的工作区访问权限部分。

选项 1：每个主题区域或项目一个工作区

为每个主题区域或项目创建一个工作区可以让你专注于其用途。 这使你可以采用均衡的方法。

示例：“季度财务”或“产品发布分析”

选项 1 的优点包括：

  • 可更直接地管理允许编辑或查看内容的用户访问权限，因为该选项是按主题区域划分的。
  • 如果用户需要跨组织级边界访问内容，则按主题区域构建工作区更为灵活且更易于管理（与接下来讨论的选项 2 相比）。
  • 在包含过多项的工作区和包含过少项的工作区之间，使用按主题区域划分的范围是一个很好的折衷方案。

选项 1 的一个缺点是，根据工作区定义范围的宽窄，仍然存在创建过多工作区的风险。 当内容分布在多个工作区时，查找内容对用户来说可能具有挑战性。

提示

如果计划和管理得当，按主题区域或项目划分的工作区数量通常可管理。

选项 2：每个部门或团队一个工作区

为每个部门或团队（或业务单位）创建一个工作区是一种常见的方法。 事实上，与组织结构图保持一致是人们开始工作区计划的最常见方式。 但是，它并不适用于所有方案。

示例：财务部门或销售团队分析

选项 2 的优点包括：

  • 开始计划很简单。 在该部门工作的人员所需的所有内容都将驻留在一个工作区中。
  • 用户很容易知道要使用哪个工作区，因为他们的所有内容都发布到与其部门或团队关联的工作区。
  • 管理安全角色非常简单，尤其是在 Microsoft Entra 组分配给工作区角色时（这是最佳做法）。

选项 2 的缺点包括：

  • 结果通常是一个范围很宽的工作区，其中包含许多项。 定义范围较宽的工作区范围会使用户难以找到特定项。
  • 由于工作区和 Power BI 应用之间存在一对一的关系，因此定义范围较宽的工作区可能会导致用户的应用包含大量内容。 可以通过从应用中排除某些工作区项以及实现设计良好的应用导航体验来缓解此问题。
  • 当其他部门的用户需要查看特定的工作区项时，管理权限会变得更加复杂。 这样做的风险是，人们会认为部门工作区里的所有内容都是他们的专属。 还有一种风险是，为了实现精细的查看权限，对个别项的共享将被过度使用。
  • 如果某些内容创建者需要编辑某些项（但不是所有项）的权限，则无法在单个工作区中设置这些权限。 这是因为确定编辑或查看权限的工作区角色是在工作区级别定义的。
  • 拥有大量工作区项时，通常意味着需要对项使用严格的命名约定，以便用户能够找到所需内容。
  • 包含许多项的宽泛工作区可能会遇到可存储在工作区中的项数的技术限制。

提示

在创建与组织结构图一致的工作区时，通常会生成更少的工作区。 但是，这可能会导致工作区包含大量内容。 预期拥有大量项和/或许多用户时，不建议让每个部门或团队的工作区保持一致。

选项 3：用于特定报表或应用的工作区

除特定情况外，不建议为每个报表或分析类型创建工作区。

示例：“每日销售摘要”或“主管奖金”

选项 3 的优点包括：

  • 定义范围较窄的工作区的目的很明确。
  • 超敏感内容可以（且通常应该）隔离到其自己的工作区中，以便可以明确地对其进行管理和治理。
  • 精细的工作区权限适用于少数项。 例如，当允许用户编辑一个报表但不能编辑另一个报表时，此设置很有用。

选项 3 的缺点包括：

  • 如果过度使用，创建定义范围较窄的工作区会导致生成大量工作区。
  • 处理大量工作区需要付出更多的工作。 虽然用户可以依赖搜索，但在正确工作区中找到正确内容的体验可能不佳。
  • 存在大量工作区时，从审计和监视的角度来看，工作量就更多了。

提示

仅应出于特定原因创建定义范围较窄的工作区（例如单个报表）。 这应该是例外，而不是常态。 有时，将记分卡分隔到其各自的工作区是一种有用的技术。 例如，当记分卡呈现跨越多个主题区域的目标时，使用单独的工作区很有帮助。 设置用于管理和查看记分卡的特定权限也很有帮助。

清单 - 考虑工作区内容的主题区域和范围时，关键决策和操作包括：

  • 评估当前工作区是如何设置的：查看人们当前如何使用工作区。 确定哪些是有效的，哪些是无效的。 计划可能的更改和用户培训机会。
  • 考虑最佳工作区范围：根据目的、主题区域、范围和内容管理负责人确定希望人们如何使用工作区。
  • 确定高度敏感内容所在的位置：确定何时为高度敏感内容创建特定工作区是合理的。
  • 创建和发布有关使用工作区的文档：为用户创建有关如何组织和使用工作区的有用文档或常见问题解答。 在培训材料和集中式门户中提供此信息。

工作区项类型

将数据资产与报告工作区分离是将数据资产与分析资产分离的常见做法。

  • 数据工作区专用于存储和保护数据项，例如湖屋、仓库、数据管道、数据流或语义模型。
  • 报告工作区更侧重于下游分析活动。 它专用于存储和保护报表、仪表板和指标等项。 报告工作区主要（但不一定只）包含 Power BI 内容。

提示

每个Fabric 体验都允许创建各种类型的项。 这些项并不总是完全符合数据与报告（或分析）内容的概念。 一个示例是可以以多种不同方式使用的Fabric 笔记本，例如：在湖屋中加载和转换数据、提交 Spark SQL 查询或使用 PySpark 分析和可视化数据。 当工作区包含混合工作负载时，建议主要关注工作区目的和内容的所有权，如本文其他部分所述。

将数据工作区与报表工作区分开的优点包括：

  • 关键组织数据（例如，认可的湖屋或语义模型）可以驻留在特定的工作区中，该工作区旨在使可重用数据在企业规模上可用。 常见示例包括：
  • 访问管理可以集中用于关键的组织数据。 当不同的人负责数据和报表时，分别管理数据工作区和报表工作区的访问非常有用。 使用托管的自助式 BI，通常会有很多报表创建者，而数据创建者却很少。
  • 限制谁可以编辑和管理语义模型，可以最大程度地降低意外更改的风险，尤其是对于出于多种目的或由许多用户重用的关键数据项更是如此。 物理分离可减少出现无意或未经批准的更改的可能性。 这一额外的保护层对于经过认证的语义模型很有用，这些语义模型依赖于其质量和可信度。
  • 明确了共同所有权方案。 当共享语义模型由集中式 BI 或 IT 团队提供，而报表由自助式内容创建者（在业务单位中）发布时，最好将语义模型隔离到单独的工作区中。 这种方法避免了共同所有权方案的模糊性，因为每个工作区的所有权和职责都可得到更清晰的定义。
  • 行级别安全性 (RLS) 已强制执行。 当你鼓励创建者在不同的工作区中工作时，他们对原始语义模型没有不必要的编辑权限。 优点是，将为内容创建者（以及内容查看者）强制执行 RLS和/或对象级安全 (OLS)。

将数据工作区与报表工作区分开的缺点包括：

  • 需要工作区命名约定才能将数据工作区与报表工作区区分开来。
  • 需要额外的用户教育，以确保内容作者和使用者知道在哪里发布和查找内容。
  • 有时很难清楚地描述应包含在工作区中的项类型。 随着时间的推移，工作区最终可能包含比最初预期更多的内容类型。
  • 使用单独的工作区会导致需要管理和审核更多的工作区。 计划目的、范围和其他考虑因素（例如开发、测试和生产内容的分离）时，工作区设计方法可能会变得更加复杂。
  • 可能需要额外的变更管理流程来跟踪对集中式数据项的请求变更并确定其优先级，尤其是当报表创建者的要求超出复合模型和报表级措施所能处理的范围时，情况尤其如此。

清单 - 考虑存储在工作区中的项类型时，关键决策和操作包括：

  • 确定数据重用目标：决定如何将数据重用作为托管的自助式 BI 策略的一部分。
  • 更新有关谁可以跨工作区使用语义模型的租户设置：确定是否可以将此功能授予所有用户。 如果决定限制可以跨工作区使用语义模型的人员，请考虑使用名为 Fabric 批准的报表创建者之类的组。

工作区访问权限

由于工作区的主要目的是协作，因此工作区访问权限主要适用于创建和管理其内容的用户。 当工作区用于查看内容（工作区的次要目的，如本文前面所述）时，权限也可能与上述人员相关。

开始计划工作区角色时，建议问自己以下问题。

  • 对工作区中的协作方式有何预期？
  • 工作区是否会直接用于使用者查看内容？
  • 谁将负责管理工作区中的内容？
  • 谁将查看存储在工作区中的内容？
  • 是否打算将单个用户或组分配给工作区角色？

最佳做法是在可行的情况下使用组来分配工作区角色。 可以分配不同类型的组。 工作区角色支持安全组、已启用邮件的安全组、通讯组和 Microsoft 365 组。 有关使用组的详细信息，请参阅租户级安全性计划。

计划使用组时，可以考虑为每个工作区的每个角色创建一个组。 例如，为了支持“季度财务”工作区，可以创建以下组：

  • Fabric 工作区 管理员 – 季度财务
  • Fabric 工作区 成员 – 季度财务
  • Fabric 工作区 参与者 – 季度财务
  • Fabric 工作区 查看者 – 季度财务
  • Power BI 应用查看者 – 季度财务

提示

创建上面列出的组可提供灵活性。 但是，这涉及创建和管理多个组。 此外，当组仅由 IT 创建和维护时，管理大量组可能具有挑战性。 通过向某些附属成员启用自助式组管理，可以缓解这一挑战。 这些成员可以包括卓越中心 (COE)、支持者或经过培训的受信任用户，这些用户已了解过如何管理其业务单位的角色成员身份。 有关详细信息，请参阅租户级安全性计划。

当数据工作区与报告工作区分离时，如前文描述的，会产生更多的组。 想一想在分离数据和报告工作区时，组的数量是如何从 5 个翻倍到 10 个的：

  • Fabric 数据 工作区 管理员 – 季度财务
  • Fabric 报告 工作区 管理员 – 季度财务
  • Fabric 数据 工作区 成员 – 季度财务
  • Fabric 报告 工作区 成员 – 季度财务
  • Fabric 数据 工作区 参与者 – 季度财务
  • Fabric 报告 工作区 参与者 – 季度财务
  • Fabric 数据 工作区 查看者 – 季度财务
  • Fabric 报告 工作区 查看者 – 季度财务
  • Power BI 应用查看者 – 季度财务

当存在多个用于开发、测试和生产的工作区时，会产生更多的组。 组的数量有可能增加三倍。 例如，对于数据工作区管理员，将有以下三个组：

  • Fabric 数据工作区管理员 – 季度财务[开发]
  • Fabric 数据工作区管理员 – 季度财务[测试]
  • Fabric 数据工作区管理员 – 季度财务

之前的示例旨在表明，使用映射到工作区角色的组很快就会变得难以管理。

提示

有时需要较少的组，特别是在开发中。 例如，可能不需要在开发中指定工作区查看者组；该组可能仅用于测试和生产。 或者，可以使用相同的工作区管理员组进行开发、测试和生产。 有关开发、测试和生产的详细信息，请参阅本文后面的工作区生命周期管理。

有效地使用工作区角色组需要相当多的计划。 当现有组（可能与组织结构图一致）不能满足管理 Fabric 内容的所有需求时，请做好应对方案的准备。 在这种情况下，建议专门为此目的创建组。 这就是上面显示的组名示例中包含Fabric或Power BI字样的原因。 如果有多个商业智能工具，可改为选择仅使用 BI 作为前缀。 这样，可以在多个工具中使用相同的组。

最后，这些示例显示了工作区“季度财务”，但通常可以使用一组组来管理工作区集合。 例如，财务团队拥有和管理的多个工作区可能能够使用相同的组。

注意

通常会更广泛地计划安全性，同时考虑语义模型读取和生成权限要求，以及行级别安全性 (RLS) 要求。 有关支持报表使用者和内容创建者的注意事项的详细信息，请参阅安全规划文章。 就本文而言，重点仅关注作为工作区计划过程一部分的工作区角色。

清单 - 考虑工作区访问权限时，关键决策和操作包括：

  • 参考角色和职责：使用之前准备的角色和职责信息来计划工作区角色。
  • 确定拥有和管理内容的人员：验证你希望存储在单个工作区中的所有项是否与负责拥有和管理内容的人员保持一致。 如果存在不匹配，请重新考虑如何更好地组织工作区。
  • 确定将在工作区中查看内容的人员：确定人们是否会直接从工作区查看内容。
  • 计划工作区角色：确定每个工作区的哪些人适合管理员、成员、参与者和查看者角色。
  • 确定组或个人角色分配：确定是否打算将个人用户或组分配给工作区角色。 检查是否存在可用于工作区角色分配的现有组。
  • 确定是否需要创建新组：仔细考虑是否需要为每个工作区角色创建一个新组。 请记住，这可能会导致创建和维护大量的组。 确定创建新工作区时的流程以及如何创建相关组。
  • 配置并测试工作区角色分配：验证用户在创建、编辑和查看内容时是否具有提高生产力所需的适当安全设置。

工作区域

如前文所述，明确工作区所有权至关重要。 在 Fabric 中进一步支持工作区所有权的一种方法是使用域。 域是一种以逻辑方式对具有相似特征的多个工作区进行分组的方法。

有关规划租户中的域的详细信息，请参阅工作区域。

工作区设置

可以为每个单独的工作区设置多个设置。 这些设置会显著影响协作的发生方式、允许访问工作区的人员以及跨 Fabric 工作负载的数据可重用性级别。

工作区许可模式

每个工作区都有一个许可证模式设置。 可将其设置为“Pro”、“Premium Per User”、“Premium 容量”、“嵌入版”、“Fabric 容量”或“试用版”。

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

许可证类型对于工作区计划很重要，因为它确定以下内容：

  • 功能：支持的不同功能。 PPU 包含专业版中不可用的更多功能（例如部署管道）。 更多的 Fabric 功能（例如，湖屋）可用于分配给 Fabric 容量的工作区。
  • 内容访问：许可证类型决定了谁可以访问工作区中的内容：
    • 只有拥有 PPU 许可证（以及分配有工作区角色）的用户才能访问 PPU 工作区。
    • 如果希望向拥有免费许可证的内容查看者提供内容，需要F64 或更高版本的许可证。
  • 数据存储位置：如果需要将数据存储在特定地理区域（主区域以外），可以通过将工作区分配给容量（相应地，在该区域创建容量）来实现这一点。 有关数据存储位置的详细信息，请参阅租户设置。

清单 - 考虑工作区许可证模式时，关键决策和操作包括：

  • 考虑每个工作区所需的功能：确定每个工作区的功能需求。 考虑工作负载的差异以及打算让其访问工作区的用户。
  • 设置工作区许可证模式：根据每个工作区所需的功能查看和更新每个工作区许可证模式。

工作区生命周期管理

当内容创建者协作交付对组织非常重要的分析解决方案时，存在各种生命周期管理注意事项。 这些过程也称为持续集成/持续交付 (CI/CD)，这是 DevOps 的一个方面。

多个生命周期管理注意事项包括：

  • 如何确保内容及时、可靠且一致地交付。
  • 如何在处理同一项目的多个内容创建者之间沟通和协调活动。
  • 当多个内容创建者在同一项目中编辑同一项时，如何解决冲突。
  • 如何构建简单可靠的部署过程。
  • 如何将部署的内容回滚到之前的稳定工作版本。
  • 如何在保护生产内容的同时平衡新功能的快速发布和 bug 修复。

在 Fabric 中，生命周期管理有两个主组件。

  • 内容的版本控制：Git 集成允许内容所有者和创建者创建其工作版本。 它可以与工作区中基于 Web 的开发结合使用，也可以在客户端工具（例如，Power BI Desktop）中开发时使用。 通过使用与Azure DevOps中的本地和远程存储库关联的分支以跟踪项目的所有修订来实现版本控制（也称为源代码管理）。 更改会定期提交到远程存储库中的分支。 当内容创建者完成经过测试和批准的修订后，其分支会与主远程存储库中的最新版本的解决方案合并（在解决任何合并冲突后）。 可以在 Fabric 门户中为每个工作区指定 Git 集成，前提是已在租户设置中启用该功能。
  • 推广内容：部署管道主要侧重于发布管理，以便为用户维护稳定环境。 可以将工作区分配到部署管道中的阶段（开发、测试或生产）。 然后，可以轻松、系统地将内容推广或部署到下一阶段。

在组合生命周期管理功能时，在规划过程中需要考虑最佳做法。 例如，可以选择将 Git 集成用于开发工作区和部署管道，从而发布到测试和生产工作区。 这些类型的决策需要一致地采用商定的做法。 建议进行概念证明，以全面测试设置、进程和权限模型。

清单 - 计划工作区生命周期管理时，关键决策和操作包括：

  • 确定用户需要使用版本控制的方式：分析自助式服务和高级内容创建者的工作方式，从而确定使用 OneDrive for Business 或 SharePoint 进行文件版本控制是否合适。 为需要更多功能的高级用户引入 Git 集成。 准备支持这两种类型的用户。
  • 确定用户需要推广内容的方式：分析自助式服务和高级内容创建者的工作方式，从而确定部署管道是否适合推广内容。
  • 确定是否应启用 Git 集成：考虑 Git 与工作区的集成是否适合内容创建者的工作方式。 设置用户可以将工作区项与其 Git 存储库同步租户设置，以符合此决策。 查看每个 Git 集成租户设置，并根据治理指南对其进行设置。
  • 执行概念证明：执行概念技术证明，以阐明打算如何让 Git 工作区和部署管道协同工作。
  • 确定哪些工作区应具有 Git 集成：考虑内容创建者的工作方式，以及应将哪些工作区分配给开发、测试或生产（发布）分支。
  • 验证许可证：确认有容量许可证可用于使用 Git 集成。 确保将每个工作区分配给 Fabric 容量或 Power BI Premium 容量。
  • 设置 Azure DevOps：与管理员协作，设置每个工作区所需的 Azure DevOps 项目、存储库和分支。 分配对每个存储库的适当访问权限。
  • 连接工作区：将每个工作区连接到相应的 Azure DevOps 存储库。
  • 考虑应将谁部署到生产环境：决策如何以及谁应能够更新生产内容。 确保这些决策与组织中工作区所有权的处理方式一致。
  • 培训内容创建者：确保所有内容创建者了解什么时候使用生命周期管理功能和做法。 向他们讲授工作流以及不同工作区如何影响生命周期管理过程。

工作区与 ADLS Gen2 集成

可以将工作区连接到 Azure Data Lake Storage Gen2 (ADLS Gen2) 帐户。 这样做的原因可能有两个：

  • Power BI 数据流数据的存储：如果选择自带数据湖，则可以直接在 Azure 中访问 Power BI 数据流(Gen1) 的数据。 希望其他用户或进程查看或访问数据时，直接访问 ADLS Gen2 中的数据流存储非常有用。 如果目标是重用 Power BI 之外的数据流数据，则会特别有用。 分配存储有两种选择：
    • 租户级存储，这在需要将 Power BI 数据流的所有数据集中到一个 ADLS Gen2 帐户中时非常有用。
    • 工作区级存储，这在业务单位管理其自己的数据湖或具有特定数据驻留要求时非常有用。
  • 备份和还原 Power BI 语义模型：分配给容量或 PPU 的工作区支持 Power BI 语义模型备份和还原功能。 此功能使用与存储 Power BI 数据流数据相同的 ADLS Gen2 帐户（如上一要点所述）。 语义模型备份有助于：
    • 遵守数据保留要求
    • 将例行备份存储为灾难恢复策略的一部分
    • 将备份存储在另一个区域
    • 迁移数据模型

重要

在 Fabric 管理门户中设置 Azure 连接并不意味着整个 Fabric 租户的所有数据流都默认存储到 ADLS Gen2 帐户。 若要使用显式存储帐户（而不是内部存储），必须显式连接每个工作区。 在工作区中创建任何 Power BI 数据流之前设置工作区 Azure 连接至关重要。

清单 - 考虑将工作区与 ADLS Gen2 集成时，关键决策和操作包括：

  • 决定是否以需要 Azure 存储的方式使用工作区：考虑自带数据湖方案是否对数据流的存储有用，且/或是否需要使用语义模型备份和恢复功能。
  • 确定将使用哪个 Azure 存储帐户：选择已启用分层命名空间的 Azure 存储帐户 (ADLS Gen2)，用于数据流数据或语义模型备份的租户级（集中式）存储。 确保拥有随时可用的 Azure 存储帐户信息。
  • 配置租户级存储帐户：在 Fabric 管理门户中，设置租户级 ADLS Gen2 存储帐户。
  • 决定工作区管理员是否可以连接存储帐户：进行讨论以了解分散式团队的需求，以及各个团队当前是否维护其自己的 Azure 存储帐户。 决定是否应启用此功能。
  • 为工作区级存储配置管理员设置：在 Fabric 管理门户中，启用允许工作区管理员连接其自己的存储帐户的选项。
  • 设置工作区级 Azure 存储连接：为每个单独的工作区指定 Azure 存储帐户。 在工作区中创建任何 Power BI 数据流之前，必须先设置存储帐户。 如果打算使用语义模型备份，请确保将工作区许可证模式设置为容量或 PPU。
  • 更新工作区管理文档：确保工作区管理文档包含有关如何正确分配 ADLS Gen2 存储帐户的信息。 在集中式门户和培训材料中提供信息。

工作区与 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 一起使用的详细信息，请参阅为 Power BI 配置 Azure Log Analytics。 请务必了解使集成正常运行必须具备的先决条件。

清单 - 考虑将工作区与 Azure Log Analytics 集成时，关键决策和操作包括：

  • 确定工作区管理员是否可以连接到 Log Analytics：确定是否允许所有或部分工作区管理员使用 Azure Log Analytics 分析工作区级日志。 如果访问权限仅限于某些人，请决定要使用的组。
  • 为 Log Analytics 连接设置租户设置：在 Fabric 管理门户中，根据工作区管理员设置连接的决策来设置租户设置。
  • 为每个工作区设置 Log Analytics 工作区：在 工作区设置中，为每个工作区指定 Azure Log Analytics 信息。 若要捕获工作区级日志，请确保将工作区许可证模式设置为容量或 PPU。
  • 更新工作区管理文档：确保工作区管理文档包含有关如何将工作区分配给 Azure Log Analytics 的信息。

其他工作区属性

有多个其他工作区属性可提供有用的信息。 对于受治理的工作区，建议设置这些属性。

以下是关于如何设置这些关键设置以改善用户体验的建议。

  • 工作区说明：好的工作区说明包含简短而具体的解释，说明可以在工作区中找到什么类型的内容。 最多可以使用 4000 个字符来说明：
    • 工作区的目的
    • 目标受众
    • 发布到工作区的内容类型
    • 工作区是否被认为是受治理的
    • 工作区是否包含开发、测试或生产数据
    • 如有任何问题，应联系谁（除了接下来描述的联系人列表外，有时尽可能突出显示此信息也很重要）
  • 工作区联系人：工作区联系人列表默认包括工作区管理员。 如果技术内容所有者与主题专家不同，可能会发现指定其他联系人很有帮助。 其他联系人可以是可以回答有关工作区内容的问题的组或个人。
  • 工作区图像：一致地使用工作区图像有助于用户扫描工作区列表。 考虑使用图像来帮助用户确定：
    • 域或主题区域
    • 哪个业务单位或团队拥有和管理内容
    • 是否是数据工作区（专用于存储可重用项的工作区，例如湖屋、仓库、数据管道、数据流或语义模型）
    • 是否是报告工作区（专用于存储分析项，例如报表、仪表板或指标）
  • 数据模型设置：允许对语义模型具有“生成”权限的工作区成员、管理员和用户使用 Web 界面编辑 Power BI 数据模型。 此设置与用户可以在 Power BI 服务中编辑数据模型租户设置结合使用。 此设置应与有关如何创建、管理和部署内容的决策和流程保持一致。 此外，请考虑前文所述的版本控制方法。

清单 - 考虑其他工作区属性时，关键决策和操作包括：

  • 指定工作区说明：确保工作区说明内容有用且全面。
  • 为工作区使用有用的图片：为工作区设置一致的图片，以直观地帮助用户了解其主题区域、谁拥有和管理工作区中的内容，和/或存储在工作区中的内容类型。
  • 确定工作区的联系人：验证工作区管理员是否应为工作区联系人，或者是否应指定特定用户或组。
  • 指定数据模型设置：考虑哪些工作区可以允许基于 Web 的数据模型编辑。 根据对谁可以编辑和管理内容的首选项，设置用户可以在 Power BI 服务中编辑数据模型租户设置。

其他技术因素

还有其他技术因素可能会影响工作区设置。

  • 如果将内容与其他工具和服务集成，可能会产生许可影响。 例如，如果在 Power BI 报表中嵌入 Power Apps 视觉对象，则需要相应的 Power Apps 许可证。
  • 每个工作区的存储限制适用于可存储在 Pro 工作区中的数据量。 如果不能选择使用容量 或 PPU，请考虑如何在工作区计划过程中在存储限制内工作。
  • 从 AppSource 安装模板应用时，将创建一个新的工作区，该工作区的主题和范围较窄。

清单 - 考虑其他技术因素时，关键决策和操作包括：

  • 注意技术因素：在完成计划过程时，确定是否存在可能影响决策过程的技术原因（例如每个工作区的存储限制）。
  • 重新组织工作区内容：如果存储限制可能造成问题，请立即创建单独的工作区并将内容重新发布到这些新工作区。

相关内容

有关有助于做出 Power BI 实现决策的更多注意事项、操作、决策标准和建议，请参阅 Power BI 实现计划。