Power BI 中的增量刷新：高效处理大型数据集

每个 Power BI 实现最终都会遇到同样的问题：数据集变得足够大，以至于完全刷新需要很长时间，消耗太多资源，并超出用户需要数据之前的可用时间窗口。

包含 5000 万行的事务表每 4 小时彻底刷新一次，不仅需要很长时间，而且还会浪费资源来重新加载未更改的数据。增量刷新通过仅加载新的和更改的记录，同时保留未更改的历史数据来解决此问题。如果做得正确，以前需要 3 小时刷新的数据集可以在 10 分钟内更新为最新数据。

本指南涵盖了 Power BI 中从基本原理到高级配置的增量更新，包括破坏实施的常见错误以及使其在生产环境中可靠的最佳实践。

要点

• 增量刷新按日期对数据集进行分区，在每个刷新周期仅加载最近的数据
• 需要事实表上的日期时间列和两个 Power Query 参数（RangeStart、RangeEnd）
• 历史数据保留在较旧的分区中，在初始加载后不会重新查询
• 超过 10 个分区的增量刷新需要 Power BI Premium（或 Fabric）
• 检测数据更改选项通过仅刷新数据更改的分区进一步减少处理
• 混合表（结合导入和 DirectQuery）支持实时数据以及历史导入分区
• 正确的配置需要了解 Power Query 折叠 - 不可折叠查询会破坏增量刷新
• 通过 XMLA 端点和第三方工具监控分区运行状况，防止静默故障

---

增量刷新如何工作

了解增量刷新首先要了解 Power BI 如何对数据进行分区。

在标准导入模型中，整个数据集位于单个分区中。每次刷新都会完全替换该分区。对于小型数据集，这很好。对于大型表，它会产生上述问题。

增量刷新将事实表拆分为多个分区，每个分区覆盖特定的日期范围：

• 分区1：2020-01-01至2020-12-31（历史，从未刷新）
• 分区 2：2021-01-01 至 2021-12-31（历史，从未刷新）
• 分区 3：2022-01-01 至 2022-12-31（历史，从未刷新）
• 分区 4：2023-01-01 至 2023-12-31（历史，从未刷新）
• 分区 5：2024-01-01 至 2024-12-31（每月刷新）
• 分区 6：2025-01-01 至 2025-03-31（每日刷新）
• 分区 7：2025 年 4 月 1 日至今（每小时或按需刷新）

每次计划刷新时，仅处理最近的分区（本示例中为 5、6 和 7）。历史分区从首次加载时起就保持完整。这意味着刷新周期仅处理总数据的一小部分，从而大大减少时间、内存和源系统负载。

---

先决条件和要求

在配置增量刷新之前，请验证是否满足以下先决条件：

许可：增量刷新在 Power BI Pro（有限制）和 Power BI Premium/Fabric（完整功能）中可用。使用 Pro 版，您最多可以配置 10 个刷新周期。 Premium 消除了此限制并添加了“检测数据更改”功能。

日期时间列：事实表必须具有 Power BI 将用于对数据进行分区的日期时间列（不是日期键整数 — 必须是实际的日期时间类型）。这通常是事务日期、事件时间戳或创建时间列。

查询折叠：加载事实表的 Power Query 查询必须支持查询折叠 - 将 Power Query 转换步骤转换为源系统执行的源查询（SQL 等）的能力。如果查询折叠中断，增量刷新会默默失败 - 它会在每次刷新时加载所有数据，从而达不到目的。

源系统支持：源必须有效支持日期范围过滤。即使配置了增量刷新，在日期时间列上没有索引的源表也会产生缓慢的刷新，因为每次分区刷新都会执行全表扫描以查找日期范围内的记录。

---

逐步配置

步骤 1：创建所需的 Power Query 参数

在 Power BI Desktop 中，打开 Power Query 编辑器。转至管理参数 → 新参数。

完全如下创建两个参数（名称区分大小写并且必须完全匹配）：

这些参数必须是日期/时间类型，而不是日期类型。它们将在运行时被 Power BI 的刷新引擎覆盖，但它们需要有效的默认值来进行开发和测试。

步骤 2：使用这些参数过滤事实表

在 Power Query 编辑器中，选择您的事实表。使用以下参数对日期时间列应用过滤器：

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

