Power BI 实施规划：工作区层面的管理

本文介绍在 工作区级别 为 Microsoft Fabric 工作区执行的战术实现规划，重点介绍 Fabric 中的 Power BI 体验。

本文主要适用于：

• 结构管理员：负责监督组织中的 Fabric 实现的管理员。
• 卓越中心（CoE）、IT 和商业智能（BI）团队：负责监督组织中数据和 BI 的使用以及在整个组织中支持自助服务用户的团队。
• 内容创建者和所有者：创建、发布和管理工作区中内容的自助服务用户。

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

工作区用途

规划工作区时，请务必不仅考虑它将存储的内容类型，而且考虑工作区旨在支持的活动。

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

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

考虑到这两个示例，请考虑工作区用途的两个特定方面： 协作意向 和 查看意向。

协作意向

Fabric 门户中工作区的主要目标是促进多个参与者之间的 协作 。

工作区中的协作以多种方式发生：

• 基于团队的开发：用户可以协同工作来生成、测试和发布内容。 一名用户可能参与Lakehouse的设计工作。 另一个用户可以处理语义模型的设计，其他用户可能专注于生成报表。
• 测试和验证：用户可能需要对新内容执行数据验证。 业务部门的主题专家可能需要执行用户验收测试（UAT）。 数据质量团队可能需要验证语义模型的准确性。
• 增强功能：内容利益干系人和使用者可能会建议在整个内容生命周期内增强内容。
• 所有权转让：其他人或团队可能承担其他人创建的内容 的责任 。

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

• 业务主导的自助服务 BI：内容创建者在业务单位或部门拥有或管理的内容。 在此方案中，工作区中的大多数协作发生在该业务部门的用户之间。
• 托管自助服务 BI：数据由集中式团队拥有或管理，但来自各业务部门的内容创建者负责报表和仪表板。 在此方案中，可能需要多个工作区才能安全地促进多个人员团队的协作。
• 企业 BI：集中式团队（如 IT、企业 BI 或 CoE 拥有或管理）的内容。 在此方案中，工作区中的协作工作发生在集中式团队中的用户之间。

在计划在工作区中的协作时的关键决策和行动清单：

内容查看意向

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

可以通过多种方式在 Power BI 服务中处理内容分发：

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

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

• 个人 BI：内容旨在供内容创建者使用。 由于与其他用户共享内容不是目标，因此个人 BI 将在个人工作区中完成，如下一部分所述。
• Team BI：内容与相对较少的、密切合作的同事共享。 在此方案中，大多数工作区都是非正式的协作工作区。
• 部门级BI：内容被分发给属于大型部门或业务单位的众多消费者。 在此方案中，工作区主要用于协作工作。 在部门 BI 方案中，内容通常在 Power BI 应用中查看，而不是直接在工作区中查看。
• 企业 BI：内容广泛地跨越组织边界，广泛传递给最多的目标消费者。 在此方案中，工作区主要用于协作工作。 对于企业 BI 方案，内容通常在 Power BI 应用中查看，而不是直接在工作区中查看。

在考虑如何查看工作区内容的预期时，关键决策和行动的清单：

适当使用个人工作区

可以从两种类型的工作区中进行选择：

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

用于学习 个人 BI、临时内容或测试以外的任何内容的个人工作区会增加组织的风险。 在个人工作区中，只有工作区所有者创建和管理内容。 个人工作区也不支持与他人协作。

为了让用户能够创建任意类型的 Fabric 项目，例如湖仓或数据仓库，必须将工作区添加到 Fabric 容量中。 此过程适用于标准工作区和个人工作区。 可以通过管理其容量分配来管理谁可以在个人工作区中创建特定类型的项目。

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

关键决策和行动的清单在考虑如何使用个人工作区的预期时：

有关详细信息，请参阅 Fabric 采用路线图：

• Fabric 集中式门户
• 织物培训
• Fabric 文档

工作区所有权

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

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

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

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

考虑工作区所有权责任时的关键决策和行动清单：

工作区组织

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

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

工作区主题和范围

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

在某些情况下，你可能已在 Microsoft Entra ID 中建立了一些有用的组。 可以使用组来管理对定义的主题区域和范围的资源的访问。 但是，可能需要创建新组才能完全实现此方法。 有关详细信息，请参阅 工作区访问。

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

如果为每个主题区域或项目创建一个工作区，则可以专注于工作区目的。 在工作区之间内容分发方面，此方法可以更加平衡。

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

