通过

Power BI 实现规划：数据级审核

  • 项目

备注

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

这篇关于数据级审核的文章面向多种受众：

  • 数据创建者和工作区管理员： 需要了解其创建、发布和共享的语义模型、数据流和数据市场使用情况、采用和性能的用户。
  • Power BI 管理员：负责监督组织的 Power BI 的管理员。 Power BI 管理员可能需要与 IT、安全、内部审核和其他相关团队协作。 对性能进行故障排除时，Power BI 管理员可能还需要与内容创建者协作。
  • Power BI 容量管理员：这些管理员负责监督组织中的 Premium 容量。 对性能进行故障排除时，Power BI 容量管理员可能需要与内容创建者协作。
  • 卓越中心、IT 和 BI 团队：还负责监督 Power BI 的团队。 他们可能需要与 Power BI 管理员和其他相关团队协作。
  • 系统管理员：负责创建和保护 Azure Log Analytics 资源的团队，以及管理数据源的数据库管理员。

重要

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

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

本文中介绍的概念主要适用于为三个内容交付范围（具体是指企业 BI、部门 BI 和团队 BI）创建的解决方案。 个人 BI 解决方案的创建者也可能会觉得本文中的信息很有用，但他们并非本文的主要受众。

当基础语义模型和/或数据源性能不佳时，无法在报表和视觉对象中实现良好的性能。 本文重点介绍如何审核和监视语义模型、数据流和数据市场。 这是关于审核和监视的文章系列中的第二篇文章，理由是工具和技术与报表级审核一文中描述的相比更加复杂。 理想情况是，在用户创建报表之前创建共享语义模型（用于在多个报表之间重复使用）。 因此，建议将本文与报表级审核文章一起阅读。

由于 Power BI 语义模型基于 Analysis Services 表格引擎构建，因此可以在 Power BI Desktop 中连接到本地数据模型，或者在 Power BI 服务中连接到 Premium 语义模型，就像它是 Analysis Services 数据库一样。 因此，Power BI Premium 语义模型支持 Analysis Services 的许多审核和监视功能。

注意

若要详细了解 Analysis Services 中托管的模型，请查看监视概述。

本文的其余部分主要介绍发布到 Power BI 服务的模型。

语义模型事件日志

随着时间的推移，数据创建者和所有者的语义模型可能会出现以下情况。 语义模型可以：

为了确保可用性、良好性能和其创建的内容的采用，应审核你负责管理的数据资产的使用情况和性能。 可使用数据集事件日志，它会捕获针对语义模型发生的用户生成活动和系统生成的活动。 它们也称为“跟踪事件”、“数据集日志”或“数据集活动日志”。 因为它们内容详细，系统管理员通常将其称为“低级别跟踪事件”。

注意

数据集名称更改已在Power BI 服务和文档中推出，尽管某些实例（例如事件日志操作名称）尚未发生更改。

应分析语义模型跟踪事件，以便：

  • 审核语义模型上发生的所有活动。
  • 对语义模型性能、内存使用情况和查询效率进行故障排除和优化。
  • 调查语义模型刷新详细信息和持续时间。
  • 监视 Power Query 发送的 Power Query 公式语言（M 查询）。
  • 监视发送到语义模型的 DAX 公式和表达式（Analysis Services 引擎）。
  • 根据工作负载以及在新数据和最佳性能之间达到平衡的需求，验证是否选择了正确的存储模式。
  • 审核在哪些语义模型上针对哪些用户调用了哪些行级别安全性角色。
  • 了解并发用户数。
  • 验证语义模型（例如，在认可语义模型之前，或在将语义模型发布到生产工作区之前验证数据质量和性能）。

Power BI 语义模型生成的事件源自 Azure Analysis Services 可用的现有诊断日志。 有许多类型的跟踪事件可供捕获和分析，下面各部分将对此进行介绍。

Azure Log Analytics

Azure Log Analytics 是 Azure Monitor 服务的一个组件。 通过 Azure Log Analytics 与 Power BI 的集成，可以从 Power BI 工作区中的所有语义模型中捕获语义模型事件。 只有 Premium 工作区支持此操作。 设置集成并为 Power BI Premium 工作区启用连接后，会自动捕获语义模型事件，并将其持续发送到 Azure Log Analytics 工作区。 语义模型日志存储在 Azure 数据资源管理器中 - 这是一个仅限追加的数据库，已针对捕获大量准实时遥测数据进行了优化。

将 Power BI Premium 工作区分配给 Azure 中的 Log Analytics 工作区。 必须在 Azure 订阅中创建新的 Log Analytics 资源，才能启用此类日志记录。

