数据集的增量刷新和实时数据

增量刷新通过为经常加载新数据和更新数据的数据集表提供自动化分区创建和管理功能,扩展了计划的刷新操作。 对于大多数数据集来说,这是一个或多个包含事务数据的表,这些数据经常变化,并可能呈指数级增长,如关系数据库或星型数据库架构中的事实数据表。 对表进行分区的增量刷新策略、仅刷新最新的导入分区、视需要利用额外的 DirectQuery 分区获取实时数据可以显著减少必须刷新的数据量,同时确保数据源的最新更改也包含在查询结果中。

使用增量刷新和实时数据:

  • 快速更改的数据的刷新周期更少 - DirectQuery 模式在处理查询时获取最新的数据更新,无需高刷新节奏。
  • 刷新更快捷 - 只需刷新最近更改的数据。
  • 刷新更可靠 - 无需与不稳定数据源建立长期连接。 对源数据的查询运行速度更快,降低了网络问题造成干扰的可能性。
  • 降低资源消耗 - 要刷新的数据量减少,从而降低了 Power BI 和数据源系统中的内存和其他资源的整体使用量。
  • 允许大型数据集 - 数据集可能会增加到包含数十亿行,而无需在每次执行刷新操作时完全刷新整个数据集。
  • 轻松安装 - 只需完成几个任务即可在 Power BI Desktop 中定义增量刷新策略。 发布策略后,服务会在每次刷新时自动应用这些策略。

将 Power BI Desktop 模型发布到服务时,新数据集中的每个表都有一个分区。 该单一分区包含该表的所有行。 如果表很大,比如说有几千万行甚至更多行,刷新该表可能需要很长时间,并且会占用过多的资源。

使用增量刷新时,服务会动态地对数据进行分区,并将需要频繁刷新的数据与不经常刷新的数据分开。 表数据是使用名称为 RangeStart 和 RangeEnd(为保留名称且区分大小写)的 Power Query 日期/时间参数进行筛选的 。 最初在 Power BI Desktop 中配置增量刷新时,参数仅用于筛选要加载到模型中的短时间内的数据。 当发布到服务时,随着第一次刷新操作,服务根据增量刷新策略设置创建增量刷新和历史分区以及可选的实时 DirectQuery 分区,然后覆盖参数值,基于每行的日期/时间值筛选和查询每个分区的数据。

在随后的每次刷新中,查询筛选器仅返回那些由参数动态定义的刷新周期内的记录。 刷新的是日期/时间在刷新周期内的那些行。 日期/时间不再处于刷新周期内的行将成为历史周期的一部分,不会再刷新。 如果增量刷新策略中包含实时 DirectQuery 分区,则还会更新其筛选器,以便拾取在刷新周期后发生的任何更改。 刷新周期和历史周期都是向前滚动的。 创建了新的增量刷新分区后,不再处于刷新周期内的刷新分区将成为历史分区。 随着时间的推移,历史分区的粒度会越来越小,因为它们被合并在一起。 当历史记录分区不再处于策略定义的历史周期内时,将从数据集中被完全删除。 这称为“滚动窗口模式”。

Graphic representing a rolling window pattern.

增量刷新的优点是,服务将根据你定义的增量刷新策略为你处理所有操作。 事实上,进程和此模式创建的分区在服务中甚至不可见。 在大多数情况下,一个明确定义的增量刷新策略是显著提高数据集刷新性能的所有必要因素。 但是,仅 Premium 容量中的数据集支持实时 DirectQuery 分区,Power BI Premium 也可以通过 XMLA 终结点实现更高级的分区和刷新方案。

要求

支持的计划

Power BI Premium、Premium Per User、Power BI Pro 和 Power BI Embedded 数据集支持增量刷新。

仅 Power BI Premium、Premium Per User 和 Power BI Embedded 数据集支持使用 DirectQuery 实时获取最新数据。

支持的数据源

