Power BI 使用方案：托管的自助式 BI

备注

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

如 Fabric 采用路线图中所述，托管的自助式 BI 以混合方法为特征，强调“核心的约束性”和“边缘的灵活性”。 数据体系结构通常由一组集中的 BI 专家维护，而报告则由部门或业务单位内的创建者负责。

通常，报表创建者比语义模型（以前称为数据集）创建者多得多。 这些报表创建者可能身处组织中的任何区域。 由于自助式报表创建者通常需要快速生成内容，因此混合方法使他们能够专注于生成支持及时决策的报表，而无需付出额外的精力创建语义模型。

注意

托管的自助式 BI 方案是自助式 BI 方案中的第一种。 有关自助式 BI 方案的完整列表，请参阅 Power BI 使用方案一文。

为简洁起见，本文未介绍内容协作和交付方案主题中所述的某些方面。 若要了解完整信息，请先阅读这些文章。

方案示意图

下图简要概述了支持托管的自助式 BI 的最常见用户操作和 Power BI 组件。 主要目标是让许多报表创建者重用集中式共享语义模型。 为实现此目标，此方案注重于将模型开发过程与报表创建过程分离。

提示

如果想要将方案图嵌入演示文稿、文档或博客文章，或者将其打印为墙上海报，建议下载方案图。 由于它是可缩放矢量图形 (SVG) 图像，因此可以放大或缩小它，而不会造成任何质量损失。

该方案图描绘了以下用户操作、工具和功能：

项目	描述
	语义模型创建者使用 Power BI Desktop 开发模型。 对于旨在供重复使用的语义模型，创建者通常（但非必需）属于跨组织边界支持用户的集中式团队（例如 IT、企业 BI 或卓越中心）。
	Power BI Desktop 连接到一个或多个数据源中的数据。
	数据模型开发是在 Power BI Desktop 中进行的。 需要付出额外的精力创建设计良好且用户友好的模型，因为许多自助式报表创建者可能会将该模型用作数据源。 模型创建者可以使用 DAX 查询在开发期间开发和探索模型。
	准备就绪后，语义模型创建者将其仅包含模型的 Power BI Desktop 文件 (.pbix) 或 Power BI 项目文件 (.pbip) 发布到 Power BI 服务。
	将语义模型发布到专门用于存储和保护共享语义模型的工作区。 由于该语义模型旨在用于重复使用，因此，它经过认可（经过认证或经过提升，视情况而定）。 该语义模型还被标记为可发现，以进一步支持重复使用。 Power BI 服务中的世系视图可用于跟踪 Power BI 项之间存在的依赖关系，包括连接到语义模型的报表。
	OneLake 数据中心中的语义模型发现已启用，因为语义模型被标记为可发现。 借助可发现性，寻找数据的其他 Power BI 内容创建者可在数据中心查看语义模型。
	报表创建者使用 Power BI 服务中的 OneLake 数据中心来搜索可发现的数据项，例如语义模型。
	如果报表创建者没有权限，他们可以请求对数据项的生成权限。 这会启动一个工作流，向已获授权的审批者请求生成权限。 获批后，报表创建者可以重复使用数据项来创建新报表。
	报表创建者使用 Power BI Desktop 创建新报表。 报表使用与共享语义模型的实时连接。
	报表创建者在 Power BI Desktop 中开发报表。 除了报表，报表创建者还可以使用主题、图像和自定义视觉对象，并且可以创建报表级度量值。
	准备就绪后，报表创建者将其 Power BI Desktop 文件发布到 Power BI 服务。
	将报表发布到专门用于存储和保护报表和仪表板的工作区。
	已发布的报表保持连接到不同工作区中存储的共享语义模型。 对共享语义模型的任何更改都将影响与它连接的所有报表。
	其他自助式报表创建者可以使用现有的共享语义模型创作新报表。 报表创建者可以选择使用 Power BI Desktop、Power BI 报表生成器或 Excel。
	某些数据源（例如驻留在专用组织网络中的数据源）可能需要本地数据网关或 VNet 网关来进行数据刷新。
	Power BI 管理员监督和监视 Power BI 服务中的活动。

要点

下面是对于托管的自助式 BI 方案需要强调的一些要点。

共享语义模型

要使托管的自助式 BI 发挥作用，关键的一点是尽量减少语义模型的数量。 此方案与帮助实现“单一事实版本”理念的共享语义模型相关。

注意