来自一个或多个 Power BI 工作区的日志会发送到目标 Log Analytics 工作区。 以下是可以选择用来整理数据的一些方法。

  • 一个目标工作区存储所有审计数据：在一个 Log Analytics 工作区中存储所有数据。 如果同一个管理员或同一批用户将会访问所有数据时，此功能非常有用。
  • 按主题领域划分的目标工作区：按主题领域划分内容。 当允许不同管理员或用户访问 Azure Log Analytics 中的审计数据时，此方法非常有用。 例如，当你需要从运营数据中分离出销售数据时。
  • 每个 Power BI 工作区共享同一个目标工作区：在 Power BI 工作区和 Azure Log Analytics 工作区之间设置一对一关系。 当你拥有敏感内容，或者数据须满足特定合规性或遵守法律法规时，此功能很有用。

提示

请全面查看有关此功能的文档和常见问题，以便清楚了解可实现的操作并了解技术要求。 在将此功能广泛提供给组织中的工作区管理员之前，请考虑使用一个 Power BI 工作区进行技术概念证明 (POC)。

重要

尽管名称相似，但 Azure Log Analytics 捕获的数据与 Power BI 活动日志不同。 Azure Log Analytics 会从 Analysis Services 引擎捕获详细信息级跟踪事件。 它的唯一用途是帮助你分析语义模型性能和排查相关问题。 其范围在工作区级别。 而活动日志的目的是帮助你了解某些用户活动发生的频率（例如编辑报表、刷新语义模型或创建应用）。 其范围是整个 Power BI 租户。

若要详细了解可针对 Power BI 租户审核的用户活动，请参阅租户级审核。

工作区管理员租户设置的 Azure Log Analytics 连接控制哪些用户组（谁也具有必要的工作区管理员角色）可以将 Power BI 工作区连接到现有的 Azure Log Analytics 工作区。

必须先满足安全性先决条件，然后才能设置集成。 因此，请考虑仅针对还在 Azure Log Analytics 中具有所需权限或者可根据请求获取这些权限的 Power BI 工作区管理员启用 Power BI 租户设置。

提示

在规划过程的早期与 Azure 管理员协作，尤其是在获得批准来新建 Azure 资源在你的组织中是一项挑战时。 还需要针对安全性先决条件进行规划。 决定是向 Azure 中的 Power BI 工作区管理员授予权限，还是向 Power BI 中的 Azure 管理员授予权限。

Azure Log Analytics 捕获的语义模型日志包括语义模型查询、查询统计信息、详细刷新活动、Premium 容量占用的 CPU 时间等。 由于它们是来自 Analysis Services 引擎的详细信息级日志，因此数据会非常详细。 对于语义模型活动较多的大型工作区来说，大数据量很常见。

若要在 Power BI 中使用 Azure Log Analytics 时优化成本，请执行以下操作：

  • 仅当主动对语义模型活动进行故障排除、测试、优化或调查时，才将 Power BI 工作区连接到 Azure Log Analytics。 连接后，跟踪将在工作区中的所有语义模型上运行。
  • 不再需要主动对语义模型活动进行故障排除、测试、优化或调查时，请断开 Azure Log Analytics 与 Power BI 工作区的连接。 断开连接后，将终止在工作区中的所有语义模型上运行跟踪。
  • 请确保了解 Azure Log Analytics 如何对数据引入、存储和查询计费的成本模型。
  • 在 Log Analytics 中存储数据的时间不要超过默认的 30 天保持期。 这是因为语义模型分析通常侧重于即时故障排除活动。

可通过多种方式访问发送到 Azure Log Analytics 的事件。 可用工具如下：

  • 预构建的“适用于 Power BI 语义模型的 Log Analytics”模板应用。
  • 适用于 Azure 数据资源管理器 (Kusto) 的 Power BI Desktop 连接器。 请使用 Kusto 查询语言 (KQL) 分析存储在 Log Analytics 中的数据。 如果你有 SQL 查询体验，你会发现 KQL 有很多相似之处。
  • Azure 数据资源管理器中基于 Web 的查询体验。
  • 可运行 KQL 查询的任何查询工具。

提示

由于语义模型跟踪事件的量很大，建议开发 DirectQuery 模型来分析数据。 使用 DirectQuery 模型可以近实时地查询数据。 事件通常在 5 分钟内到达。

有关详细信息，请参阅治理 Azure 连接。

