Power BI 中的 DirectQuery

借助 Power BI 中的 DirectQuery，可以在源中保留数据并在报表时查询数据，而不是导入数据。 本文介绍何时使用 DirectQuery、其限制以及混合表、Direct Lake 和实时连接等替代项，以便你可以选择正确的模式。

本文介绍：

• Power BI 数据连接模式以及 DirectQuery 适合的位置
• 选择何时使用 DirectQuery、导入、混合型数据表、Direct Lake 或实时连接
• 限制、影响和性能注意事项
• 建模和报表设计建议
• 诊断和改进性能

快速决策指南

下表总结了根据要求考虑的 Power BI 连接模式。 使用它作为快速参考来帮助在 Import、DirectQuery、混合表、Direct Lake 或实时连接之间进行选择：

Power BI 数据连接模式

Power BI 连接到多个数据源：

• Salesforce 和 Dynamics 365 等联机服务
• SQL Server、PostgreSQL、MySQL、Oracle、Snowflake 和 Amazon Redshift 等数据库
• 文件（Excel、CSV、JSON、Parquet）
• 大数据和分析引擎，如 Spark 和 Databricks
• 其他来源，如网站和Microsoft Exchange

从这些源导入数据。 有些还支持 DirectQuery。 有关维护的列表，请参阅 Power BI 数据源。 已启用 DirectQuery 的源通常提供交互式聚合查询性能。

默认使用导入。 它使用 Power BI 的高性能内存中引擎并提供最丰富的功能集。 仅当特定约束（延迟、大小、治理、安全或体系结构）需要时才超出导入范围。

新式增强功能（混合表、Direct Lake、自动聚合、复合模型和增量刷新）减少了需要纯 DirectQuery 的频率。

以下部分介绍导入、DirectQuery 和实时连接模式。 本文的其余部分重点介绍 DirectQuery，同时确认替代方法。

导入连接

导入数据时：

• 获取数据 选择定义每个表集的查询;可以在加载之前调整它们（筛选器、聚合、联接）。
• 这些查询定义的所有数据都会加载到语义模型的内存中缓存中。
• 生成视觉对象仅查询缓存的数据 -- 快速且完全交互。
• 在刷新（重新导入）之前，视觉对象不会反映源更改。
• 发布将上传包含导入数据的语义模型。 可以计划刷新（频率取决于许可证），并且可能需要本地数据网关。
• 在服务中生成或打开报表使用导入的数据。
• 语义模型刷新时，固定的仪表板磁贴会刷新。

DirectQuery 连接

使用 DirectQuery 时：

• 获取数据 可建立与受支持源的连接。 对于关系源，仍然可以选择表或视图;对于多维源（例如 SAP BW），请选择源模型。
• 加载时不会导入任何数据。 每个视觉对象都会触发对基础源的一个或多个查询。
• 视觉刷新延迟完全取决于数据源性能（以及网络/网关开销，如果适用）。
• 仅当在重新查询操作之后（如导航、切片器/筛选器更改、手动刷新），源数据中的更改才会显示。
• 发布无需导入数据即可创建语义模型定义（架构和元数据）。
• 服务中的报表查询源。 本地源可能需要网关。
• 基于 DirectQuery 模型的仪表板磁贴按计划刷新，以缓存快速打开仪表板的磁贴结果。
• 仪表板磁贴显示其上次计划刷新的结果，除非手动刷新。

实时连接

实时连接将 Power BI 直接连接到现有语义模型（例如 Analysis Services 或其他已发布的 Power BI 语义模型）。 它类似于 DirectQuery（无导入的数据），但语义（如角色强制）由上游模型处理。 进行实时连接时：

• 将显示完整的外部模型字段列表 - 无 Power Query 查询定义。
• 实时连接始终将用户的标识传递给 Analysis Services 或 Power BI 语义模型进行安全修整。
• 某些建模活动（如添加计算表）不可用，因为模型是外部的。

DirectQuery 在较新选项中的适用性

DirectQuery 是无法高效导入的大型或快速变化数据的主要解决方案。 今天：

• 混合表 允许在一个表中混合使用内存中和 DirectQuery 分区（最近的数据与历史数据）。
• Direct Lake （Fabric）允许近乎实时地访问 Lakehouse 表，而无需传统的刷新开销。
• 自动聚合 和手动聚合表加速频繁查询。
• 使用实时增量刷新的功能 允许最近时间窗口的数据以 DirectQuery 方式查询源数据，同时旧数据保持已导入的状态。

