了解动态表的成本

本主题概述了与动态表相关的计算和存储成本。有关 Snowflake 成本的一般信息，请参阅 了解总体费用。

计算成本

有两种计算成本与动态表相关：虚拟仓库和云服务计算。

动态表至少需要一个 虚拟仓库 才能执行 刷新。如果您想将不同操作的计算成本分开，可以选择分配第二个仓库。有关更多信息，请参阅 了解动态表的仓库使用情况。

动态表刷新会消耗 计算 Credit，其刷新频率由配置的 目标滞后 决定：较低的目标滞后值会触发更频繁的刷新，从而产生更高的计算成本。

动态表还需要 云服务计算 资源来识别底层基表对象的变化，并确定是否必须运行虚拟仓库。如果云服务计算未检测到任何更改，则不会消耗虚拟仓库的计算 Credit，因为没有新数据需要刷新。如果确实存在更改（即使这些更改随后被动态表查询过滤掉），虚拟仓库仍会使用 Credit，因为动态表必须通过刷新来评估这些更改是否适用。

如果关联的虚拟仓库已暂停，且云服务计算未检测到基表有任何更改，则仓库将保持暂停状态，动态表不会消耗任何 Credit。当云服务计算识别出基表中的更改时，相应的仓库会自动恢复运行。如果这些更改支持增量刷新，则动态表将使用 WAREHOUSE 参数进行刷新。如果需要重新初始化（例如，由于基表架构发生了更改），动态表将使用 INITIALIZATION_WAREHOUSE 执行完全重新初始化。有关动态表如何自动暂停的信息，请参阅 自动动态表暂停。

查看虚拟仓库 Credit 的使用情况

要检查动态表刷新是否使用了虚拟仓库 Credit，请使用 Snowsight 中的 Refresh History 选项卡：

  1. 在导航菜单中，选择 Transformation » Dynamic tables。

  2. 选择动态表，然后选择 Refresh History 选项卡。

  3. 要查看使用了仓库进行更新的刷新记录，请选中 Warehouse used only 复选框。

小技巧

为了更好地了解与动态表管道相关的成本，Snowflake 建议您使用专用仓库对动态表进行测试。这样，您就可以隔离归因于动态表的虚拟仓库使用量。在建立成本基准后，您可以将动态表移动至共享仓库。

有关更多信息，请参阅 了解动态表的仓库使用情况。

计算不变性约束的成本

如果您使用了 IMMUTABLE WHERE 约束，Snowflake 仅会重新计算不符合不可变条件的行，这有助于降低重新初始化成本。在可能发生重新初始化的情况下，这一特性尤其有用，例如以下场景：

  • 重新创建上游表或视图。

  • 上游数据治理策略发生变化。

  • 在故障转移组中切换到辅助区域。

使用 IMMUTABLE WHERE 约束有助于降低增量刷新和全量刷新的成本，因为该约束会忽略与其谓词匹配的更改和数据。

向动态表添加不可变约束不会触发额外的计算，但删除这些约束会触发，因为这会导致在下次刷新时进行 重新初始化。修改 IMMUTABLE WHERE 约束中的谓词可能会触发重新初始化，这取决于 Snowflake 是否能确定原条件返回的行在新条件下仍然返回。

例如，以下修改不会触发重新初始化：

  • 从 (ts < CURRENT_TIMESTAMP() - INTERVAL '2 days') 改为 (ts < CURRENT_TIMESTAMP() - INTERVAL '1 days')

  • 从 (year <= 2023) 改为 (year <= 2024)

以下修改会触发重新初始化：

  • 从 (ts < '2025-01-02') 改为 (ts < '2025-01-01')

  • 从 (year < 2024) 改为 (month < 10)

存储成本

动态表需要存储空间来存储物化的结果。与常规表类似，Time Travel、故障安全存储和克隆功能可能会产生额外的存储成本。

动态 Apache Iceberg™ Tables 不会产生 Snowflake 存储成本。有关更多信息，请参阅 计费。

本节讨论动态表的以下存储考虑事项：

有关此存储如何产生成本的详细信息，请参阅 了解存储成本 和 数据存储注意事项。

Time Travel 和故障安全存储

通过 Snowflake Time Travel，您可以访问和查询动态表在特定时间点的历史版本，这有助于分析数据中的历史趋势、变化和异常。

频繁刷新会增加 Time Travel 数据的积累，从而增加总体存储使用量。有关更多信息，请参阅 了解和使用 Time Travel。

故障安全功能有助于保护动态表，避免数据丢失或损坏。根据所配置的故障安全期，您可能要支付额外的存储费用。

动态表的复制

功能支持的区域

此功能在中华人民共和国不可用。

动态表支持跨账户、跨区域复制，这使您可以将数据从主数据库复制到辅助数据库，以便进行灾难恢复或数据共享。它既可以用作灾难恢复的故障转移准备策略，也可以用作各只读部署的共享数据方式。使用动态表进行复制会产生 复制成本。有关更多信息，请参阅 复制和动态表。

暂停的动态表

暂停的动态表不会产生标准存储费以外的额外费用，也不会消耗计算资源。如果您有持续运行的维护任务或计划作业与已暂停的表进行交互，动态表仍可能消耗计算资源。

瞬态动态表

Snowflake 支持 瞬态 动态表，与常规表类似，这些表会一直保留到显式删除为止，并且可供具有适当权限的所有用户使用，没有故障安全期。瞬态动态表最适合存储瞬态数据，即不需要永久表所提供的相同级别的数据保护和恢复的数据。使用此类表可以帮助您节省故障安全存储的存储费用。

用于增量刷新操作的额外存储

对于增量刷新操作，动态表会维护一个额外的内部元数据列，用于标识表中的每一行。内部行标识符每行都会消耗恒定的存储量，并且存储成本按表中的行数线性增加，与列数无关。

对于列很少的表，与同等 CTAS 表相比，存储空间可能会增加很多，甚至占据主导地位。在较宽的动态表中，这种效果不会那么明显。

刷新计划成本

动态表刷新（无论是 完整刷新还是增量刷新）的计划会影响其总成本。本节讨论了在确定刷新计划时要考虑的因素（假设每次刷新均包含数据变更）：

备注

如果来源没有改变，刷新的成本相对较低。有关更多信息，请参阅 :ref:`label-dt_costs_compute`（本主题内容）。

完整刷新计划

完整刷新的成本通常取决于动态表扫描的数据量及其刷新频率。为了节省成本，您可以仅在需要时刷新动态表；例如，在非营业时间暂停动态表。要精确控制时间，请为动态表设置 下游目标延迟，并使用 任务 中的 手动刷新 自动执行自定义计划。

增量刷新计划

增量刷新的成本通常与源对象的更改量成正比，外加一些固定开销。

如果开销较低，可以设置较高的刷新频率，而不会造成太多不利影响。这意味着，您可以经常刷新以获得更好的结果。例如，一个简单的 SELECT ... FROM ... WHERE 动态表仅处理在两次刷新之间发生更改的行，这可以将开销控制在最低限度，并且该动态表可以在额外成本较低的情况下频繁运行。

如果开销较高，则必须在高刷新频率的 Credit 使用情况和新鲜度带来的业务收益之间找到平衡。例如，在有联接的动态表中，必须将一个表的变更与另一个表进行联接。无论改动的幅度有多小，这种联接通常仍会有无法避免的最低限度执行成本。如果此开销很高，则成本会随着刷新频率的增加而累积。

要减少开销并优化增量刷新性能，请参阅 优化增量刷新查询。