通过

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 服务中创建工作区的决策是一项数据区域性和治理决策。 通常，可通过两种方法来处理此决策：

  • 允许所有（或大多数）用户创建新工作区：此方法通常与其他应用程序的现有决策保持一致。 例如，当允许用户创建其自己的 SharePoint 网站或 Teams 频道时，Fabric采用相同的策略是合理的。
  • 仅限所选的一组用户可以创建新工作区：此方法通常表示治理计划已就绪或在计划中。 可以完全集中管理此过程（例如，仅允许 IT 创建工作区）。 一种更灵活、更实用的做法是将集中式人员和分散型人员进行组合。 在这种情况下，卓越中心 (COE) 的成员、支持者或受信任的用户的某些卫星成员已接受培训，可代表其业务部门创建和管理工作区。

你应根据允许谁创建工作区的决策，在Fabric 管理门户中设置创建工作区租户设置。 有关详细信息，请参阅治理工作区。

清单 - 考虑向谁授予创建工作区的权限时，关键决策和操作包括：

  • 确定并验证用户需求：安排与相关利益干系人和相关各方的协作讨论，了解用户当前的工作方式。 目标是确保你已明确了解用户需求。
  • 确定允许谁创建工作区：确定是允许所有用户、仅集中式团队，还是某些集中式和分散型用户创建新工作区。 确保此决策有意与数据区域性目标保持一致。 请务必获得执行发起人的批准。
  • 为允许创建工作区的人员创建安全组：如果允许一小部分用户创建工作区，则需要安全组。 清楚地命名该组，例如 Fabric 工作区创建者。 将允许创建工作区的成员添加到此安全组。
  • 更新租户设置：将新的安全组添加到管理门户中的“创建工作区”租户设置。 除了“Fabric 工作区创建者”组之外，可能还允许添加到此租户设置的其他组是 COE、支持和 Fabric 管理员。

工作区命名约定

工作区命名约定是一种关于如何命名工作区的商定模式。 通常，命名约定更像是一种要求，而不是一项建议。

当许多用户有权创建工作区时，很难严格强制执行命名约定。 你可以通过用户教育和培训来解决此问题。 还可以执行审核过程来查找不符合命名约定的工作区。

工作区名称可以传达有关工作区的其他信息，包括：

  • 用途：工作区名称应始终包含对其内容的描述。 例如，销售季度奖金跟踪。
  • 项类型：工作区名称可以包括对它包含的项类型的引用。 例如，使用“销售数据”来指示工作区存储项目，例如湖屋或语义模型（以前被称为数据集）。 销售分析 可以指示工作区存储分析报表和仪表板。
  • 阶段（环境）：工作区名称可能包含其阶段。 例如，通常会使用单独的工作区来存储开发、测试和生产以进行生命周期管理。
  • 所有权和职责：工作区名称可能包括负责管理内容的人员的指示。 例如，使用“SLS”前缀或后缀可以指示销售团队拥有和管理内容。

提示

为了使工作区名称保持简短，可以在工作区说明中包含其他详细信息。 但是，请确保工作区名称包含最相关的信息，尤其是在你预计用户将搜索工作区的情况下。 还可以使用工作区映像来扩充工作区名称。 下一篇文章的工作区设置部分将进一步介绍这些注意事项。

保持工作区名称一致对每个人都有益。 用户体验会得到改进，因为用户可以更轻松地查找内容。 此外，在使用可预测命名约定时，管理员可以更轻松地监视内容。

建议将工作区命名约定添加到集中式门户和培训材料中。

以下列表介绍了与工作区命名相关的更多注意事项。

  • 使用简短但具有描述性的名称：工作区名称应准确反映其内容，最重要的部分位于名称的开头。 在 Fabric 门户服务中，较长的工作区名称在用户界面中可能会被截断，需要用户将光标悬停在工作区名称上才能在工具提示中显示全名。 下面是简短但具有描述性的名称示例：季度财务。
  • 使用标准前缀：标准前缀可以在排序时将类似的工作区排列在一起。 例如：FIN-季度财务。
  • 使用标准后缀：可为其他信息添加后缀，例如当你使用不同的工作区存储开发、测试和生产内容时。 建议追加 [开发] 或 [测试] 后缀，但将生产工作区保留为不带后缀的用户友好名称。 例如：FIN-季度财务 [开发]。
  • 与 Power BI 应用名称保持一致：工作区名称及其 Power BI 应用可能有所不同，尤其是在为应用使用者提高可用性或可理解性时。 我们建议使名称保持相似，以避免混淆。
  • 省略不必要的字词：以下字词可能是多余的，因此请避免在工作区名称中使用这些字词：
    • “工作区”一词。
    • 单词 Fabric 或 Power BI。 许多 Fabric 工作区包含来自各种工作负载的项。 但是，可以创建一个仅面向特定工作负荷的工作区（例如 Power BI、数据工厂 或 Synapse 数据工程）。 在这种情况下，可以选择一个短后缀，以便明确工作区用途。
    • 组织名称。 但是，当主要受众是外部用户时，包含组织名称可能会有所帮助。

