Snowflake warehouse 频繁 suspension 与 resumption 的 Credit 计费

结论

如果 warehouse 运行 10 秒后完成 suspend，随后重新 resume 并再运行 10 秒，计算型 Credit 会按 120 秒计费：

[ 60\text{ 秒} + 60\text{ 秒} = 120\text{ 秒} ]

每次 resume 都会触发新的 warehouse provision，而每次 provision 都有独立的 60 秒最低计费周期。第一次运行不足 60 秒时，已付费但未运行的时间不会延续到下一次 resume。

计费逻辑

每个连续运行区间需要单独计算：

[ \text{计费秒数}=\sum_{i=1}^{n}\max(\text{该次连续运行秒数}, 60) ]

因此：

假设 warehouse 的小时费率为 (R) Credits，该场景消耗的计算 Credit 为：

[ R \times \frac{120}{3600}=R\times\frac{1}{30} ]

例如，某个 warehouse 的费率为 2 Credits/小时，两次各运行 10 秒会产生：

[ 2\times\frac{120}{3600}=0.0667\text{ Credits} ]

实际货币成本还需乘以账户对应的 Credit 单价。

如何理解“第一分钟内停止并重启不改变计费金额”

这句话的意思是，第一次启动产生的 60 秒最低费用不会因为提前 suspend 而减少。它不表示已经付费但未实际运行的秒数可以转移到下一次 resume。

warehouse 完成 suspend 后，当前连续运行区间随之结束。之后再次 resume 会触发新的 provision，并重新产生 60 秒最低计费。

文档中的“运行 61 秒，停止后再次运行不足 60 秒，共计 121 秒”也遵循这一规则：

[ 61 + 60 = 121\text{ 秒} ]

同理，两次各运行 10 秒的计费时间为：

[ \max(10,60)+\max(10,60)=120\text{ 秒} ]

如何核对实际 Credit 消耗

可以通过 WAREHOUSE_METERING_HISTORY 查看 warehouse 的计量记录：

SELECT
    start_time,
    end_time,
    warehouse_name,
    credits_used_compute,
    credits_used_cloud_services,
    credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'MY_WAREHOUSE'
  AND start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP())
ORDER BY start_time;

如果需要查看更及时的数据，也可以使用 Information Schema 中对应的表函数：

SELECT
    start_time,
    end_time,
    warehouse_name,
    credits_used_compute,
    credits_used_cloud_services,
    credits_used
FROM TABLE(
    INFORMATION_SCHEMA.WAREHOUSE_METERING_HISTORY(
        DATE_RANGE_START => DATEADD('hour', -1, CURRENT_TIMESTAMP()),
        WAREHOUSE_NAME   => 'MY_WAREHOUSE'
    )
)
ORDER BY start_time;

计量记录通常按时间段聚合，因此不一定会直接显示“本次 resume 被计费 60 秒”。验证时应隔离其他查询，并比较测试前后的 CREDITS_USED_COMPUTE。

减少频繁启停带来的额外费用

如果工作负载会以几十秒的间隔连续到达，过短的 AUTO_SUSPEND 可能导致 warehouse 反复 provision，多次触发最低计费。可以根据查询的到达间隔，适当延长自动暂停时间：

ALTER WAREHOUSE MY_WAREHOUSE SET
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE;

合适的值不一定是 60 秒，需要比较以下两类成本：

• warehouse 保持空闲运行时产生的按秒费用；
• suspend 后再次 resume 产生的新一轮 60 秒最低费用和启动延迟。

注意事项

上述结论有一个前提：warehouse 已经真正完成 suspend，后续 resume 确实触发了新的 provision。如果 suspend 与 resume 请求间隔很短，warehouse 实际上还没有完成关闭，就不能直接按两个独立运行周期计算。

此外，这里的 60 秒最低计费主要针对 warehouse compute。CREDITS_USED_CLOUD_SERVICES、多集群 warehouse、扩容或向更大 size resize 都可能产生额外计量，因此不能只根据单个 warehouse 的两段运行时间推算全部账单。

备注：内容仅供参考。