Understanding costs for dynamic tables¶
本主题概述了与动态表相关的计算和存储成本。有关 Snowflake 成本的一般信息，请参阅 了解总体费用。
Compute costs¶
有两种计算成本与动态表相关：虚拟仓库和云服务计算。
动态表至少需要一个 虚拟仓库 才能执行 刷新。如果您想将不同操作的计算成本分开，可以选择分配第二个仓库。有关更多信息，请参阅 了解动态表的仓库使用情况。
Dynamic table refreshes consume compute credits, and their frequency is determined by the configured target lag: lower target lag values trigger more frequent refreshes and therefore higher compute costs.
Dynamic tables also require Cloud Services compute to identify changes in underlying base objects and determine whether a virtual warehouse must run. If Cloud Services compute finds no changes, no warehouse compute credits are consumed because there's no new data to refresh. If changes do exist, even if the dynamic table query filters them, the virtual warehouse consumes credits because the dynamic table refreshes to evaluate whether those changes apply.
如果关联的虚拟仓库已暂停，且云服务计算未检测到基表有任何更改，则仓库将保持暂停状态，动态表不会消耗任何 Credit。当云服务计算识别出基表中的更改时，相应的仓库会自动恢复运行。如果这些更改支持增量刷新，则动态表将使用 WAREHOUSE 参数进行刷新。如果需要重新初始化（例如，由于基表架构发生了更改），动态表将使用 INITIALIZATION_WAREHOUSE 执行完全重新初始化。有关动态表如何自动暂停的信息，请参阅 自动动态表暂停。
查看虚拟仓库 Credit 的使用情况¶
要检查动态表刷新是否使用了虚拟仓库 Credit，请使用 Snowsight 中的 Refresh History 选项卡：
In the navigation menu, select Transformation » Dynamic tables.
选择动态表，然后选择 Refresh History 选项卡。
要查看使用了仓库进行更新的刷新记录，请选中 Warehouse used only 复选框。
小技巧
To better understand costs related to your dynamic table pipelines, Snowflake recommends that you test dynamic tables by using dedicated warehouses. This way, you can isolate the virtual warehouse consumption that is attributed to dynamic tables. You can move your dynamic tables to a shared warehouse after you establish a cost baseline.
有关更多信息，请参阅 了解动态表的仓库使用情况。
计算不变性约束的成本¶
If you use the IMMUTABLE WHERE constraint, Snowflake recomputes only the rows that don’t match the immutability condition, which helps reduce reinitialization costs. This is useful in situations where reinitialization can occur, such as the following scenarios:
重新创建上游表或视图。
上游数据治理策略发生变化。
在故障转移组中切换到辅助区域。
Using the IMMUTABLE WHERE constraint can help you reduce the cost of incremental and full refresh because the constraint ignores changes and data that match its predicate.
Adding immutability constraints to a dynamic table doesn’t trigger extra computation, but removing them does because it causes reinitialization on the next refresh. Modifying the predicate in an IMMUTABLE WHERE constraint might trigger reinitialization depending on whether Snowflake can determine the rows that are returned with the original condition are still returned with the new condition.
例如，以下修改不会触发重新初始化：
从
(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)
存储成本¶
Dynamic tables require storage to store the materialized results. Similar to regular tables, you might incur additional storage cost for Time Travel, fail-safe storage, and cloning features.
Dynamic Apache Iceberg™ tables don't incur Snowflake storage costs. For more information, see 计费.
本节讨论动态表的以下存储考虑事项：
有关此存储如何产生成本的详细信息，请参阅 了解存储成本 和 数据存储注意事项。
Time Travel 和故障安全存储¶
With Snowflake Time Travel, you can access and query historical versions of dynamic tables at specific points in time, which can help provide insights into historical trends, changes, and anomalies in your data.
频繁刷新会增加 Time Travel 数据的积累，从而增加总体存储使用量。有关更多信息，请参阅 了解和使用 Time Travel。
故障安全功能有助于保护动态表，避免数据丢失或损坏。根据所配置的故障安全期，您可能要支付额外的存储费用。
动态表的复制¶
Dynamic tables support cross-account, cross-region replication, which lets you copy data from a primary database to a secondary database for either disaster recovery or data sharing. It can serve as either a failover preparation strategy for disaster recovery or as a means of sharing data across deployments for read-only purposes. Using replication with dynamic tables is subject to replication costs. For more information, see 复制和动态表.
暂停的动态表¶
Suspended dynamic tables don't incur additional costs beyond standard storage fees and don't consume compute resources. If you have ongoing maintenance tasks or scheduled jobs that interact with the suspended table, your dynamic tables might consume compute resources.
瞬态动态表¶
Snowflake supports transient dynamic tables, similar to regular tables, that persist until explicitly dropped, and are available to all users with the appropriate privileges without a fail-safe period. Transient dynamic tables are best used for transitory data that doesn't need the same level of data protection and recovery that permanent tables provide. Using them helps you save on storage charges for fail-safe storage.
用于增量刷新操作的额外存储¶
For incremental refresh operations, dynamic tables maintain an additional internal metadata column for identifying each row within the table. Internal row identifiers consume a constant amount of storage per row and increase storage cost linearly to the number of rows in the table, independent of the number of columns.
对于列很少的表，与同等 CTAS 表相比，存储空间可能会增加很多，甚至占据主导地位。在较宽的动态表中，这种效果不会那么明显。
刷新计划成本¶
The schedule at which a dynamic table refreshes, whether full or incremental, has an effect on its overall cost. This section discusses the factors that you should consider when you decide on a refresh schedule, with the assumption that every refresh is non-empty:
备注
如果来源没有改变，刷新的成本相对较低。有关更多信息，请参阅 :ref:`label-dt_costs_compute`（本主题内容）。
完整刷新计划¶
The cost of a full refresh typically depends on how much data your dynamic table scans and how often it refreshes. To save on costs, you can refresh your dynamic tables only when you need to; for example, you can suspend your dynamic tables outside of business hours. For precise timing control, set the downstream target lag for your dynamic tables and use manual refresh from a task to automate your custom schedules.
增量刷新计划¶
The cost of an incremental refresh is typically proportional to the volume of changes in the source objects, plus some fixed overhead.
If the overhead is low, you can set a high refresh frequency without much downside. This means that you can refresh often for best results.
For instance, a simple SELECT ... FROM ... WHERE dynamic table only processes changed rows between refreshes, which has minimal
overhead and the dynamic table can run frequently at low added cost.
If the overhead is high, you must balance the credit consumption of high refresh frequency with the business benefits of freshness. For example, in a dynamic table with a join, you must join the changes in one table with the other table. No matter how small the set of changes, this join usually involves a minimum cost for you to execute. If this overhead is significant, it can accumulate as the refresh frequency increases.