注意

建议在工作区名称将发生更改时通知用户。 在大多数情况下，可以安全地在 Fabric 门户中重命名工作区，因为工作区的唯一标识符 GroupID（可在工作区 URL 中找到）不会发生更改。 但是，XMLA 连接会受到影响，因为它们使用工作区名称而不是 GroupID 进行连接。

清单 - 考虑创建工作区命名约定时，关键决策和操作包括：

  • 确定工作区名称的要求或首选项：考虑如何命名工作区。 确定是需要严格的命名约定要求还是以建议和示例为指导的更灵活的要求。
  • 查看现有工作区名称：根据需要更新现有工作区名称，使其成为用户能够遵循的良好示例。 当用户看到对现有工作区进行重命名时，他们会将其理解为要采用的隐含标准。
  • 为工作区命名约定创建文档：提供有关工作区命名约定要求和首选项的参考文档。 请务必包含展示正确使用首字母缩略词、前缀和后缀的示例。 在集中式门户和培训材料中提供此信息。

工作区域

明确内容的拥有和管理方式始终至关重要。 当创建和管理数据资产的职责分散到多个部门或业务部门时，这种明确性尤其重要。 有时，此方法称为分布式、联合式或数据网格体系结构。

在 Fabric 中支持工作区所有权和管理的一种方法是使用域。 域是一种以逻辑方式对具有相似特征的多个工作区进行分组的方法。 例如，可以创建域以将所有销售工作区组合在一起，并为财务工作区创建另一个域。

以下是使用域的主要优势。

  • 它们将类似的工作区分组到单个管理边界中。
  • 它们允许在域级别管理某些租户设置。 有关详细信息，请参阅替代租户级设置。
  • 它们可帮助用户查找相关数据。 例如，它们可以在 OneLake 数据中心使用筛选器。

下表列出了可用于选择组织相关工作区的不同方式。

用于组织工作区的方法 示例域
按主题区域/域/内容类型 财务域包括与财务内容相关的每个工作区。
按拥有和管理内容的团队/部门 企业 BI域包括团队直接负责管理的所有工作区。
按组织业务部门细分市场 欧洲分区域包括与欧洲运营直接相关的所有工作区。
按项目 子公司收购域包括高度敏感项目的所有工作区。

下面是在租户中规划 Fabric 域时的一些注意事项。

  • 如何将每个工作区映射到域？ 每个工作区只能分配给一个域（而不是多个域），因此请准备好进行一些规划。 考虑创建一个矩阵图，其中行为工作区，列为域，以帮助你规划它们的分配方式。 如果发现需要重新组织工作区，可以在工作区设置或管理门户中重新分配域。
  • 谁有权管理域？ 域管理员角色的成员有权管理现有域。 如果可能，请分配直接拥有和管理域内容的域管理员。 域管理员应是熟悉主题领域的内部、区域和政府法规的专家。 他们还应该熟悉所有内部治理和安全要求。 有关详细信息，请参阅域角色。
  • 谁可以将工作区分配给域？ 域参与者角色的成员定义哪些用户（同时也是工作区管理员）可以将工作区分配给域。 如果允许更多用户将工作区分配给域，则应经常审核分配的分组的准确性。 如果只允许特定用户组或 Fabric 管理员和域管理员，则可以更好地控制进行分配的方式。 有关详细信息，请参阅域角色。
  • 是否存在特定的合规性需求或限制，例如地理区域？ 请记住，数据存储的地理区域为每个容量（而不是为域）设置。 考虑将工作区分配给域和容量对规划过程有何影响。

有关详细信息，请参阅治理域。

