Snowflake 推出自适应计算，以共享资源池与动态规模调度替代固定虚拟仓库配置

一句话结论

Snowflake 发布自适应计算模式，通过共享资源池与动态查询级调度，解决标准型虚拟仓库因资源隔离导致的闲置浪费与成本刚性问题。

关键要点

• 自适应计算将账户内多个虚拟仓库的计算任务路由至专属共享资源池，消除跨仓库资源孤岛，但保留各仓库的访问端点隔离。
• 该模式以两个核心参数取代标准型虚拟仓库 15 项以上配置：MQPL（最大查询性能级别）设定单查询性能上限，QTM（查询吞吐量倍数）定义并发排队策略。
• 计算规模扩展存在非线性瓶颈：从 2XL 升至 3XL，资源翻倍但速度仅提升 50%；3XL 升至 4XL，速度仅提升 25%。
• 资源分配基于 Token 预算机制：独占计算单元承担全部 Token 成本，共享查询按份额承担，Token 可互换（如 4 条 Large 等价于 8 条 Medium）。
• QTM 提供峰值弹性容量而非固定资源：提高 QTM 降低延迟但增加峰值成本，降低 QTM 增加等待但限制支出，未使用额外容量不产生费用。

背景与事实

Snowflake 传统标准型虚拟仓库采用资源隔离架构，每个仓库拥有独立计算资源池，闲置资源无法跨仓库调用。这种设计导致用户必须按峰值容量预留资源，在业务低谷期产生显著闲置浪费。自适应计算模式对此进行重构：将账户内所有启用的自适应虚拟仓库的任务统一路由至专属共享资源池，在保留访问端点隔离的前提下实现资源池化。随着迁移至该模式的虚拟仓库数量增加，规模经济效应增强，系统调度机会也随之增多。

在性能调度逻辑上，传统模式要求为整个仓库设定统一计算规模，而自适应计算为每条查询动态分配匹配需求的规模。系统根据数据量、连接结构及并行比例预测性能曲线，识别扩展瓶颈。具体而言，在 2XL 之前，计算规模每提升一级，查询速度呈线性翻倍；但从 2XL 升至 3XL，资源投入翻倍而速度仅提升 50%；从 3XL 升至 4XL，速度提升进一步衰减至 25%。基于此曲线，当查询在低级别（如 Small）即出现并行扩展瓶颈时，系统仅分配其能有效利用的规模，忽略 MQPL 上限，避免无效资源消耗。

配置层面，自适应计算以两个属性取代标准型虚拟仓库的 15 项以上配置。第一为 MQPL（MAX_QUERY_PERFORMANCE_LEVEL，最大查询性能级别），采用 T 恤尺码体系（XS 至 4XL），设定单条查询在成本与性能曲线上的最高级别。合理起点为比原有标准型规模高一级，为重型查询预留空间；MQPL 是严格上限，多数查询在低于该上限的规模下执行。第二为 QTM（QUERY_THROUGHPUT_MULTIPLIER，查询吞吐量倍数），规定虚拟仓库在新查询排队前允许的并发工作负载数量，决定突发流量应对策略。QTM 是 MQPL 的倍数而非具体数量，类似标准型仓库的 MAX_CLUSTER_COUNT，提供峰值额外容量；未使用额外容量不影响账单，使用则可能增加费用。

在资源核算机制上，MQPL 与 QTM 共同定义准入控制 Token 预算，每条查询需经过准入控制决定执行或等待。Token 预算支持并发查询数量：例如 MQPL 为 Large 且 QTM 为 4 时，可同时执行相当于 4 条 Large 级别查询的工作量。在共享计算中，独占计算单元的查询承担全部 Token 成本，共享查询按份额承担，占用更少 Token 使系统能准入更多查询。Token 具有可互换性：同一预算支持 4 条 Large、8 条 Medium、16 条 Small 或混合组合查询。自适应计算避免资源碎片化，使单个虚拟仓库支持不同规模查询，成本核算与遥测数据保持与工作负载的关联。此外，当预测不足或不确定时，查询按原应计算级别执行，系统设有查询规模向下调整下限，这些非永久性架构组成部分。

影响分析

对使用 Snowflake 的中文开发者与数据工程师而言，这一架构变更意味着成本管控逻辑从“预留峰值容量”转向“按需动态调度”，直接降低业务波峰波谷间的资源闲置成本。过去团队需为应对偶发重型查询而长期运行高规模仓库，如今可通过 MQPL 设定上限、QTM 控制突发并发，将资源支出与实际负载精准挂钩。Token 预算机制进一步细化了成本归属：共享查询按份额计费使团队能按业务优先级分配资源，高价值查询可独占计算单元，低优先级查询在资源紧张时自动排队而非强制扩容。

该模式同时降低运维复杂度。标准型虚拟仓库的 15 项以上配置需团队手动调优且易出错，自适应计算将其简化为两个核心参数，且系统自动处理规模预测与瓶颈识别。但团队需理解性能曲线非线性特征：3XL 及以上规模的速度增益递减显著，盲目提高 MQPL 可能产生成本而非性能收益。QTM 的调节直接映射为延迟与成本的权衡，需结合业务 SLA 设置：高敏感业务可提高 QTM 减少排队，批处理任务可降低 QTM 限制峰值支出。

适用边界

自适应计算的效率优势依赖多仓库资源池化的规模效应。若账户内仅迁移少量虚拟仓库，共享资源池的调度机会有限，规模经济效应不明显；此时固定配置的标准型仓库可能更易预测成本。此外，对延迟极度敏感且需独占资源保障的特定工作负载，Token 共享机制在资源紧张时可能导致查询排队，需通过 QTM 预留峰值容量或保持部分标准型仓库作为补充。性能曲线非线性瓶颈（3XL 以上增益衰减）意味着超大规模查询的收益提升有限，不适用于单纯依赖堆叠计算规模追求极限速度的场景。

孤本观察

从架构设计看，Snowflake 将资源调度粒度从仓库级下沉至查询级，实质是将云原生弹性计算理念嵌入数据仓库内核，其核心假设是查询负载存在显著异质性且可预测——这是该模式区别于传统 MPP 固定配置的根本。Token 可互换机制则暗示成本核算模型从“固定资源×时间”转向“虚拟资源池×动态占用”，对财务归集逻辑产生连锁影响。

来源：InfoQ 中文 AI