Snowflake动态存储过程并发适配、数据一致性与预聚合视图方案问询

CREATE OR REPLACE PROCEDURE database.schema.sp_sample(dynamic_columns VARCHAR, dynamic_where_clause VARCHAR)
RETURNS VARCHAR
LANGUAGE JAVASCRIPT
EXECUTE AS CALLER
AS 
$$
rs="Success";
try {
retrieve_queries_sql = `SELECT COL_1, COL_2, ${DYNAMIC_COLUMNS} FROM view ${DYNAMIC_WHERE_CLAUSE} GROUP BY COL_1, COL_2, ${DYNAMIC_COLUMNS}`;
var stmt = snowflake.createStatement( {sqlText: retrieve_queries_sql, binds:[DYNAMIC_COLUMNS, DYNAMIC_WHERE_CLAUSE, DYNAMIC_COLUMNS]} );
var rs = stmt.execute();
}
catch(err) {
rs= "Failed Message: "+err.message;
}
return rs;
$$;

CALL "database"."schema"."sp_sample"('COL_3','WHERE COL_3=\'somevalue\'');
SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID(-2)));

备注：当前无按用户维度展示专属数据的需求，代码中的参数插值实现细节可暂时忽略。

• 该存储过程为纯读操作，不会产生写锁、事务阻塞这类传统并发故障，但结合Snowflake引擎特性与当前实现，存在三个明确的实际风险：
  • 执行计划复用率极低：每次调用传入的动态列、动态where条件都会直接拼入最终SQL文本，高频不同参数组合会生成大量结构异构的SQL，Snowflake无法复用之前的SQL解析、优化结果，每个请求都要从头做解析、资源调度，并发量上来后会快速占满当前虚拟仓库的算力，出现查询排队、延迟飙升。
  • 现有代码的硬伤会放大故障影响：当前实现一边用模板字符串把入参直接拼进SQL，一边又错误地把入参传入binds参数，实际执行时会因为绑定参数数量和占位符不匹配直接报错，大量无效请求会额外消耗计算资源。
  • 无查询结果管控机制：动态聚合逻辑没有做返回行数、扫描范围的限制，一旦某用户传入的筛选条件过滤性极弱，会触发大宽表全量扫描，挤占所有并发用户的可用资源。

• 直接给结论：在你描述的「所有ETL加工在用户访问前全部完成、访问窗口内无任何数据更新」的前提下，不存在数据完整性问题，所有用户读到的有效数据完全一致。
• 核心逻辑：Snowflake的普通视图是纯逻辑映射层，只要底层源表在ETL完成后没有任何DML/DDL变更，不管多少用户、隔多久发起查询，读到的都是同一版本的已提交数据，不存在并发读场景下的脏读、版本不一致问题。
• 唯一可能出现的一致性偏差属于上游时序管控问题：如果用户访问窗口内还有未跑完的ETL批次、源表还在持续写入，那部分用户可能会读到未加工完成的中间数据，这个问题和当前动态存储过程的实现逻辑没有任何关系。

• 首先要明确：之前收到的“当前动态存储过程会引发数据完整性问题、必须上预聚合”的判断完全错位，本质是把查询性能/成本问题和数据一致性问题做了概念混淆。
  • 为什么两种方案不存在数据完整性的差异？不管是当前实现的“运行时从明细视图实时动态聚合”，还是预聚合方案里“按维度层级拆分存储聚合结果”，只要底层源表在用户访问期没有变更、预聚合的刷新动作严格卡在ETL完成后、用户访问前，两种方式返回的逻辑结果完全等价，不存在谁的数据更准确、用户更难看到有效数据的区别。
  • 预聚合方案真正解决的从来不是数据完整性问题，而是三个性能/成本层面的问题：
    • 大幅降低查询计算成本：明细层往往存在千万到亿级别的数据量，实时做动态GROUP BY需要扫描全量明细列，消耗大量虚拟仓库 credits；预聚合是在ETL阶段就把常用维度的聚合结果算好落盘，用户查询时直接扫结果集，扫描量通常能降到原来的几十分之一，单查询成本和延迟会同步大幅下降。
    • 稳定高并发下的资源表现：预聚合生成的查询SQL是固定结构的，Snowflake可以高效缓存执行计划，不会因为动态参数组合过多导致缓存频繁失效，并发压力下的资源消耗波动会小很多，不会出现动态实时聚合时突发请求打满算力的情况。
    • 简化复杂聚合的逻辑：如果后续维度组合越来越多、聚合计算逻辑越来越复杂，预聚合可以把复杂计算前置到离线批次完成，避免把复杂计算逻辑放到用户在线查询链路里。
• 对该技术建议的合理性反馈：
  • 完全站不住脚的部分：把动态存储过程定性为“导致数据缺失、用户看不到更新后有效数据”的原因，在当前静态访问的场景下没有任何事实依据，属于典型的概念混淆。
  • 有参考价值的部分：如果后续用户量上升、实时动态聚合的查询延迟已经影响使用体验、计算成本高到不可接受，上预聚合是非常成熟的性能优化路径，但这从始至终都是性能优化动作，和数据一致性、完整性的修复没有任何关系。

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