语义模型的增量刷新和实时数据

  • 项目

增量刷新通过为经常加载新数据和更新数据的语义模型表提供自动化分区创建和管理功能，扩展了计划的刷新操作。 对于大多数模型来说，一个或多个表包含经常变化且呈指数级增长的事务数据，如关系数据库或星型数据库架构中的事实数据表。 对表进行分区的增量刷新策略，仅刷新最新导入分区且可以为实时数据使用另一个 DirectQuery 分区，可以显著减少必须刷新的数据量。 同时，此策略可确保数据源的最新更改包含在查询结果中。

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

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

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

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

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

Graphic representing a rolling window pattern.

增量刷新的优点是，服务将根据你定义的增量刷新策略为你处理所有操作。 事实上，进程和此模式创建的分区在服务中不可见。 在大多数情况下，一个明确定义的增量刷新策略是显著提高模型刷新性能的所有必要因素。 但是，实时 DirectQuery 分区仅支持高级容量中的模型。 Power BI Premium 还通过 XML for Analysis (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 参数中的日期/时间值，以匹配日期列的整数代理键。 若要了解详细信息，请参阅配置增量刷新 - 将日期/时间转换为整数。

对于其他数据源，RangeStart 和 RangeEnd 参数必须以某种允许筛选的方式传递给数据源。 对于按日期组织文件和文件夹的基于文件的数据源，RangeStart 和 RangeEnd 参数可用于筛选文件和文件夹，以选择要加载的文件。 对于基于 Web 的数据源，RangeStart 和 RangeEnd 参数可以集成到 HTTP 请求中。 例如，以下查询可用于从 AppInsights 实例增量刷新跟踪：

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

配置增量刷新时，将对数据源执行包含基于 RangeStart 和 RangeEnd 参数的日期/时间筛选器的 Power Query 表达式。 如果在初始源查询后的查询步骤中指定了筛选器，则查询折叠将初始查询步骤与引用 RangeStart 和 RangeEnd 参数的步骤相结合至关重要。 例如，在以下查询表达式中，Table.SelectRows 将折叠，因为它紧跟 Sql.Database 步骤，SQL Server 支持折叠：

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

最终查询无需支持折叠。 例如，在以下表达式中，我们使用非折叠 NativeQuery，但将 RangeStart 和 RangeEnd 参数直接集成到 SQL 中：

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

然而，如果增量刷新策略包括使用 DirectQuery 获取实时数据，则无法使用非折叠转换。 如果它是不包含实时数据的纯导入模式策略，则查询糅合引擎可能会在本地补偿筛选器并应用筛选器，这需要从数据源中检索表的所有行。 这可能会导致增量刷新速度变慢，并且此进程可能会耗尽 Power BI 服务或本地数据网关上的资源，这实际上违背了增量刷新的本意。

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

Screenshot of the 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:00 刷新并指定时区，将根据太平洋时间确定当前日期和时间，而不是协调世界时 (UTC)（若根据后者确定，则当前时间将晚一天）。 不通过 Power BI 服务调用的刷新操作（如 TMSL 刷新命令）不考虑计划的刷新时区。

Screenshot of Scheduled refresh dialog showing the Time zone input field

配置增量刷新和实时数据

此部分介绍有关配置增量刷新和实时数据的重要概念。 如果已准备好了解更详细的分步说明，请参阅配置语义模型的增量刷新和实时数据。

配置增量刷新是在 Power BI Desktop 中完成的。 对于大多数模型，只需要完成几个任务。 不过，请记住下列几点：

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

创建参数

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

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

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

筛选数据

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

Screenshot of column context menu with Custom Filter selected

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

定义策略

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

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

表

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

必需设置

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

例如，如果你指定五年，则表会将过去五年的历史数据存储在年份分区中。 该表还将包含季度、月份或日分区中当前年份的行，直至并包括刷新周期。

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

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

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

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

可选设置

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

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

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

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

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

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

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

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

发布

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

注意

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

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

重要

在 Power BI Desktop 将模型发布到服务后，你无法重新下载该 .pbix。

刷新

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

后续刷新操作（单个或计划刷新）速度要快得多，因为只会刷新增量刷新分区。 仍然需要执行其他处理操作，如合并分区和重新计算，但与初始刷新相比，通常只需要很少时间。

自动刷新报表

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

高级增量刷新

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

社区

Power BI 有一个充满活力的社区，在此社区中，MVP、BI 专业人员和同行在讨论组、视频、博客等平台分享专业知识。 在了解增量刷新时，请参阅以下资源：

相关内容