Snowflake MERGE语句阻塞：不同时间压测结果差异原因问询

背景回顾 #

2024年5月2-3日压测阶段，基于Snowflake的系统在35请求/分钟以内可正常运行，超出该阈值会因MERGE语句触发表阻塞；近期在代码、依赖版本、压测场景完全未变更的情况下，原35请求/分钟的压测出现MERGE阻塞退化，甚至10-20请求/分钟也失败，升级snowflake-sdk无改善。技术栈为AWS API Gateway + Lambda（Node.js）、Artillery压测工具。

可能的差异原因 #

1. Snowflake侧的隐性变更 #

• 虚拟仓库资源/配置调整：如果Snowflake虚拟仓库的大小、自动缩放策略（AUTO_SUSPEND/AUTO_RESUME/SCALING_POLICY）被修改，会直接削弱MERGE语句的并发处理能力。比如仓库缩容、自动缩放触发延迟，会导致并发MERGE请求无法获取足够计算资源，引发阻塞。
• 目标表数据变化：从5月到当前，目标表的数据量可能大幅增长，或出现数据分布倾斜（如部分分区数据量过大）。MERGE需要扫描匹配数据，数据量增大或倾斜会延长单条MERGE的执行时间，并发下锁竞争加剧，触发阻塞。
• 外部事务锁占用：若近期新增了长期运行的后台任务（如ETL、批量查询），这些事务会占用目标表的锁，导致压测时的MERGE请求排队阻塞。
• 查询优化器行为变更：Snowflake自身版本迭代会更新查询优化器，可能对MERGE生成效率更低的执行计划（如选择不合适的索引、扩大扫描范围），导致MERGE执行变慢，进而引发阻塞。

2. AWS服务的隐性变化 #

• Lambda运行环境变更：AWS Lambda的底层环境（如Node.js小版本、操作系统）可能有隐性更新，或冷启动频率上升，导致请求处理延迟增加，MERGE提交节奏不稳定，加剧锁冲突。若Lambda的内存/CPU配置被误降配，也会影响处理效率，间接引发阻塞。
• API Gateway限流/排队：API Gateway的限流配置（throttling）若被调整，或其他流量占用了配额，会导致请求排队，使得MERGE请求集中提交，加剧Snowflake侧的并发锁竞争。

3. 压测环境的隐性差异 #

• Artillery运行资源受限：压测机器（如EC2实例）的CPU、内存、带宽被其他任务占用，会导致压测请求发送节奏紊乱，出现突发请求，使得Snowflake侧MERGE并发量瞬间超标，触发阻塞。
• 网络链路延迟变化：压测机器到Snowflake的网络延迟增加（如AWS区域网络波动、Snowflake端点负载上升），会延长MERGE执行时间，锁持有时间变长，更容易引发阻塞。

4. 会话与参数隐性变更 #

• Snowflake会话参数被覆盖：Lambda使用的Snowflake会话参数（如LOCK_TIMEOUT、STATEMENT_TIMEOUT_IN_SECONDS）若被账户级参数覆盖，会影响MERGE执行行为。比如LOCK_TIMEOUT调小会导致请求更快因锁等待失败，STATEMENT_TIMEOUT_IN_SECONDS过短会导致MERGE未完成就超时。
• 并发连接数限制调整：Snowflake账户或仓库级的并发连接数限制若被修改，超过限制的MERGE请求会被排队或拒绝，表现为阻塞或失败。

排查方向 #

• 对比5月与当前的Snowflake仓库配置、目标表数据量及分布，确认是否有变更。
• 查看Snowflake查询历史，对比相同MERGE语句在两个时间段的执行计划、执行时间差异。
• 检查Snowflake锁历史，确认压测时是否有其他事务占用目标表锁资源。
• 验证Lambda的内存/CPU配置、Node.js版本是否与5月一致，监控冷启动频率。
• 检查API Gateway的限流配置，确认压测请求是否被限流排队。
• 压测时监控Artillery机器的资源使用率，确保请求发送节奏稳定。

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