此过滤步骤至关重要：它必须折叠到数据源。要验证折叠，请右键单击最后一个查询步骤，然后检查“查看本机查询”是否可用。如果它呈灰色，则折叠已损坏 - 检查其上方的哪些转换步骤正在破坏折叠链。

第 3 步：验证查询折叠

查询折叠中断最常见的原因是：

• 无法转换为 SQL 的自定义函数
• 合并（连接）两个查询，其中一个或两个查询都不折叠
• 某些文本转换函数（Text.Upper、Text.PadStart）
• 使用列表操作（List.Contains）
• 添加索引列
• 某些类型转换操作

如果折叠中断，请重构查询，将有问题的操作推送到日期筛选器之后的后续步骤，或者在源数据库的视图中而不是在 Power Query 中执行转换。

步骤4：配置增量刷新策略

在 Power BI Desktop 中，右键单击字段窗格中的事实表 → 增量刷新。

配置选项：

• 存储最近 N 个日历年/月/日的行：这定义了模型中保留的总历史窗口。早于此的数据会自动从模型中删除（删除的分区）。

• 仅刷新最近 N 个日历年/月/日的行：这定义了在每个周期重新刷新的滚动窗口。早于此窗口的数据将被视为历史（不可变）并且不再刷新。

• 检测数据更改：（仅限高级版）使用单独的日期时间列（通常是“上次修改”列）来检测哪些历史分区已更改数据，并且仅重新处理这些分区。

具有 5 年历史的事务数据库的示例配置：

• 存储过去5年的行
• 仅刷新最近3天内的行

这将创建涵盖 5 年数据的分区，但每个周期仅刷新过去 3 天的分区。

第5步：发布并验证

将报表发布到 Power BI 服务。发布后的第一次刷新将比后续刷新花费更长的时间 - 它会加载所有历史数据并第一次创建所有分区。这是预料之中的。

---

高级配置：检测数据变化

Premium 中的“检测数据更改”选项又提高了一层效率。它通过查询指定列（通常是 last_modified_date 列）来确定历史分区中的任何记录是否已更新。仅刷新数据实际发生更改的分区。

不检测数据更改：即使最近 3 天内没有数据更改，3 天滚动窗口也会始终刷新。

通过检测数据更改：刷新引擎在决定是否处理每个分区之前检查滚动窗口中的任何记录是否被修改。如果星期一晚上刷新了星期一的数据，并且此后没有修改任何记录，则星期二晚上的刷新将跳过星期一分区。

这对于以下场景特别有价值：

• 源数据写入一次并且很少更新（不可变的仅附加事件）
• 滚动窗口很大（例如 30 天），但大多数日子没有变化
• 源系统查询能力受限

检测数据更改列必须在源数据库中建立索引 - 刷新引擎在每个刷新周期查询每个分区的该列。

---

混合表：实时+历史数据

Power BI Fabric/Premium 引入了混合表 - 导入模式（历史分区）和 DirectQuery 模式（当前数据）的强大组合。这使得仪表板能够显示更新到当前分钟的数据以及历史导入数据。

在混合表配置中：

• 历史分区（昨天和更早的）处于导入模式 - 快速、缓存、完全可聚合
• 当前分区处于 DirectQuery 模式 - 针对源数据库实时运行查询

用户体验是无缝的——查询透明地跨越两种模式。 “本周销售额与上周销售额”的查询会从导入分区中提取昨天的数据，并通过 DirectQuery 提取今天的数据，将它们组合成一个结果。

混合表的注意事项：

• DirectQuery 性能完全取决于源数据库性能 - 缓慢的数据库意味着缓慢的当前查询
• DirectQuery 分区不会受益于导入模式优化（无 VertiPaq 压缩、无预聚合）
• 需要 Premium 或 Fabric 工作区

---

监控增量刷新健康状况

增量刷新失败通常是无声的 — 即使某些分区失败或回退到完全刷新，模型也会显示为“刷新成功”。监控对于生产可靠性至关重要。

XMLA 端点检查：Power BI Premium 公开 SQL Server Management Studio (SSMS)、表格编辑器或 Azure Analysis Services 等工具可以连接到的 XMLA 端点。从那里，您可以查询分区元数据以查看每个分区的上次刷新时间以及是否有任何分区处于错误状态。