清单 - 计划工作区域时，关键决策和操作包括：

  • 验证内容所有权的工作原理：确保深入了解整个组织中内容所有权和管理的发生方式。 将信息纳入计划，以便将工作区组织到域中。
  • 规划工作区域：讨论规划如何以最佳方式将工作区组织到域中。 与卓越中心以及执行发起人确认所有关键决策。
  • 培训 Fabric 管理员：确保租户管理员熟悉如何创建域以及如何分配和管理域管理员。
  • 培训域管理员：确保域管理员了解对于此角色在管理域方面的期望。
  • 确定如何处理域参与者：考虑哪些用户应有权将工作区分配给域。
  • 创建审核过程：定期验证分配的域分组是否正确。

工作区创建过程

如果你已决定限制谁可以创建工作区，则更广泛的用户群体需要了解请求新工作区的过程。 在这种情况下，建立一个便于用户查找和遵循的请求过程非常重要。

快速响应针对新工作区的请求也至关重要。 2-4 小时的服务级别协议 (SLA) 比较理想。 如果请求新工作区的过程太慢或过于麻烦，用户将使用他们拥有的工作区，这样他们就能够继续操作。 如果他们选择跳过创建新工作区，那么他们使用的工作区可能不是最佳选择。 他们可能会选择重复使用不适合新内容的现有工作区，或者可能共享来自其个人工作区的内容。

提示

创建新过程的目标是让用户能够轻松遵循该过程。 与所有数据治理决策一样，关键是让用户轻松执行正确的操作。

下表列出了在请求新工作区试要收集的信息。

所需信息 示例 需要验证
工作区名称 SLS-区域销售分析 • 名称是否遵循命名约定？

• 是否存在具有相同名称的其他工作区？
所需的阶段 SLS-现场销售分析 [开发]、SLS-现场销售分析 [测试] 和 SLS-现场销售分析 • 是否需要多个工作区才能为内容提供适当的支持？

• 如果是，是否还应创建部署管道？
说明 用于每月、每季度和每年分析的客户销售和订单历史记录。 • 是否期望存储敏感数据或监管数据？

• 如果是，这是否将影响工作区的治理方式？
目标读者 全球现场销售组织 • 内容传递范围有多广泛？

• 这将如何影响工作区的治理方式？
分配给工作区的许可证模式 销售团队需要 Fabric 容量，因为许多销售人员只是查看者，并且他们拥有免费许可证 • 需要哪种级别的 Fabric 容量？
数据存储要求 加拿大的数据驻留 • 是否存在需要多地理位置的数据驻留需求？

• 预期的数据量是多少？
工作区管理员 FabricContentAdmins-FieldSalesAnalytics • 管理员（最好）是一个组吗？

• 是否至少有两名管理员？
提交请求的人员 requestor@contoso.com • 提交请求的人员是否担任与所提供信息相关的角色或从事相关业务？

上表包含设置工作区所需的最少信息量。 但是，它不包括所有可能的配置。 在大多数情况下，工作区管理员将在创建工作区后负责完成设置。 有关详细信息，请参阅工作区级别设置一文。

有许多技术选项可供你用于为工作区创建请求创建联机表单。 请考虑使用 Microsoft Power Apps，这是一种低代码软件选项，非常适合用于生成简单的基于 Web 的表单和应用程序。 你选择使用哪种技术来创建基于 Web 的表单取决于谁将负责创建和维护表单。

提示

若要提高效率和准确性，请考虑使用 Power BI REST API 以编程方式创建或更新工作区来自动执行该过程。 在这种情况下，建议包括评审和审批流程，而不是自动处理每个请求。

清单 - 考虑请求新工作区的过程时，关键决策和操作包括：

  • 建立请求新工作区的过程：确定请求新工作区的特定过程。 请考虑所需的信息、捕获信息的方式以及处理请求的人员。
  • 创建用于请求新工作区的标准表单：确定将在用于请求新工作区的表单上包含哪些信息。 请考虑构建 Power Apps 应用，以从用户处收集信息。 确保表单的链接广泛可用，并且易于在集中式门户和其他常见位置中找到。 还需在正在进行的通信中包含表单的链接。
  • 确定谁将响应提交的请求以及响应速度：确定谁将处理请求。 考虑处理新工作区请求的预期响应时间。 验证你是否可以快速处理请求，以便自助服务用户不会遇到延迟。
  • 进行知识传输会话：如果另一个团队将支持工作区请求过程，请与他们进行知识传输会话，以便他们获得所需的全部信息。
  • 创建有关如何批准或拒绝请求的文档：创建有关如何批准请求的文档，此文档面向将评审或处理请求的人员。 此外，还需包括请求可能被拒绝的原因，以及应采取的操作。
  • 创建有关如何请求工作区的文档：创建有关如何请求新工作区的文档，此文档面向无法创建其自己的工作区的用户。 需包括所需的信息以及对响应的预期。 确保在集中式门户和培训材料中提供此信息。