在采用完全 DirectQuery 模型之前评估这些选项。

DirectQuery 用例

DirectQuery 在以下情况下最有益：

• 数据更改太频繁，无法导入（即使增量刷新和计划刷新频率最大），并且需要低延迟可见性。
• 数据量或治理约束使完全引入不切实际。
• 源强制执行的安全策略（细粒度行规则）必须通过传递保持权威。
• 数据主权或法规规则限制保留的完整副本。
• 源以多维或度量为中心（例如 SAP BW），服务器定义的度量值必须按视觉对象解析。

数据频繁更改，需要准实时报告

导入的模型（Pro）每天最多可以计划 8 次刷新（加上按需/API 触发器）。 高级和 PPU 每天最多支持 48 次计划刷新，而且还支持最新分区的增量刷新和实时 DirectQuery（混合模式）。 如果仍无法满足所需的延迟，或者无法完全导入，请使用 DirectQuery、混合表或 Direct Lake。 DirectQuery 仪表板可以每隔 15 分钟刷新一次磁贴。

数据量很大

完整导入可能会超出内存或刷新窗口的限制。 DirectQuery 会就地查询数据。 如果源太慢，无法实现交互式性能，请考虑：

• 仅导入聚合或筛选的子集。
• 使用增量刷新和聚合。
• 使用混合表或 Direct Lake 处理最新和高价值段。

请参阅 Power BI Premium 中的大型语义模型 ，了解如何管理大量内存中数据。

源强制安全

导入依赖于在语义模型中定义的 Power BI 凭据和可选的行级别安全性（RLS）。 DirectQuery 可以（如果受支持）传递用户标识（SSO），以便源强制实施自己的安全规则。 请参阅 Power BI 中本地数据网关的单一登录（SSO）概述。

数据主权限制

当法规要求数据保留在受控边界内时，DirectQuery 限制保留的副本。 视觉对象和磁贴缓存仍可以包含有限的聚合数据。

具有服务器定义的度量值的源

某些系统（如 SAP BW）包含查询时解析的语义逻辑（度量值和层次结构）。 DirectQuery 支持按每个可视化对象进行解析。 请参阅 DirectQuery 和 SAP BW 、 DirectQuery 和 SAP HANA。

源特定注意事项（包括 PostgreSQL 和 MySQL）

行为和性能因引擎而异：

• PostgreSQL： 带引号的标识符区分大小写。 确保在联接和筛选列上使用适当的 B-tree 索引。 避免导致查询折叠过程提前中断的函数。 检查文本和数字联接是否存在隐式强制转换。
• MySQL： 使用一致的排序规则和 SQL 模式。 为常见筛选器和联接模式创建复合索引。 大型 TEXT 列可以减少折叠或强制后处理。
• Snowflake、BigQuery 和 Databricks： 弹性缩放可提高并发性，但冷启动延迟可能会影响第一个查询。 发送预热信号或安排定期活动。
• Azure Synapse、SQL 和 Fabric Warehouse： 列存储索引和结果集缓存提供强加速。 将它们与自动聚合结合。
• Azure 数据资源管理器： 投影修剪很重要。 仅选择所需的列并尽早应用筛选器。
• SAP BW 和 SAP HANA： 度量解析和层次结构语义驱动查询模式。 避免过度叠加的转换导致折叠无法进行。

确认查询折叠（在 Power Query 编辑器中选择“ 查看本机查询 ”）以便将转换操作下推。

DirectQuery 限制

使用 DirectQuery 会影响一致性、性能、安全性、转换、建模和报告。

常规影响

在 Power BI 中使用 DirectQuery 时，以下一般含义适用：

• 刷新以查看最新数据。 缓存（视觉对象、磁贴、结果）表示视觉对象可以在刷新前显示结果。 选择 “刷新 ”以强制重新查询页面上的所有视觉对象。
• 视觉效果并不总是与时间保持一致。 不同的视觉对象（或一个视觉对象中的内部查询）可以在略有不同的时间执行。 如果需要严格的时间点准确性，请刷新页面或设计聚合快照。
• 架构更改需要 Power BI Desktop 刷新。 该服务不会自动检测已删除或重命名的列。 在 Power BI Desktop 中打开模型并刷新以协调模型元数据。
• 一百万行的中间结果限制。 返回超过 1,000,000 行的任何查询（或中间作）都失败。 高级容量可以提高此限制，请参考 最大中间行集计数。
• 更改存储模式受到限制。 不能将仅导入模型全局切换到 DirectQuery。 请参阅下一部分。