表格编辑器 2（免费）：通过 XMLA 连接到 Premium 工作区并检查模型中的分区表。每个分区都会显示其名称、日期范围、上次刷新时间戳和状态。这是诊断增量刷新问题的最实用的工具。

Power BI 活动日志：管理活动日志记录刷新操作，包括处理了哪些分区以及任何错误。可通过 Power BI REST API 获取。

常见故障模式：

---

查询折叠验证实践

查询折叠是增量刷新未能实现其承诺的性能提升的最常见原因。以下是如何诊断和修复常见的折叠断裂。

测试 1：查看本机查询。在 Power Query 中添加 RangeStart/RangeEnd 筛选器步骤后，右键单击该步骤。如果“查看本机查询”可用并且显示带有过滤日期范围的 WHERE 子句的 SQL 查询，则折叠正在工作。

测试2：检查生成的SQL。本机查询应包含以下内容：

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

如果缺少 WHERE 子句，则折叠已损坏，并且在从源加载所有数据后，将在 Power Query 引擎中应用筛选器。

恢复折叠：如果自定义转换破坏了折叠，请将其移至日期筛选步骤之后，或在源数据库的 SQL 视图中执行转换并将 Power BI 连接到视图而不是表。

---

常见问题

增量刷新是否适用于所有数据源？

增量刷新适用于任何支持查询折叠和日期范围筛选的数据源，包括 SQL Server、Azure SQL、PostgreSQL、Snowflake、BigQuery、Azure Synapse 和 Databricks。它不适用于不支持查询折叠的源（Excel 文件、平面 CSV、某些 REST API）——在这些情况下，仍然需要完全刷新。对于不可折叠源，建议的解决方法是在 Power BI 连接之前将数据暂存在 SQL 数据库中。

增量刷新需要什么 Power BI 许可证？

增量刷新可在 Power BI Pro（仅限 10 个刷新周期）、Power BI Premium 每容量、Power BI Premium 每用户 (PPU) 和 Microsoft Fabric 容量中使用。 “检测数据更改”功能和混合表需要 Premium 或 Fabric。对于大多数具有超过 10 个历史分区的企业实施，需要 Premium 或 Fabric。

增量刷新如何处理迟到的数据？

迟到数据——在交易日期之后到达的记录（例如，12 月的交易在 1 月的数据提取中到达）——通过将滚动刷新窗口设置得足够宽以捕获迟到数据来处理。如果数据最多可能延迟 7 天到达，则将滚动窗口设置为 14 天可确保在重新刷新相关分区时捕获延迟到达的数据。或者，无论滚动窗口设置如何，带有最后修改列的检测数据更改选项都会捕获迟到的数据。

增量刷新是否可以应用于维度表，而不仅仅是事实？

增量刷新是为大型事实表设计的，并且需要日期时间筛选列。大多数维度表（产品、客户、位置）没有合适的日期时间分区列，并且足够小，适合完全刷新。对于缓慢变化且已变大的维度表（具有 50M+ 行的客户表），另一种方法是使用源数据库中的 SQL 视图来过滤最近更改的记录并在数据库层而不是 Power BI 中处理历史记录保留。

如何查看增量刷新模型中存在哪些分区？

最简单的方法是通过 XMLA 终结点将表格编辑器（免费版本 2）连接到 Power BI Premium 工作区。在表 → [您的表] → 分区下，您将看到所有创建的分区及其日期范围和上次处理的时间戳。 SQL Server Management Studio (SSMS) 还通过 XMLA 进行连接，并在对象资源管理器中显示分区详细信息。

如果增量刷新中途失败会发生什么？

如果刷新中途失败，Power BI 会重试失败的分区。不会重新处理在失败之前成功完成的分区 - 仅重试失败的分区。这种重试行为意味着增量刷新比完全刷新更能适应短暂的源系统中断。如果某个分区持续失败，则该分区将保持上次成功加载的状态，同时新分区将继续正常刷新。

---

后续步骤

增量刷新是任何处理大型事务数据集的 Power BI 实施的基础。从一开始就采取正确的做法——通过适当的查询折叠、适当的滚动窗口和监控——可以防止出现性能问题，从而迫使以后进行昂贵的重新架构。

ECOSIRE 的 Power BI 性能优化服务 包括针对大型企业数据集的增量刷新设计和实施。联系我们评估您当前的刷新架构并确定优化机会。