增量刷新和实时数据最适用于结构化关系数据源,如 SQL 数据库和 Azure Synapse,但也适用于其他数据源。 在任何情况下,数据源都必须支持以下各项:

日期列 - 表必须包含日期/时间或整数数据类型的日期列。 RangeStart 和 RangeEnd 参数(必须为日期/时间数据类型)根据日期列筛选表数据。 对于格式为 yyyymmdd 的整数代理键的日期列,你可以创建一个函数,用于转换 RangeStart 和 RangeEnd 参数中的日期/时间值,以匹配日期列的整数代理键。 若要了解详细信息,请参阅配置增量刷新 - 将日期/时间转换为整数

查询折叠 - 增量刷新适用于支持“查询折叠”的数据源,这是 Power Query 中可以生成单个查询表达式来检索和转换源数据的功能,尤其是在使用 DirectQuery 实时获取最新数据时。 大多数支持 SQL 查询的数据源都支持查询折叠。 平面文件、blob 和部分 Web 数据源通常不支持查询折叠。

配置增量刷新时,将对数据源执行包含基于 RangeStart 和 RangeEnd 参数的日期/时间筛选器的 Power Query 表达式。 此筛选器实际上是一个包含在查询中的转换,它根据参数定义了一个 WHERE 子句。 如果数据源不支持筛选器,则无法将其包含在查询表达式中。 如果增量刷新策略包括使用 DirectQuery 获取实时数据,则无法使用非折叠转换。 如果它是不包含实时数据的纯导入模式策略,则查询糅合引擎可能会在本地补偿筛选器并应用筛选器,这需要从数据源中检索表的所有行。 这可能会导致增量刷新速度变慢,并且此进程可能会耗尽 Power BI 服务或本地数据网关上的资源,这实际上违背了增量刷新的本意。

由于不同数据源类型对查询折叠的支持各不相同,因此应进行验证以确保针对数据源执行的查询中包含了筛选器逻辑。 在大多数情况下,在定义增量刷新策略时,Power BI Desktop 会尝试为你执行此验证。 对于基于 SQL 的数据源(例如 SQL 数据库、Azure Synapse、Oracle 和 Teradata),此验证是可靠的。 但是,如果不跟踪查询,其他数据源可能无法进行验证。 如果 Power BI Desktop 无法确认,“增量刷新策略配置”对话框中会显示一条警告。

Query folding warning

如果你看到此警告,并需要验证是否正在执行所需的查询折叠,请使用数据源支持的工具(如 SQL 事件探查器)来使用 Power Query 诊断功能或跟踪查询。 如果未进行查询折叠,请验证要传递给数据源的查询中是否包含筛选器逻辑。 如果不包含,则该查询可能包含禁止折叠的转换。

在配置增量刷新解决方案之前,请务必仔细阅读并了解 Power BI Desktop 中的查询折叠指南Power Query 查询折叠。 这些文章可帮助你确定数据源和查询是否支持查询折叠。

单个数据源

使用 Power BI Desktop 配置增量刷新和实时数据时,或者使用表格模型脚本语言 (TMSL) 或表格对象模型 (TOM) 通过 XMLA 终结点配置高级解决方案时,所有分区(无论是导入还是 DirectQuery)都必须从单个源查询数据。

其他数据源类型

通过使用其他自定义查询函数和查询逻辑,可以对其他类型的数据源使用增量刷新,前提是可以在单个查询中传递基于 RangeStart 和 RangeEnd 的筛选器。 例如,保存在文件夹中的 Excel 工作簿文件、SharePoint 中的文件或 RSS 源。 请注意,这些高级方案需要比本文所述内容更多的自定义和测试。 请务必查看本文后面的社区部分,了解如何找到更多关于使用增量刷新的信息,以应对类似的独特场景。

时间限制