更改存储模式 （导入 ↔ DirectQuery）

无法将整个导入模型切换到 DirectQuery。 相反：

• 向同一源添加新的 DirectQuery 连接，并将视觉对象映射到新表。
• 创建复合模型：保留 Import 维度，添加 DirectQuery 事实表（或反之），并可选择性地将某些表设置为 Dual。
• 使用混合表（最近的 DirectQuery 分区和历史导入）进行热冷优化。
• 如果前面的步骤阻止 DirectQuery，请使用折叠友好的转换重新生成。

性能和负载影响

交互式性能取决于源延迟和并发。 瞄准 5 秒以下的常见视觉刷新时间;超过 30 秒会降低可用性。 每个用户操作都会触发查询。 用户数量、视觉对象和磁贴的高刷新计数会造成大量负载，因此需要相应地规划容量。

安全隐患

除非配置 SSO，否则 DirectQuery 会为所有查看者使用已配置的存储凭据。 根据需要在语义模型中定义 RLS。 复合模型中的多个源可以在源之间移动数据;评估敏感数据移动 - 请参阅 安全隐患。

数据转换限制

Power Query 折叠是可扩展性能所必需的。 转换必须精简为单个本机查询。 复杂的步骤（不可折叠的操作、某些自定义函数、多步骤过程逻辑等）可能会导致需要简化或者切换到导入模式的错误。 由于公开了整个外部模型，因此 SAP BW 等 OLAP 源不允许进行查询内转换。 不支持存储过程调用和常用表表达式（CTE），因为它们无法在 DirectQuery 中以可折叠的方式使用。

建模限制

大多数功能得到了增强，但某些能力有所降低。

• 无自动日期层次结构（创建显式日期表）。
• 时间精度限制为秒（在源处删除毫秒）。
• 计算列仅限于可折叠的行级表达式；在自动完成中省略不受支持的函数。
• 没有父子 PATH 函数。
• 不支持集群。

报表限制

如果源响应良好，则大多数视觉效果都能正常运行。 注意以下限制和性能注意事项：

• 不支持长度超过 32,764 个字符的长文本列。
• 度量筛选器、TopN 筛选器、Median高级文本包含/开始筛选器、多选切片器和总计/小计（尤其是使用DistinctCount）可能添加额外查询或影响性能。
• 请考虑简化设计或禁用某些交互。

示例（度量值筛选器）：

DirectQuery 建议

本部分提供有关在 Power BI 中设计、优化和对 DirectQuery 模型进行故障排除的实用建议。 遵循以下准则，在处理 DirectQuery 连接时提高性能、可靠性和用户体验。

基础数据源性能

验证基础交互查询。 如果查询速度缓慢，请使用性能分析器检查查询，并优化源架构（如果适用）的索引、统计信息和列存储）。 优先使用整数键进行联接。

模型设计

• 使 Power Query 步骤简单且可折叠。 经常预览“查看原生查询”。
• 从简单的措施开始，然后迭代。
• 避免对计算表达式列进行联接 - 根据需要在源中具体化。
• 避免加入 uniqueidentifier 其中强制转换中断索引用法;具体化备用键类型。
• 隐藏代理项/系统密钥，并且根据需要创建可见的别名的列。
• 查看可生成非折叠表达式的计算表/列。
• 仅在必需的情形中限制使用双向筛选器。 测试性能影响。
• 请考虑假设引用完整性 以启用 INNER JOIN 用法。
• 避免 Power Query 中的相对日期筛选器。 而是在模型或报表层中实现相对逻辑。

筛选示例：

生成的本机查询使用固定文本日期：

报表设计

设计使用 DirectQuery 的报表时，请考虑以下最佳做法来优化可用性和性能：

• 使用查询减少选项（对切片器和筛选器使用“应用”按钮，并禁用在延迟影响体验时的交叉高亮显示）。

  

• 尽早应用关键筛选器，以减少中间行计数并避免达到限制。

• 限制每个页面的视觉对象 以最大程度地减少并行查询和序列化查询。

• 如果触发昂贵的源查询，请禁用不必要的交互（交叉筛选或突出显示）。

  

最大连接数

在文件>选项和当前文件的“选项 DirectQuery”设置“选项>”>中调整每个文件 DirectQuery 并发（默认 10）。