清单 - 计划使用 Azure Log Analytics 时，关键决策和操作包括：

  • 考虑技术 POC：针对小项目进行规划，确保完全了解技术要求、安全要求、要捕获的事件和日志分析方式。
  • 确定哪些工作区应与 Log Analytics 集成：确定哪些 Premium 工作区包含你想要分析的语义模型。
  • 确定是否应为任何工作区全始终启用 Log Analytics：对于成本优化，请确定是否存在应永久启用日志记录的情况（或特定工作区）。 确定在未进行故障排除时是否应断开工作区的连接。
  • 确定 Log Analytics 数据的保留时长：确定是否需要设置比默认的 30 天更长的保持期。
  • 明确请求新的 Log Analytics 工作区的过程：与 Azure 管理员协作，明确 Power BI 工作区管理员应如何提交对新 Log Analytics 资源的请求。
  • 确定安全性的工作原理：与 Azure 管理员协作，确定是向 Power BI 工作区管理员授予 Azure Log Analytics 工作区的权限更可行，还是向 Azure 管理员授予 Power BI 工作区的权限更可行。 做出此安全决策时，请考虑定期连接工作区和断开连接的计划（目的是进行成本优化）。
  • 决定如何组织目标 Log Analytics 工作区：考虑多少个 Log Analytics 工作区才适合组织一个或多个 Power BI 工作区的数据。 将此决策与关于谁能访问日志数据的安全决策保持一致。
  • 确定允许哪些工作区管理员进行连接：确定哪些工作区管理员组可将 Power BI 工作区连接到 Log Analytics 工作区。 设置“工作区管理员的 Azure Log Analytics 连接”租户设置，使其与此决策保持一致。
  • 创建 Azure Log Analytics 资源：与 Azure 管理员协作创建每个 Log Analytics 工作区。 验证并更新在 Azure 中分配的权限，确保可进行 Power BI 配置而不出现任何问题。 验证 Azure 中存储的数据是否位于正确的地理区域。
  • 为每个 Power BI 工作区设置 Log Analytics 连接：与 Power BI 工作区管理员协作，为每个 Power BI 工作区设置与 Log Analytics 的连接。 验证日志数据是否正确流向 Log Analytics 工作区。
  • 创建查询来分析数据：设置 KQL 查询，根据你的用例和当前需求分析 Log Analytics 中的数据。
  • 包括面向 Power BI 工作区管理员指南：向 Power BI 工作区管理员提供信息和先决条件，使其了解如何请求新的 Log Analytics 工作区以及如何连接到 Power BI 工作区。 此外，请说明何时适合断开 Power BI 工作区的连接。
  • 提供用于分析数据的指南和示例查询：为工作区管理员创建 KQL 查询，以便他们能够更轻松地开始分析已捕获的数据。
  • 监视成本：与 Azure 管理员协作，持续监视 Log Analytics 成本。

SQL Server Profiler

可使用 SQL Server Profiler (SQL Profiler) 来捕获 Power BI 语义模型事件。 它是 SQL Server Management Studio (SSMS) 的一个组件。 SSMS 支持与 Power BI 语义模型的连接，因为它基于源自 SQL Server 的 Analysis Services 体系结构。

可以在语义模型生命周期的不同阶段使用 SQL Profiler。

  • 在数据模型开发期间：SQL Profiler 可作为外部工具连接到 Power BI Desktop 中的数据模型。 此方法适用于想要验证其数据模型或执行性能优化的数据建模者。
  • 将语义模型发布到 Power BI 服务后：SQL Profiler 可以连接到 Premium 工作区中的语义模型。 SSMS 是众多受支持的客户端工具之一，可使用 XMLA 终结点进行连接。 如果要在 Power BI 服务中审核、监视、验证、优化已发布的语义模型或排查相关问题，那么此方法非常有用。

还可在 DAX Studio 中将 SQL Profiler 作为外部工具使用。 可使用 DAX Studio 来启动探查器跟踪、分析数据和设置结果格式。 使用 DAX Studio 的数据建模者通常更喜欢这种方法，而不是直接使用 SQL Profiler。

注意

使用 SQL Profiler 与分析数据的活动不同。 需要在 Power Query 编辑器中分析数据，以便更深入地了解其特征。 虽然数据分析是数据建模师的重要活动，但不在本文的讲解范围内。

在以下情况下，请考虑使用 SQL Profiler 而不是 Azure Log Analytics：

  • 你的组织不允许你在 Azure 中使用或创建 Azure Log Analytics 资源。
  • 你想要捕获 Power BI Desktop 中的数据模型的事件（此模型尚未发布到 Power BI 服务中的 Premium 工作区）。
  • 你想要在短时间内捕获一个语义模型的事件（而不是 Premium 工作区中的所有语义模型）。
  • 你只想在跟踪期间捕获某些事件（例如，仅捕获“查询结束”事件）。
  • 你想要频繁启动和停止跟踪（例如，当你需要捕获当前发生的语义模型事件时）。

