PowerBI - 配置增量刷新

转载

mob604756f79c64 2021-07-12 17:31:00

参考官网教程：
https://docs.microsoft.com/zh-cn/power-bi/connect-data/incremental-refresh-overview#supported-data-sources

支持的数据源

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

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

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

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

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

时间限制

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

防止初始完全刷新超时

发布到服务后，针对数据集的初始完全刷新操作将为增量刷新策略中定义的整个周期创建分区，并加载和处理历史数据。对于将加载和处理大量数据的某些数据集，初始刷新操作所需的时间可能会超过服务所施加的刷新时间限制或数据源施加的查询时间限制。

为了防止超时，在将模型发布到服务之前，可以启动初始刷新操作。通过启动，服务可以为数据集创建表和分区对象，但不会将历史数据加载到任何分区中并进行处理。发布时，对数据集执行初始刷新操作，为所有表创建表和分区对象，但只为那些没有被启动的表加载数据。随后会删除启动。然后，通过 XMLA 终结点，使用 SSMS 选择性地处理分区。根据要为每个分区加载的数据量，可能需要按顺序或小批量处理每个分区，以降低其中一个或多个分区导致超时的可能性。

例：如何为 FactInternetSales 表定义增量刷新策略
在将模型发布到服务之前，在 Power Query 编辑器中，向 ProductKey 列添加另一个筛选器，以筛选出任何非 0 的值。这会有效地筛选出 FactInternetSales 表中的所有数据。

在 Power Query 编辑器中单击“关闭并应用”，定义增量刷新策略，并保存模型后，我们将模型发布到服务。然后，在服务中对数据集运行初始刷新操作。

FactInternetSales 表分区是根据策略创建的，但是没有数据被加载和处理，因为所有数据都被筛选掉了。初始刷新操作完成后，请返回 Power Query 编辑器，ProductKey 列上的其他筛选器已被删除。在 Power Query 编辑器中单击“关闭并应用”并保存模型后，模型将不会再次发布，因为它将覆盖增量刷新策略设置，并在从服务执行后续刷新操作时强制对数据集执行完全刷新。

配置增量刷新

配置增量刷新是在 Power BI Desktop 中完成的。请注意以下几个方面：

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

创建参数

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

筛选数据

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

定义策略

在应用筛选器并将数据子集加载到模型后，可以为表定义增量刷新策略。将模型发布到服务后，服务将使用该策略来创建和管理表分区，并执行刷新操作。

定义策略时，有三个必需的设置和两个可选设置：

1 - 表

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

2 - 存储以下时间内的行: 过去

这个必需的设置用于确定一个历史周期，在这个周期内的日期/时间的行被包含在数据集中，加上当前不完整的历史周期的行，加上直至当前日期和时间的刷新周期的行。

3 - 刷新以下时间内的行: 过去

这个必需的设置确定了增量刷新周期，日期/时间在此周期内的所有行都包含在刷新分区中，并在执行每次刷新操作时刷新。

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

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

4 - 检测数据更改

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

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

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

5 - 仅刷新全天

此设置是可选的。假设计划每天凌晨 4:00 运行刷新。如果在午夜到凌晨 4:00 之间的四个小时内数据源表中出现了新数据行，则你可能不希望考虑这些数据。对于某些天数而言，石油天然气行业的每日桶数等一些业务指标毫无意义。再比如刷新财务系统中的数据，其中前一个月的数据在该月的第 12 个公历日获得批准。可将刷新周期设置为 1 个月，并安排在该月的第 12 天运行刷新。例如，选中此选项后，系统将在 2 月 12 日刷新 1 月份的数据。

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