无论增量刷新如何,Power BI Pro 数据集的刷新时间限制为两小时,并且不支持使用 DirectQuery 获取实时数据。 对于高级容量中的数据集,时间限制为 5 小时。 刷新操作将使用大量进程,并消耗大量内存。 完全刷新操作使用的内存量多达数据集自身所需内存的两倍,因为在刷新操作完成前,服务会在内存中保留数据集的快照。 刷新操作还可能会使用大量进程,并消耗大量可用的 CPU 资源。 刷新操作还必须依赖于与数据源的不稳定连接,以及这些数据源系统快速返回查询输出的能力。 时间限制是防止过度使用可用资源的一种安全措施。

注意

使用高级容量时,通过 XMLA 终结点执行的刷新操作没有时间限制。 若要了解详细信息,请参阅使用 XMLA 终结点进行高级增量刷新

由于增量刷新在数据集中的分区级别优化刷新操作,因此可以显著减少资源使用量。 同时,即使使用增量刷新,除非通过 XMLA 终结点执行,否则,刷新操作也受相同的 2 小时和 5 小时限制。 有效的增量刷新策略不仅减少了刷新操作处理的数据量,还减少了存储在数据集中的不必要的历史数据量。

查询还受数据源默认时间限制的限制。 大多数关系数据源都允许在 Power Query M 表达式中覆盖时间限制。 例如,以下表达式通过 SQL Server 数据访问函数将 CommandTimeout 设置为 2 小时。 策略范围定义的每个周期提交一个查询,以观察命令超时设置。

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

对于可能包含数十亿行的高级容量中的超大型数据集,可以启动初始刷新操作。 通过启动,服务可以为数据集创建表和分区对象,但不会将数据加载到任何分区中并进行处理。 通过使用 SQL Server Management Studio,分区可以单独处理、按顺序处理或并行处理,从而减少单个查询中返回的数据量,同时绕过 5 小时的时间限制。 若要了解详细信息,请参阅高级增量刷新 - 防止初始完全刷新超时

当前日期和时间

当前日期和时间基于刷新时的系统日期。 如果为服务中的数据集启用了计划的刷新,则在确定当前日期和时间时将考虑指定的时区。 通过服务执行的单个刷新和计划的刷新都将遵循时区(如果可用)。 例如,指定在太平洋时间(美国和加拿大)晚上 8 点刷新并指定时区,将根据太平洋时间确定当前日期和时间,而不是 GMT(若根据后者确定,则当前时间将晚一天)。 不通过服务调用的刷新操作(如 TMSL 刷新命令)将不考虑计划的刷新时区。

Time zone

配置增量刷新和实时数据

这里我们将了解有关配置增量刷新和实时数据的重要概念。 如果你已准备好按详细的分步说明操作,请务必查看配置数据集的增量刷新和实时数据

配置增量刷新是在 Power BI Desktop 中完成的。 对于大多数模型,只需要完成几个任务。 但是,请注意以下几个方面:

  • 当发布到服务时,不能再次从 Power BI Desktop 发布同一模型。 重新发布将删除数据集中已有的所有分区和数据。 如果要发布到高级容量,可通过开源 ALM 工具包或使用表格模型脚本语言 (TMSL) 等工具进行后续元数据架构更改。 若要了解详细信息,请参阅高级增量刷新 - 仅元数据部署
  • 当发布到服务时,无法将数据集以 PBIX 格式下载回 Power BI Desktop。 由于服务中的数据集可能会变得很大,因此将数据集下载回来并在一般台式计算机中打开是不切实际的。
  • 在使用 DirectQuery 获取实时数据时,无法将数据集发布到非 Premium 工作区。 仅 Power BI Premium 支持增量刷新和实时数据。

创建参数

在 Power BI Desktop 中配置增量刷新时,需要先创建两个名称为 RangeStart 和 RangeEnd(为保留名称且区分大小写)的 Power Query 日期/时间参数 。 在 Power Query 编辑器的“管理参数”对话框中定义的这些参数最初用于筛选加载到 Power BI Desktop 模型表中的数据,以便只包括日期/时间在该周期内的行。 将模型发布到服务后,服务会自动覆盖 RangeStart 和 RangeEnd,以查询增量刷新策略设置中指定的刷新周期定义的数据。