为简单起见，方案图中仅描绘了一个共享语义模型。 但是，在单个语义模型中为所有组织数据建模通常是不切实际的。 另一种极端做法是为每个报表创建一个新的语义模型，而经验不足的内容创建者经常采用这种做法。 托管的自助式 BI 的目的是找到适当的平衡，并倾向于创建相对较少的语义模型，并在有意义的情况下才创建新的语义模型。

分离语义模型和报表

将语义模型与报表分离有利于实现任务和职责的分离。 共享语义模型通常由集中式团队（例如 IT、BI 或卓越中心）维护，而报表则由业务单位中的主题专家维护。 但不一定非要如此。 例如，任何想要实现可重用性的内容创建者都可以采用这种模式。

注意

为简单起见，方案图中未描绘数据流。 若要了解数据流，请参阅自助数据准备方案。

语义模型认可

由于共享语义模型预期可重复使用，因此认可它们会有所帮助。 已认证的语义模型向报表创建者传达数据值得信任并符合组织的质量标准这一信息。 提升的语义模型强调语义模型所有者认为数据有价值并值得其他人使用。

提示

最佳做法是制定一致、可重复且严格的内容认可流程。 认证内容应表明数据质量已经过验证。 它还应遵循变更管理规则，获得正式支持并有全面的文档阐述。 由于认证内容已达到严格的标准，因此对可信度的期望更高。

语义模型发现

OneLake 数据中心可帮助报表创建者在整个组织中查找、浏览和使用语义模型。 除了语义模型认可外，启用语义模型发现对于促进语义模型的重复使用同样至关重要。 需要搜索数据的报表创建者可以在数据中心看到可发现的语义模型。

注意

如果未将某个语义模型配置为可发现，则只有拥有生成权限的 Power BI 用户才能找到该语义模型。

请求语义模型访问

报表创建者可能会在数据中心找到他们想要使用的语义模型。 如果没有对语义模型的构建权限，他们可以请求访问权限。 根据语义模型的请求访问权限设置，会向语义模型所有者提交一封电子邮件，或者向请求访问权限的人员提供自定义说明。

实时连接共享语义模型

Power BI Desktop 实时连接会将报表连接到现有语义模型。 实时连接避免了在 Power BI Desktop 文件中创建新数据模型的需要。

重要

使用实时连接时，报表创建者所需的所有数据必须驻留在连接的语义模型中。 但是，可自定义的托管自助式 BI 方案介绍了如何使用其他数据和计算来扩展语义模型。

发布到不同的工作区

将报表发布到不同于语义模型存储位置的工作区可带来诸多优势。

首先，可以明确地知道谁负责管理哪个工作区中的内容。 其次，报表创建者有权将内容发布到报告工作区（通过工作区管理员、成员或参与者角色）。 但是，他们只对特定的语义模型拥有读取和构建权限。 通过这种技术，可以在有必要对分配到查看者角色的用户实施行级安全性 (RLS) 时使 RLS 生效。

重要

将 Power BI Desktop 报表发布到工作区时，RLS 角色将应用于分配到工作区中查看者角色的成员。 即使查看者对语义模型拥有构建权限，也仍会应用 RLS。 有关详细信息，请参阅在 Power BI 中对工作区使用 RLS。

依赖项和影响分析

当许多报表使用某个共享语义模型时，这些报表可以存在于许多工作区中。 世系视图可帮助识别和了解下游依赖项。 在规划语义模型更改时，请先执行影响分析，以了解哪些依赖的报表可能需要进行编辑或测试。

网关设置

通常，在访问驻留在专用组织网络或虚拟网络中的数据源时需要一个数据网关。 将 Power BI Desktop 文件发布到 Power BI 服务后，本地数据网关就会与此相关。 网关的两个作用是刷新导入的数据，或查看查询实时连接或 DirectQuery 语义模型的报表。

注意

对于托管的自助式 BI 方案，强烈建议使用标准模式的集中式数据网关，而不是个人模式的网关。 在标准模式下，数据网关支持实时连接和 DirectQuery 操作（此外还支持计划的数据刷新操作）。

系统监督

活动日志记录 Power BI 服务中发生的用户活动。 Power BI 管理员可以使用收集的活动日志数据来执行审核，以帮助他们了解使用模式和采用情况。 在支持治理工作、安全审核和合规性要求方面，活动日志也很有作用。 对于托管的自助式 BI 方案，跟踪共享语义模型的使用情况特别有帮助。 高报表与语义模型比率表示语义模型的重复使用良好。

相关内容

在本系列的下一篇文章中，了解根据其他类型的要求自定义和扩展共享语义模型的方法。