与 Azure Log Analytics 一样（参见本文的前面部分），SQL Profiler 捕获的语义模型事件源自 Azure Analysis Services 可用的现有诊断日志。 但是，可用事件存在一些差异。

提示

很多书籍、文章和博客文章介绍了如何使用 SQL Profiler 来监视 Analysis Services。 大部分信息都与监视 Power BI 语义模型相关。

重要

还可使用 SQL Profiler 监视从 Power BI 服务发送到基础数据源（例如，发送到 SQL Server 关系数据库）的查询。 但是，跟踪关系数据库的功能已弃用。 支持连接到 Analysis Services 引擎，此功能未弃用。 如果你熟悉 Analysis Services 扩展事件，并且更喜欢使用这些事件，那么对于 Power BI Desktop 中的数据模型，可从 SSMS 进行连接。 但是，Power BI Premium 不支持此操作。 因此，本部分仅重点介绍标准 SQL Profiler 连接。

“允许对本地语义模型使用 XMLA 终结点和‘在 Excel 中分析’功能”这一租户设置控制了哪些用户组可使用 XMLA 终结点查询和/或维护 Power BI 服务中的语义模型（其中这些用户也拥有“参与者”、“成员”或“管理员”工作区角色，或者拥有单个语义模型的“生成”权限）。 若要详细了解如何使用 XMLA 终结点，请查看高级数据模型管理使用方案。

注意

还可使用 SQL Profiler 来帮助调试特定 DAX 表达式并对其进行故障排除。 可以将 SQL Profiler 作为外部工具连接到 Power BI Desktop。 查找“DAX 评估日志”事件类来查看 DAX 表达式的中间结果。 在模型计算中使用 EVALUATEANDLOG DAX 函数时，会生成该事件。

此函数仅用于开发和测试目的。 在将数据模型发布到生产工作区之前，应将其从数据模型计算中移除。

清单 - 计划使用 SQL Profiler 时，关键决策和操作包括：

  • 确定谁可能安装了 SSMS 或 DAX Studio：确定是否允许组织中的所有 Power BI 内容创建者安装 SSMS 和/或 DAX Studio，以便其可以使用 SQL Profiler。 确定这些辅助工具是根据请求安装的，还是为组织中经批准的数据创建者安装的一组标准软件的一部分。
  • 将 SQL Profiler 添加到 Power BI Desktop 中的“外部工具”菜单：如果数据创建者会经常使用 SQL Profiler，请让 IT 人员自动将其添加到 Power BI Desktop 中的“外部工具”菜单，供这些用户使用。
  • 确定谁可使用 XMLA 终结点：确定是否允许所有用户使用 XMLA 终结点连接到已发布的语义模型，或者是否仅限于已批准的数据创建者。 设置“允许通过本地语义模型使用 XMLA 终结点和在 Excel 中分析”租户设置，使其与此决策保持一致。
  • 提供用于分析数据的指南和示例查询：为数据创建者创建文档，以便他们了解审核和监视语义模型的建议方法。 为常见用例提供指导，让他们更轻松地开始收集和分析跟踪数据。

数据模型元数据

由于 Power BI 语义模型基于 Analysis Services 引擎构建，因此你有权访问可查询数据模型元数据的工具。 元数据包含有关数据模型的一切内容，包括表名、列名和度量值表达式。

动态管理视图

Analysis Services 动态管理视图 (DMV) 可以查询数据模型元数据。 可以使用 DMV 在某个时间点审核、记录和优化数据模型。

具体而言，你可以：

  • 审核模型使用的数据源。
  • 发现哪些对象在模型中消耗的内存最多。
  • 确定压缩列数据的效率。
  • 查找模型中未使用的列。
  • 审核活动用户会话和连接。
  • 验证模型的结构。
  • 查看计算表、计算列、度量值和行级安全性 (RLS) 规则使用的 DAX 表达式。
  • 确定对象和度量值之间的依赖关系。

提示

DMV 会检索有关语义模型当前状态的信息。 将 DMV 返回的数据视为某个时间点所发生情况的快照。 相反，本文前面所述的语义模型事件日志检索跟踪连接处于活动状态时语义模型发生的活动的相关信息。

SSMS 是一种通常用于运行 DMV 查询的工具。 还可以使用 Invoke-ASCmd PowerShell cmdlet 来创建和执行查询 DMV 的 XMLA 脚本。

