关于Snowflake Stream消费机制与数据一致性的技术咨询

1. CTAS执行期间父表新增数据的归属 #

当执行CREATE TABLE AS SELECT * FROM telemetry_data_stream;时，事务启动瞬间就会锁定流的可见数据范围——此时父表中所有未被消费的变更会被纳入本次CTAS的结果集，而CTAS执行期间（比如3秒）父表新增的数据，不会出现在新创建的表中，会被流捕获并保留在流的后续版本里，等待下一次消费。

2. 数据丢失风险与规避方案 #

正常使用CTAS消费流的场景下，不存在数据丢失风险，因为Snowflake流的消费逻辑具备原子性：

• 如果CTAS事务成功提交，流的偏移会自动推进到事务启动时的位置，确保后续消费只处理新的变更；
• 如果CTAS事务失败（比如执行出错），流的偏移不会推进，未消费的变更会被保留，可重新执行消费操作。

若要规避潜在的极端风险，需注意以下几点：

• 避免多独立事务同时消费同一个流：多个并行消费事务会看到相同的未消费变更，首个提交的事务会推进偏移，后续事务将无法获取已被消费的变更（不会丢失，但可能导致重复消费或逻辑混乱），建议通过单任务（Task）或串行消费流程确保唯一消费者；
• 调整流的数据保留期：默认流的保留期为14天，若消费间隔较长，可通过ALTER STREAM telemetry_data_stream SET DATA_RETENTION_TIME_IN_DAYS = 30;延长保留期，避免未消费的变更被自动清理；
• 禁止对父表执行重置变更跟踪的操作：TRUNCATE TABLE或ALTER TABLE telemetry_data SET CHANGE_TRACKING = OFF会直接失效流，导致未消费的变更永久丢失，需严格避免此类操作。

3. 流偏移的推进时机与并发读写管理机制 #

• 流偏移推进时机：流的偏移是在消费事务成功提交时推进的。事务启动时，流会记录当前的变更快照点（即未消费变更的截止位置），事务执行期间的新变更会被持续捕获，但不会被纳入本次消费范围；只有当事务成功提交后，流的偏移才会更新到之前记录的快照点，确保已消费的变更不会被重复读取。
• 并发读写管理：Snowflake流基于父表的变更跟踪功能实现，父表的写入操作（INSERT/UPDATE/DELETE）会被实时捕获并存储在变更日志中，与消费操作完全解耦。消费事务不会阻塞父表的写入，写入操作也不会干扰消费事务的可见数据范围——两者各自独立执行，流会确保所有变更都被捕获，直到被消费或超过保留期。

4. 验证数据完整性的方法 #

若要验证持续写入时是否存在数据丢失，可通过以下方式：

• 给父表的每条记录添加精确到毫秒的时间戳字段（比如INSERT INTO telemetry_data VALUES (... CURRENT_TIMESTAMP())）；
• 执行CTAS消费流前，记录当前的系统时间；
• 消费完成后，检查新表中的最大时间戳是否等于消费前记录的时间，而消费期间插入的记录（时间戳晚于消费前时间）会出现在下一次消费的结果中，以此确认数据未丢失。

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