关于每日Clone Snowflake生产库替代90天Time Travel的可行性问询

一、是否能节省90天Time Travel的存储成本？ #

• 答案是能，但有前提：Snowflake的Time Travel存储按历史数据增量计费，原本生产库开启90天Time Travel需要留存90天的快照与变更日志。若改为每日克隆生产库，同时将生产库的Time Travel调整为1天，生产侧的历史存储开销会大幅降低——无需再保留90天的旧数据快照。
• 需注意：若克隆的测试库仅作只读使用，不会产生额外存储成本（Snowflake克隆为零拷贝机制）；但如果测试环境需要修改数据（如插入测试数据、删除数据），这部分修改产生的新数据会单独占用存储资源，需计入成本核算。

二、方案的遗漏点 #

• 数据一致性风险：克隆全量库需在生产库低峰期执行，若克隆过程中生产库有数据写入，可能导致克隆库数据不一致（部分表为最新数据、部分为快照时刻数据）。需使用指定时间点克隆的方式，比如CLONE my_prod_db AT(OFFSET => -300)（克隆5分钟前的快照），确保数据一致性。
• 权限配置不同步：生产库的角色、用户、权限策略不会自动同步到克隆库，需编写脚本定期同步权限，否则测试人员可能出现无法访问或权限异常的问题。
• 测试自定义对象会被覆盖：若测试环境自建了测试用的存储过程、视图或表，次日全量克隆时这些自定义对象会被覆盖。需将自定义对象放在单独的Schema中，与生产同步的Schema分离。
• 跨天故障恢复受限：若生产库在克隆完成到次日克隆前发生数据损坏（如误删），仅靠生产库1天的Time Travel和克隆库1天的Time Travel，无法恢复到更早时间点（如3天前）的数据。若业务需要回溯更早数据，需额外补充冷备机制，比如定期将数据导出到外部存储，或使用Snowflake外部快照。
• 克隆操作的性能开销：全量克隆大型生产库会占用计算资源，可能影响生产库的查询性能。需评估克隆操作的时长与资源消耗，建议使用专用Warehouse执行克隆，避免与生产查询抢占资源。
• 合规留存风险：若业务有合规要求（如需保留90天历史数据用于审计），该方案可能无法满足——生产库仅留存1天Time Travel，克隆库未保留历史快照，超过90天后将无法追溯旧数据。需确认克隆后的库是否能满足合规留存要求，或额外备份历史数据。

内容的提问来源于stack exchange，提问作者Iory