较高的值可以提高许多可视化效果的吞吐量，但它们也可以增加源负载。 发布的行为也可能受到服务或容量限制的影响。

性能缓解功能

使用这些功能可提高 DirectQuery 性能：

• 自动聚合和手动聚合表： 缓存汇总的数据以减少源查询。
• 混合表： 通过 DirectQuery 维护最新数据，通过导入历史数据。
• 聚合感知度量值设计： 确保 DAX 尽可能在聚合层进行评估。
• 动态 M 参数： 提前将用户选择推送到源谓词中。
• 查询和结果缓存（容量设置）： 对重复视觉对象重复使用最近的结果集。
• 共享维度表的双存储模式： 减少重复的远程维度扫描。

Power BI 服务中的 DirectQuery

Power BI Desktop 支持所有 DirectQuery 数据源。 只有有限的子集直接从服务 UI 启动。 从 Power BI Desktop 开始，实现更丰富的建模和转换控制。 有关服务中直接可用的源的当前列表，请参阅 Power BI 数据源。

服务中的性能取决于：

• 并发用户数
• 视觉复杂性和每页的数量
• 存在行级别安全性（可减少缓存重用）
• 磁贴刷新时间表

Power BI 服务中的报表行为

打开报表页会针对每个视觉对象运行查询（有时每个视觉对象有多个）。 每当进行交互操作（如切片器更改、交叉突出显示、筛选器应用）时，查询将再次运行。 服务会缓存一些结果。 除非安全边界不同，否则确切的重复查询可以立即返回。

功能细微差别：

• 快速见解： 不支持 DirectQuery 语义模型。
• 在 Excel 中浏览/在 Excel 中分析： 支持但感觉较慢。 考虑导入模式或聚合，以优化大量使用 Excel 的情况。
• Excel 中的层次结构： 某些 DirectQuery 语义模型层次结构在 Excel 中不显示相同。

仪表板刷新

DirectQuery 磁贴按计划刷新。 默认值为每小时，可以从每 15 分钟设置为每周一次。 通过行级别安全性，每个用户运行单独的磁贴查询。 高图块数量乘以用户数量和刷新频率可能导致负载过重，因此需要进行容量规划并考虑聚合。

查询超时

每个查询的服务都会执行 4 分钟的超时限制。 超出限制的视觉内容由于超时错误而失败。 在选择 DirectQuery 之前，请确保基础源提供交互式性能。

性能诊断

首先在 Power BI Desktop 中诊断性能。

使用 性能分析器 隔离慢速视觉对象。 一次关注一个有问题的视觉对象。

使用 SQL Server Profiler 查看查询

Power BI Desktop 将会话跟踪（包括某些源的 DirectQuery SQL）写入用户的 AnalysisServicesWorkspaces 文件夹中的 FlightRecorderCurrent.trc 文件。

若要查找跟踪，请执行以下命令：

1. 在 Power BI Desktop 中，选择“文件>选项和设置>诊断”。>

2. 选择 打开故障转储/跟踪文件夹。

   

3. 向上转到 AnalysisServicesWorkspaces，打开活动工作区文件夹，然后 数据，并找到 FlightRecorderCurrent.trc。

4. 在 SQL Server Profiler 中，打开文件： 文件 > 打开 > 跟踪文件。

探查器显示分组事件：

事件列：

• TextData： DAX（用于查询开始/结束）或原生 SQL（用于 DirectQuery 开始/结束）。
• 持续时间（ms） 和 EndTime 有助于查明慢速阶段。
• ActivityID 组相关事件。

捕获指南：

• 使会话保持短（≈10 秒的目标作）。
• 重新打开跟踪文件以查看新刷新的事件。
• 避免多个并发桌面实例，以减少混淆。

了解查询的格式

Power BI 通常对 Power Query 步骤定义的每个引用逻辑表使用子选择（派生表）。

示例查询逻辑：

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

生成的视觉对象：

使用子选择生成的 SQL：

子选择查询模式通常不会损害受支持引擎的性能，因为优化器消除了未使用的列。 确定可折叠性优先级。

相关内容

• 在 Power BI Desktop 中使用 DirectQuery
• DirectQuery 和 SAP HANA
• DirectQuery 和 SAP BW
• 使用适用于 Power BI 语义模型和 Analysis Services 的 DirectQuery
• Power BI 中的聚合
• 性能分析器
• 复合模型
• 行级别安全性概述
• 单一登录 (SSO)