第三方工具和外部工具在 Power BI 社区也很受欢迎。 这些工具使用公开记录的 DMV 来简化访问和处理 DMV 返回的数据。 一个示例是 DAX Studio，它包含用于访问 DMV 的显式功能。 DAX Studio 还包括内置的视图指标功能（通常称为 Vertipaq Analyzer）。 Vertipaq Analyzer 具有一个用户界面，用于分析数据模型中表、列、关系和分区的结构和大小。 还可以将数据模型元数据导出（或导入）到 .vpax 文件。 导出的文件仅包含有关数据模型结构和大小的元数据，但不存储任何模型数据。

提示

如果需要数据模型方面的帮助，请考虑与其他人共享 .vpax 文件。 这样，你就不会与该人员共享模型数据。

可以在语义模型生命周期的不同阶段使用 DMV 查询。

  • 在数据模型开发期间：你选择的工具可作为外部工具连接到 Power BI Desktop 中的数据模型。 此方法适用于想要验证其数据模型或执行性能优化的数据建模者。
  • 将语义模型发布到 Power BI 服务后：你选择的工具可以连接到 Premium 工作区中的语义模型。 SSMS 是众多受支持的客户端工具之一，它使用 XMLA 终结点进行连接。 如果要在 Power BI 服务中审核或验证已发布的语义模型，此方法非常有用。

提示

如果你决定编写自己的 DMV 查询（例如在 SSMS 中），请注意 DMV 并不支持所有 SQL 操作。 此外，Power BI 不支持某些 DMV（因为它们需要 Power BI 不支持的 Analysis Services 服务器管理员权限）。

“允许对本地语义模型使用 XMLA 终结点和‘在 Excel 中分析’功能”这一租户设置控制了哪些用户组可使用 XMLA 终结点查询和/或维护 Power BI 服务中的语义模型（其中这些用户也拥有“参与者”、“成员”或“管理员”工作区角色，或者拥有单个语义模型的“生成”权限）。

若要详细了解如何使用 XMLA 终结点、第三方工具和外部工具，请查看高级数据模型管理使用方案。

最佳做法分析器

最佳做法分析器 (BPA) 是表格编辑器的一项功能，它是 Power BI 社区广泛采用的第三方工具。 BPA 包括一组可自定义的规则，可帮助你审核数据模型的质量、一致性和性能。

提示

若要设置 BPA，请下载 Microsoft 在 GitHub 上提供的一组最佳做法规则。

首先，BPA 通过检测可减少性能问题的次优设计决策，可帮助你提高模型的一致性。 如果你有自助式数据建模者分布在组织的不同区域，那么这非常有用。

BPA 还可以帮助你审核和管理数据模型。 例如，你可以验证数据模型是否包含任何行级安全性 (RLS) 角色。 或者，你可验证是否所有模型对象都有说明。 例如，当你的目标是确保数据模型包含数据字典时，这非常有用。

BPA 可以公开设计问题，这些问题可帮助卓越中心确定是否需要更多培训或文档。 它可采取措施向数据创建者介绍最佳做法和组织准则。

提示

请记住，BPA 可以检测是否存在某个特征（例如行级别安全）。 但是，可能很难确定它是否已正确设置。 因此，主题专家可能需要进行评审。 相反，不存在特定特征并不一定意味着设计不佳；数据建模者可能有充分的理由生成特定设计。

清单 - 计划访问数据模型的元数据时，关键决策和操作包括：

  • 确定谁可能安装了 SSMS：确定是否允许组织中的所有 Power BI 内容创建者安装 SSMS，以便他们可以连接到已发布的语义模型。 确定此工具是根据请求安装的，还是为组织中经批准的数据创建者安装的一组标准软件的一部分。
  • 确定谁可能安装了第三方工具：确定是否允许组织中的所有 Power BI 内容创建者安装第三方工具（例如 DAX Studio 和表格编辑器），以便他们可监视本地数据模型和/或已发布的语义模型。 确定这些工具是按请求安装的，还是为组织中经批准的数据创建者安装的一组标准软件的一部分。
  • 设置最佳做法规则：确定哪些最佳做法分析器规则可以扫描组织中的数据模型。
  • 确定谁可使用 XMLA 终结点：确定是否允许所有用户使用 XMLA 终结点连接到语义模型，或者是否仅限于已批准的数据创建者。 设置“允许通过本地语义模型使用 XMLA 终结点和在 Excel 中分析”租户设置，使其与此决策保持一致。
  • 为内容创建者提供指导：为数据创建者创建文档，以便他们了解分析语义模型的建议方法。 为常见用例提供指导，让他们更轻松地开始收集和分析 DMV 结果和/或使用最佳做法分析器。