工作区治理级别

并非所有工作区都需要相同级别的监督。 某些工作区可能被视为“受治理”。 受治理的工作区意味着对其内容有更多的要求和期望。 某些组织使用“受管理”一词，而不是“受治理”。

有四个用于确定治理级别的关键决策标准：

  • BI 内容由谁拥有和管理？
  • BI 内容交付的范围。
  • 什么是数据主体区域？
  • 是否将数据和/或 BI 解决方案视为重要内容？

注意

有关四个关键决策标准的详细信息，请参阅构成 Fabric 采用路线图一部分的治理一文。

你可以从两个级别的工作区入手：受治理和不受治理。 建议尽可能使治理级别保持简单。 但是，根据具体情况，你可能需要细分受治理分类。 例如，由企业 BI 团队管理的重要内容可能具有一组治理要求。 而由业务部门直接拥有和管理的重要内容可能要符合一组略有不同的要求。 在某些情况下，会针对各个业务部门专门制定决策。

下表列出了将工作区视为受治理时的一些最常见要求。

类别 潜在的治理要求
所有权和支持 • 为技术内容所有者和/或行业专家分配明确的职责时分配所有权。

• 分配用户支持团队/人员，并且用户了解如何请求帮助或提交问题。

• 提供一种用于用户反馈、问题和增强请求的机制。

• 有一个沟通计划用于宣布对工作区中内容的重要更改。
工作区设置 • 工作区组织得井然有序，目标明确。

• 使用特定的命名约定。

• 工作区分配给特定域。

• 工作区说明、映像和联系人是必需的。
精确度 • 所有内容都经过认证。

• 数据验证是自动化的，以便内容所有者能够及时了解数据质量问题。
分布 • Power BI 应用用于分发报表和仪表板。
安全性和数据保护 • 使用 安全组（而不是单个帐户）管理工作区角色。

• 使用敏感度标签进行信息保护。

• 仅允许已批准的数据源。

• 所有源文件都驻留在备份的安全位置。
更改管理 • 使用单独的开发、测试和生产工作区。

•源代码管理（例如 Git 集成）用于 Fabric 门户中的所有 Power BI Desktop 文件和项。

• 所有数据源文件都使用版本控制或源控制。

• 生命周期管理和更改管理过程，包括部署管道和/或 DevOps 过程，都会得到遵循。
容量 • 工作区分配到相应的 Fabric 容量级别。

• Fabric 容量受到管理和监视。
网关 • 使用处于标准模式（非个人模式）下的数据网关。

• 所有网关数据源凭据都使用已批准的凭据。
审核和监视 • 为跟踪采用情况、使用模式和性能，已制定了主动审核和监视流程。

提示

治理要求通常不是可选的。 因此，及时审核很重要，并且在某些情况下，有必要强制执行。 例如，如果受治理的工作区要求将所有文件都放在一个安全位置，但审核期间检测到未批准的文件位置，则应采取措施更新文件位置。

清单 - 考虑工作区治理级别时，关键决策和操作包括：

  • 确定工作区治理级别：确定所需的治理级别。 尽可能使其保持简单。
  • 确定如何对工作区进行分类的标准：确定将工作区分类到特定治理级别的决策标准。
  • 确定工作区治理要求：对于每个治理级别，确定具体要求。
  • 确定如何指定工作区治理级别：找到用于确定工作区治理级别的最简单方法。 你可以将它记录为名称的一部分、说明的一部分或将它存储在其他位置（例如包含有关每个工作区的详细信息的 SharePoint 列表）。
  • 创建有关工作区治理要求的文档：创建面向内容创建者的有用文档，其中包括他们在管理受治理工作空间中的内容方面的职责。 在集中式门户和培训材料中提供此信息。
  • 创建工作区审核过程：对于被视为受治理的工作区，请创建审核过程来识别不符合最重要的要求的区域。 确保有人负责联系内容所有者以解决合规性问题。

相关内容

在本系列的下一篇文章中，了解工作区级别计划。