了解动态表初始化和刷新¶

动态表的内容由查询定义，并在基础数据发生变化时自动更新，这种更新被称为刷新。此过程会分析查询，以使表保持最新状态。

以下各部分更详细地解释了动态表刷新：

部分	描述
了解动态表初始化	介绍初始化，换句话说，即创建动态表时的数据初始填充。您可以指定何时进行初始刷新。
了解手动和计划刷新选项	动态表刷新的概述。动态表根据计划刷新，除非手动刷新。
动态表刷新模式	动态表支持多种刷新模式：增量、完全和 AUTO。
当动态表依赖于其他动态表时数据如何刷新	了解动态表如何根据其依赖关系进行刷新。
了解对基表中的列所做的变更造成的影响

了解动态表初始化¶

当您创建一个动态表时，其初始刷新会在创建时同步发生或按照计划时间发生。初始数据填充或初始化取决于此初始刷新发生的时间。

动态表基于指定的目标滞后进行刷新，该滞后设置了基表更新与动态表内容更新之间的最大允许滞后。如果设置 INITIALIZE = ON_CREATE``（默认），则会立即初始化该表。如果设置 ``INITIALIZE = ON_SCHEDULE，则初始化将在指定的目标滞后时间范围内发生。

例如，假设一个动态表名为 DT1，其目标滞后为 30 分钟。DT1 的初始数据填充可能如下进行：

如果 DT1 设置为在创建时同步刷新 (ON_CREATE)，则会在创建时初始化。
如果 DT1 设置为在计划时间刷新 (ON_SCHEDULE)，则它将在 30 分钟内初始化。

在具有下游依赖关系的场景中，刷新行为取决于依赖关系。例如，如果动态表 DT1 具有一个下游目标滞后，且依赖于 DT1 的 DT2 具有 30 分钟的目标滞后，那么 DT1 仅在 DT2 刷新时刷新。

对于 DT1：

如果设置为在创建时同步刷新，它将立即初始化。如果初始化失败，则创建过程将停止，对任何错误提供即时反馈。
如果设置为在计划时间刷新，则初始化取决于 DT2 刷新时间。

初始化可能需要一些时间，具体取决于扫描的数据量。要跟踪进度，请参阅动态表创建故障排除。

了解手动和计划刷新选项¶

动态表按目标滞后确定的计划进行刷新。每次读取动态表时，数据的新鲜度都应在目标滞后定义的时间范围内。

您可以使用 ALTER DYNAMIC TABLE ... REFRESH 命令或 Snowsight 手动刷新动态表以获取最新数据。有关更多信息，请参阅手动刷新动态表。

动态表刷新超时由 STATEMENT_TIMEOUT_IN_SECONDS 参数控制，该参数设置在账户或仓库级别上刷新自动取消前的最大允许持续时间。

目标滞后如何影响计划刷新¶

目标滞后控制计划刷新的频率。要手动管理刷新，请将动态表的目标滞后设置为 DOWNSTREAM，并确保所有下游动态表也设置为 DOWNSTREAM。

将整个有向无环图 (DAG) 的目标滞后设置为 DOWNSTREAM，实际上会禁用计划刷新，因为最终的动态表会控制刷新计划。如果没有动态表具有基于时间的目标滞后，则管道的计划刷新将被暂停。在这种情况下，手动刷新最下游的表会自动刷新所有上游依赖关系。

将目标滞后设置为 DOWNSTREAM 不会指定确切的时间。相反，Snowflake 会选择一个刷新频率，尝试将滞后保持在目标值以下。例如，目标滞后为 4 小时的动态表可能每 3.5 小时刷新一次。

要指定确切的时间，您可以将任务与 CRON 计划配合使用。有关更多信息，请参阅手动刷新动态表。

动态表刷新模式¶

动态表支持三种刷新模式：自动、增量和完全。您可以将刷新模式设置为 AUTO，也可以显式指定：

AUTO 刷新模式： 当您使用 AUTO 参数时，Snowflake 会根据查询复杂性、支持的结构、运算符、函数和预期性能，自动选择成本和时间效率最高的刷新模式。该决策仅在表创建时做出一次。如果增量刷新不受支持或效率低下，Snowflake 会改为选择完全刷新。

例如，如果动态表引用了一个视图，而该视图的定义异步发生了变化，刷新模式将保持不变。如果最初的决策是增量刷新，但后来因上游视图变化而不再受支持，刷新将失败，并出现类似以下错误：Dynamic table can no longer be refreshed incrementally because an upstream view changed.