数据模型和查询性能

Power BI Desktop 包括多个工具，可帮助数据创建者对数据模型进行故障排除和调查。 这些功能面向想要验证其数据模型和想要在发布到 Power BI 服务之前进行性能优化的数据建模者。

性能分析器

使用 Power BI Desktop 中提供的性能分析器来审核和调查数据模型的性能。 性能分析器可帮助报表创建者测量各个报表元素的性能。 但是，性能问题的根本原因通常与数据模型设计有关。 因此，语义模型创建者也可以从使用性能分析器中受益。 如果有不同的内容创建者负责创建报表和语义模型，这些创建者可能需要在排查性能问题时进行协作。

提示

可以使用 DAX Studio 来导入和分析性能分析器生成的日志文件。

有关性能分析器的详细信息，请参阅报表级审核。

查询诊断

使用 Power BI Desktop 中提供的查询诊断来调查 Power Query 的性能。 这些诊断可用于故障排除，当你需要了解 Power Query 引擎的作用时，它们也很有用。

可以从查询诊断中获得如下信息：

  • （发生异常时）与错误消息相关的额外详细信息。
  • 发送到数据源的查询。
  • 是否发生查询折叠。
  • 查询返回的行数。
  • 数据刷新操作期间可能出现的速度变慢情况。
  • 后台事件和系统生成的查询。

根据要查找的内容，可启用一种日志或所有日志：“聚合”、“详细”、“性能计数器”和“数据隐私分区”。

可在 Power Query 编辑器中启动会话诊断。 启用后，将收集查询和刷新操作，直到停止诊断跟踪。 一旦停止诊断，就会直接在查询编辑器中填充数据。 Power Query 会创建一个诊断组（文件夹），并向其添加多个查询。 然后，可以使用标准 Power Query 功能来查看和分析诊断数据。

或者，可在 Power BI Desktop 中，在“选项”窗口的“诊断”部分中启用跟踪。 日志文件将保存到本地计算机上的文件夹中。 关闭 Power BI Desktop 后（此时跟踪将停止），将使用数据填充这些日志文件。 关闭 Power BI Desktop 后，可以使用首选程序（例如文本编辑器）打开日志文件来查看它们。

查询计算和折叠

Power Query 支持各种功能来帮助你了解查询计算，例如查询计划。 它还可帮助你确定是针对整个查询还是针对查询中的一部分步骤进行查询折叠。 查询折叠是性能优化最重要的方面之一。 监视数据源时，查看 Power Query 发送的本机查询也很有帮助，本文稍后将对此进行介绍。

Premium 指标应用

进行故障排除时，与 Power BI Premium 容量管理员协作会很有帮助。 容量管理员有权访问 Power BI Premium 使用量和指标应用。 此应用可以提供有关容量中发生的活动的丰富信息。 该信息可以帮助你排查语义模型问题。

提示

Premium 容量管理员可以向其他用户（非容量管理员）授予访问权限，使他们能够他们访问 Premium 指标应用。

Premium 指标应用包含一个内部语义模型和一组初始报表。 它可帮助你对 Power BI Premium 容量 (P SKU) 或 Power BI Embedded (A SKU) 容量进行准实时监视。 它包括过去两到四周的数据，具体取决于指标。

使用 Premium 指标应用对语义模型进行故障排除和优化。 例如，可以识别内存占用量大或 CPU 使用率过高的语义模型。 若要查找即将达到容量大小限制的语义模型，该工具也很有用。

清单 - 考虑用于监视数据模型和查询性能的方法时，关键决策和操作包括：

  • 确定语义模型查询性能目标：确保你已充分了解良好的语义模型性能意味着什么。 确定何时需要特定的查询性能目标（例如，支持报表的查询必须在 5 秒内呈现）。 如果是这样，请确保将目标传达给组织中的数据创建者。
  • 确定语义模型刷新性能目标：确定何时需要特定的数据刷新目标（例如，在 15 分钟内并在凌晨 5 点之前完成数据刷新操作）。 如果是这样，请确保将目标传达给组织中的数据创建者。
  • 培训支持团队：确保内部用户支持团队熟悉诊断功能，以便他们可以在 Power BI 用户需要帮助时提供支持。
  • 连接支持团队和数据库管理员：确保支持团队知道如何联系每个数据源的适当管理员（例如，在排查查询折叠问题时）。
  • 与高级容量管理员协作：与容量管理员协作，对工作区中分配给高级容量或 Power BI Embedded 容量的语义模型进行故障排除。 适当时，请求访问 Premium 指标应用。
  • 为内容创建者提供指导：为数据创建者创建文档，以便他们了解在故障排除时要采取的操作。
  • 包含在培训材料中：为数据创建者提供有关如何创建性能良好的数据模型的指导。 帮助他们尽早养成良好的设计习惯。 专注于教授数据创建者如何做出好的设计决策。