选项 1 的优点包括：

• 管理用户访问权限（即哪些用户可以编辑或查看内容）更为简单，因为访问权限是根据特定主题区域限制的。
• 当跨组织边界的用户访问内容时，按主题区域构建工作区更加灵活且更易于管理，与接下来讨论的选项 2 相比。
• 每个主题区域一个范围是在包含过多项的工作区和包含过少项的工作区之间的良好妥协。

选项 1 的缺点是，根据定义窄或宽工作区的方式，仍可能会给创建过多工作区的用户造成风险。 当内容分布在多个工作区时，查找内容对用户来说可能具有挑战性。

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

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

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

下图描述了如何按部门、团队或主题区域分隔工作区的通用示例。 选项 1 和选项 2 看起来相同。 每个工作区中包含的项目取决于每个部门、团队或主题领域关注的数据的性质，以及他们打算如何使用数据。

选项 2 的优点包括：

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

选项 2 的缺点包括：

• 结果通常是一个范围广泛的工作区，其中包含大量项目。 定义范围较宽的工作区范围会使用户难以找到特定项。
• 由于工作区与 Power BI 应用之间存在一对一关系，因此定义较宽泛的工作区可能会导致用户的应用包含大量内容。 可以通过从应用和应用 导航设计中排除某些工作区项来缓解此问题。
• 当来自其他部门的用户需要查看特定的工作区项时，管理权限可能更为复杂。 一个风险是人们可能会认为部门工作区中的一切仅供他们查看。 另一个风险是，共享单个项而不是角色以实现细致的查看权限。
• 如果某些内容创建者需要权限来编辑部分但并非所有项目，则无法在单个工作区中设置这些权限。 工作区角色（用于确定编辑或查看权限）在工作区级别定义。
• 拥有大量工作区项时，通常需要对项使用严格的命名约定，以便用户可以找到所需的项。
• 包含许多项的宽泛工作区可能会遇到可存储在工作区中的项数的技术限制。

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

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

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

选项 3 的优点包括：

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

选项 3 的缺点包括：

• 如果过度使用，定义过于狭窄的工作区可能会导致大量工作区。
• 用户需要花更多精力来管理大量的工作区。 尽管用户可以依赖搜索，但在正确的工作区中查找正确的内容可能会令人沮丧。
• 更多的工作区会增加审核和管理工作负荷。

考虑工作区内容的主题区域和范围时的关键决策和行动的清单：

工作区项类型

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

• 数据工作区专用于存储和保护数据项，例如湖屋、仓库、数据管道、数据流或语义模型。
• 报表工作区更侧重于下游分析活动。 报表工作区仅存储和保护报表、仪表板和指标等项。 报告工作区通常包括 Power BI 内容，但这不是必需的。

在 Fabric 中，可以扩展此分隔，以便为其他项类型提供不同的工作区。

一些示例包括：

• 用于存储数据的数据仓库、Lakehouse 和 SQL 数据库的数据源工作区
• 用于数据管道、笔记本和数据流转换数据的数据转换工作区
• 用于向用户分发数据的记分卡、指标集和组织应用程序的分发工作区

下图描绘了如何按项类型分隔工作区的示例。

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

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

将数据工作区与报告工作区分离的缺点包括：

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

工作区开发阶段

一种常见做法是将单独的工作区用于内容开发的不同阶段。 通常，这种做法涉及以下阶段：

• 针对未测试变更的开发工作区
• 测试工作区 专用于内部和用户测试
• 用于发布使用者内容的生产工作区

在 Fabric 中，可以将每个阶段的工作区添加到部署管道。 部署管道通过让管道管理员在阶段之间比较和部署更改来帮助实现内容生命周期管理。 通常，首先将内容发布到最早阶段（如 开发），然后将其部署到下一阶段（例如将 开发 内容部署到 测试 工作区，然后从 测试 工作区部署到 生产 工作区）。

下面是此设置的示例：

还可以按开发阶段和项类型组合分隔工作区。 如果使用部署管道，可以使用 自动绑定 来确保阶段已链接。 自动绑定可确保报表 开发工作区 中的报表指向 模型开发工作区中的正确语义模型。

下面是一个示例：

（可选）你可能具有其他工作区，例如以下类型的工作区：

