在 Power BI Desktop 中排查 DirectQuery 模型问题
本文可帮助你诊断在 Power BI Desktop 或 Power BI 服务中开发的 Power BI DirectQuery 数据模型的性能问题。 本文还介绍了如何获取详细信息以帮助优化报表。
应在 Power BI Desktop(而不是 Power BI 服务或 Microsoft Power BI 报表服务器)中开始诊断任何性能问题。 性能问题通常依赖于基础数据源的性能级别。 可以在隔离的 Power BI Desktop 环境中更轻松地识别和诊断这些问题,而无需涉及本地网关等组件。
如果在 Power BI Desktop 未发现性能问题,可以侧重于调查 Power BI 服务中报表的具体内容。
在查看页面上的许多视觉对象之前,还应尝试将问题隔离到单个视觉对象。
性能分析器
性能分析器是一个有用工具,可在故障排除过程中识别性能问题。 如果可以在 Power BI Desktop 的页面上识别单个缓慢的视觉对象,则可以使用性能分析器来确定 Power BI Desktop 发送到基础源的查询。
还可以查看基础数据源发出的跟踪和诊断信息。 此类跟踪可能包含关于如何执行查询的详细信息以及如何改进的有用信息。
即使没有来自源的跟踪,也可以查看 Power BI 发送的查询及其执行时间。
注意
对于基于 DirectQuery SQL 的源,性能分析器仅显示针对 SQL Server、Oracle 和 Teradata 数据源的查询。
跟踪文件
默认情况下,Power BI Desktop 会在给定会话期间将事件记录到名为 FlightRecorderCurrent.trc 的跟踪文件中。 可在当前用户的 AppData 文件夹中找到当前会话的跟踪文件:<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces。
以下 DirectQuery 数据源将 Power BI 发送的所有查询写入跟踪文件。 该日志将来可能支持其他 DirectQuery 源。
- SQL Server
- Azure SQL 数据库
- Azure Synapse Analytics(以前称为 SQL 数据仓库)
- Oracle
- Teradata
- SAP HANA
若要轻松转到 Power BI Desktop 中的跟踪文件夹,请选择“文件”>“选项和设置”>“选项”,然后选择“诊断”。
在“故障转储集合”下,选择“打开故障转储/跟踪文件夹”链接,此时会打开以下文件夹:<User>\AppData\Local\Microsoft\Power BI Desktop\Traces。
导航到该文件夹的父文件夹,然后打开 AnalysisServicesWorkspaces 文件夹,该文件夹包含每个 Power BI Desktop 开放实例的一个工作区子文件夹。 子文件夹名称具有整数后缀,例如 AnalysisServicesWorkspace2058279583。
每个 AnalysisServicesWorkspace 文件夹包含一个 Data 子文件夹,其中包含当前 Power BI 会话的跟踪文件 FlightRecorderCurrent.trc。 相关联的 Power BI Desktop 会话结束时,该文件夹将消失。
可以使用 SQL Server Profiler 工具打开跟踪文件,该工具可作为免费 SQL Server Management Studio (SSMS) 下载的一部分获取。 下载并安装 SQL Server Management Studio 后,打开 SQL Server Profiler。
若要打开跟踪文件,请执行以下操作:
在 SQL Server Profiler 中,选择“文件”>“打开”>“跟踪文件”。
导航到或输入当前 Power BI 会话跟踪文件的路径,例如:<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data,并打开 FlightRecorderCurrent.trc。
SQL Server Profiler 显示当前会话的中所有事件。 以下屏幕截图突出显示了一组查询事件。 每个查询组具有以下事件:
Query Begin
和Query End
事件,表示通过更改 Power BI UI 中的视觉对象或筛选器,或筛选或转换 Power Query 编辑器中的数据生成的 DAX 查询的开始和结束。一对或多对
DirectQuery Begin
和DirectQuery End
事件,表示在评估 DAX 查询的过程中发送到基础数据源的查询。
多个 DAX 查询可以并行运行,因此来自不同组的事件可能互相交错。 可以使用 ActivityID
值确定哪些事件属于同一组。
以下各列也相关:
- TextData: 事件的文本详细信息。 对于
Query Begin
和Query End
事件,详细信息为 DAX 查询。 对于DirectQuery Begin
和DirectQuery End
事件,详细信息是发送到基础源的 SQL 查询。 当前所选事件的 TextData 值也会显示在屏幕底部的窗格中。 - EndTime: 事件完成的时间。
- Duration:运行 DAX 或 SQL 查询的持续时间,以毫秒为单位。
- Error:是否发生了错误(发生错误时,该事件也显示为红色)。
上图缩小了一些不太相关的列,因此你可以更轻松地查看更相关的列。
按照此方法捕获跟踪以帮助诊断潜在的性能问题:
打开单个 Power BI Desktop 会话,以避免多个工作区的文件夹产生混淆。
在 Power BI Desktop 执行一组意向操作。 再执行一些操作,确保将意向操作事件刷新到跟踪文件中。
打开 SQL Server Profiler 并检查跟踪。 请记住,关闭 Power BI Desktop 会删除跟踪文件。 此外,Power BI Desktop 中的其他操作不会立即显示。 必须关闭并重新打开跟踪文件才能看到新事件。
使各个会话保持在合理的范围内(可能是 10 秒而非数百秒的操作)。 此方法可以更轻松地解释跟踪文件。 跟踪文件的大小也有限制,因此对于长时间会话,早期事件可能会丢弃。
查询和子查询格式
Power BI Desktop 查询的一般格式是对查询引用的每个模型表使用子查询。 Power Query 编辑器查询定义子选择查询。 例如,假设 SQL Server 关系数据库中有以下 TPC-DS 表:
在 Power BI 视觉对象中,以下表达式定义 SalesAmount
度量值:
SalesAmount = SUMX(Web_Sales, [ws_sales_price] * [ws_quantity])
刷新该视觉对象会生成下图中的 T-SQL 查询。 如你所见,有针对 Web_Sales
、Item
和 Date_dim
模型表的三个子查询。 每个查询返回所有模型表列,即使视觉对象仅引用四列。
这些灰显的子查询是 Power Query 查询的确切定义。 这样使用子选择查询不会影响 DirectQuery 支持的数据源的性能。 SQL Server 等数据源优化了对其他列的引用。
Power BI 使用此模式原因之一是,你可以定义 Power Query 查询来使用特定的查询语句。 Power BI 按提供时的原样使用查询,而无需尝试重写它。 此模式限制使用使用公共表表达式 (CTE) 和存储过程的查询语句。 不能在子查询中使用这些语句。
网关性能
有关网关性能故障排除的信息,请参阅对网关进行排除故障 - Power BI。
相关内容
有关 DirectQuery 的详细信息,请查看以下资源:
- 在 Power BI Desktop 中使用 DirectQuery
- DirectQuery 支持的数据源
- Power BI Desktop 中的 DirectQuery 模型
- Power BI Desktop 中的 DirectQuery 模型指导
是否有任何问题? 尝试咨询 Power BI 社区