数据源监视

有时，需要直接监视 Power BI 连接到的特定数据源。 例如，你可能有一个数据仓库的工作负载增加，并且用户报告性能下降。 通常，数据库管理员或系统管理员会监视数据源。

你可以监视数据源来实现以下目的：

  • 审核哪些用户正在向数据源发送查询。
  • 审核哪些应用程序（例如 Power BI）正在向数据源发送查询。
  • 查看哪些用户在何时向数据源发送哪些查询语句。
  • 确定运行查询所需的时间。
  • 审核源系统在使用单一登录 (SSO) 时如何调用行级别安全性。

Power BI 内容创建者在分析监视结果后可能会执行许多操作。 他们可以：

  • 调整并优化发送到数据源的查询，使其尽可能高效。
  • 验证并优化发送到数据源的本机查询。
  • 减少导入数据模型的列数。
  • 移除导入到数据模型的高精度和高基数列。
  • 减少导入到数据模型的历史数据量。
  • 调整 Power BI 数据刷新时间，帮助分散对数据源的需求。
  • 使用增量数据刷新来减少数据源上的负载。
  • 通过将多个语义模型合并到共享语义模型，减少 Power BI 数据刷新次数。
  • 调整自动页面刷新设置以增加刷新频率，从而减少数据源上的负载。
  • 简化计算以降低发送到数据源的查询的复杂性。
  • 更改数据存储模式（例如，更改为导入模式而不是 DirectQuery），从而减少数据源上的一致查询负载。
  • 使用查询减少技术来减少发送到数据源的查询数。

系统管理员可能会执行其他操作。 他们可以：

  • 在数据仓库不是可行选项时引入中间数据层，例如 Power BI 数据流。 Power BI 内容创建者可以使用数据流作为其数据源，而不是直接连接到数据源。 中间数据层可减少源系统上的负载。 它还具有将数据准备逻辑集中化这一额外优势。 有关详细信息，请查看自助式数据准备使用方案。
  • 更改数据源位置以减少网络延迟的影响（例如，对 Power BI 服务、数据源和网关使用相同的数据区域）。
  • 优化数据源，使其更有效地检索 Power BI 的数据。 几种常见技术包括创建表索引、创建索引视图、创建持久化计算列、维护统计信息、使用内存中表或列存储表，以及创建具体化视图。
  • 指示用户使用数据源的只读副本，而不是使用原始生产数据库。 副本可能作为高可用性 (HA) 数据库策略的一部分提供。 只读副本的一个优点是减少源系统上的争用。

可用于监视数据源的工具和技术由技术平台决定。 例如，数据库管理员可以使用扩展事件或查询存储来监视 Azure SQL 数据库和 SQL Server 数据库。

有时，Power BI 会通过数据网关访问数据源。 网关处理从 Power BI 服务到某些类型的数据源的连接。 但是，它们不只是连接到数据。 网关包括一个 mashup 引擎，用于在计算机上执行处理和数据转换。 它还会压缩和加密数据，使其可高效安全地传输到 Power BI 服务。 因此，非托管或未优化的网关可能会导致性能瓶颈。 建议与网关管理员联系，获取网关监视方面的帮助。

提示

Power BI 管理员可编译完整的租户清单（其中包括世系），并访问活动日志中的用户活动。 通过关联世系和用户活动，管理员可以识别最常用的数据源和网关。

有关租户清单和活动日志的详细信息，请参阅租户级审核。

清单 - 计划监视数据源时，关键决策和操作包括：

  • 确定特定目标：监视数据源时，请明确需要完成的具体任务和故障排除目标。
  • 与数据库管理员协作：与数据库或系统管理员协作，在监视特定数据源时获得他们的帮助。
  • 与网关管理员协作：对于通过数据网关连接的数据源，请在故障排除时与网关管理员协作。
  • 连接支持团队和数据库管理员：确保支持团队知道如何联系每个数据源的适当管理员（例如在排查查询折叠问题时）。
  • 更新培训和指南：为数据创建者提供有关如何使用组织数据源的关键信息和提示。 包含有关出现问题时要执行的操作的信息。