• 专用工作区 供创建者隔离工作。 使用此设置是使用 Git 集成协作处理内容的一种常见做法，因为每个内容创建者在内容各自的单独副本（分支）上工作，以避免彼此的工作中断。 然后，创建者可以打开拉取请求，将其更改合并到同步到开发工作区的另一个分支，创建者可以查看该工作区，但不能修改或发布内容。
• 创建者在发布内容之前执行特定测试的预生产工作区。 这些测试可能包括性能测试或支持资源（如数据网关和应用）的测试。
• 供创建者自由试验和进行即兴探索的沙盒工作区。 沙盒工作区通常会定期清空（通常是自动清空，例如使用 API 或笔记本来清空）。 创建者希望从沙盒工作区保留的内容可以复制到个人或专用工作区，以便进行更多开发。

按开发阶段分隔工作区的优点包括：

• 可以支持更复杂的结构化开发过程，包括：

  • 部署管道，用于在阶段之间复制内容
  • 用于部署和发布的 Git 集成和分支策略
  • 用于协调或自动执行内容生命周期中某些任务的笔记本

• 可以避免中断使用者使用的生产内容。

• 你对内容有更好的访问控制。

按开发阶段分隔工作区的缺点包括：

• 必须管理和管理更多工作区，从而产生更多的开销。
• 必须规划新的部署和部署后活动。
• 您可能需要考虑在开发阶段使用不被支持的工具或功能来进行内容部署或推广。
• 需要制定更复杂的工作区访问策略来防止创作者发布到错误的阶段以及使用错误的阶段。

工作区内部组织

除了组织工作区结构之外，还必须在单个工作区 中 组织内容。

若要更好地组织工作区中的内容，请考虑以下准则：

• 使用明确的命名约定轻松识别不同的内容。 请考虑使用数字前缀（如 01 - 每日销售额，根据需要按字母顺序订购内容）。
• 使用 任务流，根据工作流程中的用途将内容进行任务分类。 使用任务流有助于快速识别和选择类似内容（通过在任务流中选择任务）。 如果决定在同一工作区中包含具有不同用途的许多项类型，这一点很重要。
• 使用工作区文件夹将类似内容组织到组中。 工作区文件夹可以代替任务流中的任务，也可以将其添加到任务流中。
• 使用认可和敏感度标签根据认可和敏感度状态适当地标记内容。

关键决策和操作的清单，当你考虑用户可以在工作区中存储的项类型时：

工作区访问权限

由于工作区的主要用途是协作，工作区访问权限主要适用于创建和管理工作区内容的用户。 当在工作区用于查看内容时，访问权限也可能很重要。 此用途是工作区的辅助用途，如本文前面所述。

开始规划 工作区角色时，考虑以下问题会很有帮助：

• 工作区中如何进行协作？
• 使用者是否会直接查看工作区中的内容？
• 谁负责管理工作区中的内容？
• 谁可以查看存储在工作区中的内容？
• 您是否打算将个体用户或群组分配到工作区角色？

最佳做法是使用组分配工作空间角色。 工作区角色支持安全组、已启用邮件的安全组、通讯组和 Microsoft 365 组。 有关使用安全组的详细信息，请参阅租户级安全性计划。

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

• Fabric 工作区管理员 – 季度财务
• Fabric 工作区 成员 – 季度财务报告
• Fabric 工作区 贡献者 – 季度财务报告
• Fabric 工作区查看者 – 季度财务
• Power BI 应用查看者 – 季度财务

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

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

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

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

前面的示例旨在传达映射到工作区角色的组的使用可以快速变得不可管理。

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

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

考虑工作区访问时，关键决策和行动的清单：

工作空间域

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

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

工作区设置

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

工作区许可模式

每个工作区都有一个许可证模式设置。 可以将工作区许可证模式设置为 Pro、 Premium per user、 Premium 容量、 Embedded、 Fabric 容量或 试用版。

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

• 功能：支持不同的功能。 PPU 包含专业版中不可用的更多功能（例如部署管道）。 更多的 Fabric 功能（例如，湖屋）可用于分配给 Fabric 容量的工作区。

• 内容访问：许可证类型确定谁可以访问工作区中的内容：

  • 只有拥有 PPU 许可证（以及分配有工作区角色）的用户才能访问 PPU 工作区。
  • 如果希望向具有免费许可证的内容查看器提供内容，则需要 F64 或更高版本的许可证。

• 数据存储位置：当需要将数据存储在特定地理区域（位于主区域外部）时，可以使用分配给容量的工作区（相应地，在该区域中创建容量）。 有关数据存储位置的详细信息，请参阅租户设置。

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