例如,FactInternetSales 数据源表平均每天新增 10,000 行。 为了限制 Power BI Desktop 中最初加载到模型中的行数,我们在 RangeStart 和 RangeEnd 之间指定了 2 天的周期。

Manage Parameters dialogue

筛选数据

定义了 RangeStart 和 RangeEnd 参数后,你可以对表的日期列应用自定义日期筛选器。 单击“应用”后,你应用的筛选器会选择将被加载到模型中的数据子集。

Custom filter

使用我们的 FactInternetSales 示例,在基于参数创建筛选器并应用步骤后,两天的数据 - 大约 20,000 行被加载到模型中。

定义策略

在应用筛选器并将数据子集加载到模型后,可以为表定义增量刷新策略。 将模型发布到服务后,服务将使用该策略来创建和管理表分区,并执行刷新操作。 若要定义策略,将使用“增量刷新和实时数据”对话框指定必需设置和可选设置。

Define policy dialog

“选择表”列表框默认为你在“数据视图”中选择的表。 使用滑块启用表增量刷新。 如果表的 Power Query 表达式不包括基于 RangeStart 和 RangeEnd 参数的筛选器,则会禁止切换。

必需设置

“在刷新日期之前开始存档数据”设置用于确定一个历史周期,在这个周期内的日期/时间的行被包含在数据集中,加上当前不完整的历史周期的行,加上直至当前日期和时间的刷新周期的行。

例如,如果指定 5 年,表将在年份分区中存储最近五个整年的历史数据,加上在季度、月份或日期分区中存储当年的行,直至刷新周期(包含)。

对于高级容量中的数据集,可以按此设置确定的粒度选择性地对追溯历史分区进行刷新。 若要了解详细信息,请参阅高级增量刷新 - 分区

“在刷新日期之前开始增量刷新数据”设置确定了增量刷新周期,日期/时间在此周期内的所有行都包含在刷新分区中,并在执行每次刷新操作时刷新。

例如,如果将刷新周期指定为 3 天,则在每次刷新时,服务将覆盖 RangeStart 和 RangeEnd 参数,以便为日期/时间在 3 天内的行创建一个查询,其开始和结束时间依赖于当前日期和时间。 将刷新日期/时间在过去 3 天内直至当前刷新操作时间的行。 对于此类策略,服务中平均每日新增 10,000 行的 FactInternetSales 数据集表的每次刷新操作应刷新约 30,000 行。

请确保指定一个时期,只包含可确保准确报告所需的最少行数。 如果为多个表定义策略,则必须使用相同的 RangeStart 和 RangeEnd 参数,即使为每个表定义了不同的存储和刷新周期也是如此。

可选设置

“使用 DirectQuery 实时获取最新数据(仅限高级版)”设置允许使用 DirectQuery 从增量刷新周期后的数据源中的选定表中提取最新更改。 日期/时间晚于增量刷新周期的所有行都包含在 DirectQuery 分区中,并在每次数据集查询时从数据源中提取。

例如,如果已启用,则在每次刷新时,服务将覆盖 RangeStart 和 RangeEnd 参数,以便对日期/时间在刷新周期之后的行创建一个查询,其开始时间取决于当前日期和时间。 包含日期/时间在当前刷新操作时间之后的行。 对于此类策略,我们可以期望服务中的 FactInternetSales 数据集表甚至包括最新的数据更新。

“仅刷新全天”可确保全天的所有行都包括在刷新操作中。 此设置是可选的,除非你启用“使用 DirectQuery 实时获取最新数据(仅限高级版)”设置。 假设计划每天凌晨 4:00 运行刷新。 如果在午夜到凌晨 4:00 之间的四个小时内数据源表中出现了新数据行,则你不希望考虑这些数据。 对于某些天数而言,石油天然气行业的每日桶数等一些业务指标毫无意义。 再比如刷新财务系统中的数据,其中前一个月的数据在该月的第 12 个公历日获得批准。 可将刷新周期设置为 1 个月,并安排在该月的第 12 天运行刷新。 例如,选中此选项后,系统将在 2 月 12 日刷新 1 月份的数据。