要更改刷新模式，需要使用 CREATE OR REPLACE DYNAMIC TABLE 命令重新创建动态表。
增量刷新： 此模式会分析动态表的查询，并计算自上次刷新以来的变更。然后它会将这些变更合并到表中。
完全刷新模式： 此模式会执行动态表的查询，并完全替换先前实现的结果。

有关何时使用增量刷新与完全刷新的指导，请参阅选择刷新模式。要查看现有动态表使用哪种刷新模式，请参阅刷新模式。

重要

增量刷新模式下的动态表不能是完全刷新模式下动态表的下游。这是因为增量刷新模式不兼容上游完全刷新表每次刷新时发生的完整行变更。

当动态表依赖于其他动态表时数据如何刷新¶

当动态表的滞后被设置为时间量度时，自动刷新流程会安排刷新，以更好地满足目标滞后时间。

为了在一个动态表依赖于另一个动态表的情况下保持数据一致，该过程会在合适的时间刷新账户中的所有动态表。刷新频率较低的时间与刷新频率较高的时间相吻合。如果刷新时间过长，调度程序可能会跳过刷新，以尽量保持最新状态。但是，快照隔离仍会保留。

例如，假设动态表 DT1 的目标滞后为两分钟，而查询动态表 DT2 的目标滞后为一分钟。该过程可能会确定 DT1 应每 96 秒刷新一次，而 DT2 应每 48 秒刷新一次。因此，该过程可能会采用以下时间表：

具体时间点	刷新的动态表
2022-12-01 00:00:00	DT1、DT2
2022-12-01 00:00:48	DT2
2022-12-01 00:01:36	DT1、DT2
2022-12-01 00:02:24	DT2

动态表的目标滞后不能短于其所依赖的动态表的目标滞后。例如，假设：

DT1 查询动态表 DT2 和 DT3。
DT2 目标滞后为五分钟。
DT3 目标滞后为一分钟。

这意味着 DT1 的目标滞后时间不得短于五分钟（即，不得短于 DT2 和 DT3 的滞后时间中较长的一个）。

如果将 DT1 的滞后设置为五分钟，该过程将设置具有以下目标的刷新时间表：

经常刷新 DT3，使其滞后短于一分钟。
经常同时刷新 DT1 和 DT2，使它们的滞后短于五分钟。
确保 DT1 和 DT2 的刷新在时间上与 DT3 的刷新相吻合，以确保快照隔离。

重要

增量刷新模式下的动态表不能是完全刷新模式下动态表的下游。这是因为增量刷新模式不兼容上游完全刷新表每次刷新时发生的完整行变更。

快照隔离¶

当动态表刷新时，它会通过 Time Travel 将所有上游依赖关系的数据时间戳统一起来，以确保状态的一致性。

对于非动态基表，Time Travel 功能照常运行，即查看“挂钟”提交时间。这意味着动态表的内容始终与基表中数据的“快照”一致。

对于上游动态表，Snowflake 会查找标有该数据时间戳的特定表版本。这可确保下游表始终与其上游表保持一致。您无需协调刷新计划或担心不同步延迟；Snowflake 会自动对快照进行对齐，以确保整个管道中的数据完整性。

使用手动 SELECT 语句联接多个动态表时，无法保证快照隔离，因为临时查询使用每个表的当前版本。由于每个动态表独立提交刷新，因此即使动态表具有相同的目标滞后或上游刷新延迟，手动联接也可能会获取不同的刷新状态。这意味着结果可能无法反映基础数据的单个一致快照。

了解对基表中的列所做的变更造成的影响¶

当与动态表关联的基础对象发生变更时，将适用以下行为：

变更	影响
新列已添加到基表。已移除基表中现有未使用的列。	无。如果将新列添加到基表中或删除了未使用的列，则不会发生任何操作，并且刷新会像之前一样继续进行。
使用相同的列名称和类型重新创建基础基表。使用相同的名称和类型重新创建基础基表列。对具有增量刷新的动态表的底层基表策略进行了更改。	重新初始化：重新创建后的第一次刷新被称为初始化。
对使用 `SELECT *` 从基表创建的动态表进行基表更改。	动态表将刷新失败，必须重新创建才能响应更改。
对使用列定义创建的动态表进行基表更改。	对动态表没有影响。