数据刷新监视

数据刷新操作涉及到将数据从基础数据源导入 Power BI 语义模型、数据流或数据市场。 可计划数据刷新操作或按需运行该操作。

服务级别协议

IT 通常使用服务级别协议 (SLA) 来记录对数据资产的期望。 对于 Power BI，请考虑对关键内容或企业级内容使用 SLA。 它通常包括用户预期何时可使用语义模型中更新的数据。 例如，你可能有一个 SLA，它要求所有数据刷新必须在每天上午 7 点之前完成。

语义模型日志

来自 Azure Log Analytics 或 SQL Profiler 的语义模型事件日志（如本文前面所述）包含有关语义模型中发生的情况的详细信息。 捕获的事件包括语义模型刷新活动。 需要对语义模型刷新进行故障排除和调查时，事件日志特别有用。

高级版容量语义模型

如果你有内容托管在 Power BI Premium 容量中，那么你有更多的功能来监视数据刷新操作。

  • 管理门户中的 Power BI 刷新摘要页包含刷新历史记录的摘要。 此摘要提供有关刷新持续时间和错误消息的信息。
  • Power BI Premium 使用量和指标应用还包括有用的刷新信息。 当需要调查 Power BI Premium 容量 (P SKU) 或 Power BI Embedded (A SKU) 容量的刷新活动时，此功能非常有用。

增强型语义模型刷新

内容创建者可通过将增强型刷新与在组中刷新数据集 Power BI REST API 结合使用，以编程方式启动语义模型刷新。 使用增强型刷新时，可以监视历史、当前和挂起的刷新操作。

数据刷新计划监视

Power BI 管理员可监视租户中的数据刷新计划，来确定在特定时间范围内（例如，在凌晨 5 点到凌晨 7 点之间，这可能是特别繁忙的数据刷新时间）是否同时计划了许多刷新操作。 管理员有权从元数据扫描 API（称为“扫描程序 API”）访问语义模型刷新计划元数据。

Power BI REST API

对于关键语义模型，不要仅依赖电子邮件通知来监视数据刷新问题。 请考虑在集中存储中编译数据刷新历史记录，你可在这里监视、分析和处理此历史记录。

可使用以下方法来检索数据刷新历史记录：

提示

强烈建议监视语义模型的刷新历史记录，确保当前数据可用于报表和仪表板。 它还有助于你了解是否满足 SLA。

清单 - 计划数据刷新监视时，关键决策和操作包括：

  • 确定特定目标：监视数据刷新时，请明确需要完成的具体任务和应监视的范围（例如生产语义模型、认证语义模型等）。
  • 考虑设置 SLA：确定对于设置数据可用性的预期以及设置何时应运行数据刷新计划来说 SLA 是否有用。
  • 与数据库和网关管理员协作：与数据库/系统管理员和网关管理员协作，来监视或排查数据刷新问题。
  • 向支持团队传达知识：确保支持团队知道在出现数据刷新问题时如何帮助内容创建者。
  • 更新培训和指南：为数据创建者提供有关如何从组织数据源和常见数据源刷新数据的关键信息和提示。 提供有关如何管理数据刷新的最佳做法和组织首选项。
  • 使用支持电子邮件地址发送通知：对于关键内容，请设置刷新通知以使用支持电子邮件地址。
  • 设置集中刷新监视：使用 Power BI REST API 编译数据刷新历史记录。

数据流监视

使用 Power Query Online 创建 Power BI 数据流。 前面所述的许多查询性能功能和 Power Query 诊断都适用。

（可选）可将工作区设置为将 Azure Data Lake Storage Gen2 用于数据流存储称为“自带存储”）而不是内部存储。 使用自带存储时，请考虑启用遥测，以便监视存储帐户的指标。 有关详细信息，请参阅自助式数据准备使用方案和高级数据准备使用方案。

可使用 Power BI REST API 来监视数据流事务。 例如，使用获取数据流事务 API 来检查数据流刷新的状态。

可以使用 Power BI 活动日志跟踪 Power BI 数据流的用户活动。 有关详细信息，请参阅租户级审核。

提示

有许多最佳做法可用来优化数据流设计。 有关详细信息，请参阅数据流最佳做法。

数据市场监视

Power BI 数据市场包括多个集成组件，例如数据流、托管数据库和语义模型。 请参阅本文前面的部分，了解每个组件的审核和监视。

可以使用 Power BI 活动日志跟踪 Power BI 数据市场的用户活动。 有关详细信息，请参阅租户级审核。

相关内容

在本系列的下一篇文章中，了解租户级审核。