请注意,除非为非 UTC 时区配置了计划的刷新,否则服务中的刷新操作将在 UTC 时间运行,这可以决定有效日期和影响完整的周期。

“检测数据更改”设置可实现更多选择性刷新。 可选择用于仅标识和刷新数据更改日期的日期/时间列。 此操作假定数据源中存在通常用于审核的列。 这不应与用于使用 RangeStart 和 RangeEnd 参数对数据进行分区的列相同。 将针对增量范围中的每个周期评估此列的最大值。 如果自上次刷新后未更改,则无需刷新周期。 在本例中,这可能会将增量刷新的天数从 3 天进一步减少到 1 天。

当前的设计要求将用于检测数据更改的列保留并缓存到内存中。 以下技术可用于减少基数和内存占用量:

  • 刷新时仅保留此列的最大值(可能通过 Power Query 函数实现)。
  • 根据刷新频率要求,将精度降低到可接受的水平。
  • 请定义使用 XMLA 终结点来检测数据更改的自定义查询,并避免完全暂留列值。

在某些情况下,可以进一步增强启用“检测数据更改”选项。 例如,你可能需要避免在内存中缓存内保留“上次更新时间”列,或实现以下方案:由 ETL 进程准备配置/指令表,用于仅标记需要刷新的分区。 在这种情况下,对于高级容量,请使用表格模型脚本语言 (TMSL) 和/或表格对象模型 (TOM) 来替代检测数据更改行为。 若要了解详细信息,请参阅高级增量刷新 - 用于检测数据更改的自定义查询

发布

配置增量刷新策略后,可以将模型发布到服务。 发布完成后,可以对数据集执行初始刷新操作。

注意

只能将使用增量刷新策略以使用 DirectQuery 实时获取最新数据的数据集发布到 Premium 工作区。

对于发布到分配给高级容量的工作区的数据集,如果你认为数据集会超过 1 GB 或更大,则可以在服务中执行第一次刷新操作之前,启用较大的数据集存储格式,从而提高刷新操作的性能并确保数据集不会超出大小限制。 若要了解详细信息,请参阅 Power BI Premium 中的大型数据集

重要

发布到服务后,不能再将 PBIX 下载回来。

刷新

发布到服务后,对数据集执行初始刷新操作。 这应该是一个单独的(手动)刷新,便于你监视进度。 初始刷新操作可能需要很长时间才能完成。 必须创建分区,加载历史数据,生成或重新生成关系和层次结构等对象,并且计算对象也会被重新计算。

后续刷新操作(单个或计划刷新)速度要快得多,因为只会刷新增量刷新分区。 仍然需要执行其他处理操作,如合并分区和重新计算,但与最初的刷新相比,通常只需要很小的一部分时间。

自动刷新报表

对于利用数据集(使用增量刷新策略以使用 DirectQuery 实时获取最新数据)的报表,最好以固定间隔或基于更改检测启用自动页刷新,以便报表无延迟地包括最新的数据。 有关详细信息,请参阅 Power BI 中的自动页面刷新

高级增量刷新

如果你的数据集在启用了 XMLA 终结点的高级容量上,则可以对高级方案进一步扩展增量刷新。 例如,可以使用 SQL Server Management Studio 查看和管理分区、启动初始刷新操作或刷新追溯历史分区。 若要了解详细信息,请参阅使用 XMLA 终结点进行高级增量刷新

社区

Power BI 有一个充满活力的社区,在此社区中,MVP、BI 专业人员和同行在讨论组、视频、博客中分享专业知识。 在了解增量刷新时,请务必查看以下额外的资源:

后续步骤

配置数据集增量刷新
使用 XMLA 终结点进行高级增量刷新
排查增量刷新问题
数据流的增量刷新