工作区生命周期管理

当内容创建者协作提供对组织非常重要的分析解决方案时，必须做出各种 生命周期管理 决策。 生命周期管理过程也称为 持续集成/持续交付（CI/CD），它们是 DevOps 的一个方面。

生命周期管理 注意事项包括如何：

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

Fabric 有两个主要生命周期管理组件：

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

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

规划工作区生命周期管理时的关键决策和行动清单：

工作区与 Data Lake Storage Gen2 的集成

可以将工作区连接到 Azure Data Lake Storage Gen2 帐户。 出于两个原因，可能采用此方法：

• Power BI 数据流数据的存储：如果选择自带数据湖，可以直接在 Azure 中访问 Power BI 数据流（Gen1）的数据。 如果希望其他用户或进程查看或访问数据，则可以直接访问 Data Lake Storage Gen2 中的数据流存储 。 如果目标是重用 Power BI 之外的数据流数据，则会特别有用。 有两种用于分配存储的选项：

  • 租户级存储，当你想要将 Power BI 数据流的所有数据集中到一个 Data Lake Storage Gen2 帐户时，这非常有用。
  • 工作区级存储，这在业务单位管理其自己的数据湖或具有特定数据驻留要求时非常有用。

• 备份和还原 Power BI 语义模型：分配给容量或 PPU 的工作区支持 Power BI 语义模型备份和还原功能。 此功能使用相同的 Data Lake Storage Gen2 帐户来存储 Power BI 数据流数据（如上一项目符号中所述）。 语义模型备份有助于：

  • 遵守数据保留要求
  • 将例行备份存储为灾难恢复策略的一部分
  • 将备份存储在另一个区域
  • 迁移数据模型

规划工作区与 Data Lake Storage Gen2 集成时的关键决策和操作清单：

工作区与 Log Analytics 的集成

Log Analytics 是 Azure Monitor 的一项功能。 可以使用 Log Analytics 查看 Analysis Services 引擎生成的诊断数据，该引擎托管 Power BI 语义模型。 工作区级日志对于分析性能和趋势、执行数据刷新分析、分析 XMLA 终结点操作等非常有用。 Log Analytics 功能仅适用于分配给容量或 PPU 的工作区。

有关语义模型事件日志的详细信息，请参阅数据级审核。

有关如何设置 Log Analytics 以用于 Power BI 的详细信息，请参阅 配置 Power BI 的 Log Analytics。 请务必了解必须具备的先决条件才能实现集成。

规划工作区与 Log Analytics 集成时的关键决策和行动检查列表：

其他工作区属性

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

下面是有关如何设置密钥设置以提高用户体验的一些建议：

• 工作区说明：良好的工作区说明包括工作区中内容类型的简短但具体说明。 最多可以使用 4,000 个字符来描述：

  • 工作区的目的
  • 目标受众
  • 发布到工作区的内容类型
  • 工作区是否被认为是受治理的
  • 工作区是否包含开发、测试或生产数据
  • 对于问题或支持，请联系相关人员

• 工作区联系人：工作区联系人列表默认包括工作区管理员。 如果技术内容所有者与主题专家不同，可能会发现指定其他联系人很有帮助。 其他联系人可以是可以回答有关工作区内容的问题的组或个人。

• 工作区映像：扫描工作区列表时，工作区映像的一致使用对用户有帮助。

  请考虑使用图像来帮助用户识别：

  • 域或主题区域
  • 拥有和管理内容的业务部门或团队
  • 专门用于存储可重用项的数据工作区，例如数据湖仓库、仓库、数据管道、数据流或语义模型
  • 专用于存储分析项（如报表、仪表板或指标）的报告工作区

• 数据模型设置：允许具有语义模型的“生成”权限的工作区成员、管理员和用户使用 Web 界面编辑 Power BI 数据模型。 此设置与 用户可以在 Power BI 服务租户设置中编辑数据模型 一起使用。 此设置应与有关如何创建、管理和部署内容的决策和流程保持一致。 此外，请考虑使用 版本控制 的方法，如前所述。

清单：在考虑其他工作区属性时的关键决策和行动。

其他技术因素

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

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

考虑其他技术因素时的关键决策和行动的清单：

相关内容

有关更多注意事项、行动、决策标准和建议，以帮助您做出有关 Power BI 实现决策，请参阅：

• Power BI 实现规划简介