Snowflake自适应计算通过资源池化优化数仓弹性

Snowflake标准型虚拟仓库为不同工作负载提供独立计算资源，可分别进行成本核算、SLA管理和治理。但这种隔离也会形成资源孤岛：一个仓库排队时，其他仓库的闲置容量无法跨仓库调度。自适应计算试图在保留隔离边界的同时，提高整体资源利用率。

自适应计算包含四项原则：多个工作负载共享计算资源池；系统根据单条查询的实际需求自动调整计算规模；自动使用新的硬件和查询加速能力；将原本需要管理的15项以上属性简化为两个。账户内启用该能力的虚拟仓库仍是独立的访问和治理端点，但查询执行会进入账户专属资源池，不与其他账户或其他类型仓库混用。

这种模式既不同于各自保留峰值容量的独立虚拟仓库，也不同于少量大型仓库的集中整合。它能够复用闲置资源，同时维持工作负载级隔离。迁移到自适应计算的仓库越多，资源池中的需求越集中，调度机会和规模经济效应越明显，因此只迁移一个仓库时，收益通常有限。

传统仓库要求所有查询使用同一固定规模，可能让小查询承担过高成本，也可能无法满足大型连接或转换任务。自适应计算则按查询分配资源，使仪表板刷新和数十亿行数据处理等不同任务获得更匹配的计算能力。系统会在编译阶段依据数据量、连接结构和可并行程度，预估不同规模下的性能与成本。

资源增加并不意味着速度始终同比提升。示例中，查询在达到2XL前接近线性扩展；从2XL提升至3XL，资源翻倍但速度仅提高50%，从3XL到4XL时速度增幅进一步降至25%。因此资源配置本质上是成本与延迟的权衡，后台批处理和实时报表可能需要不同选择。

用户需要通过两个属性表达业务取舍。MAX_QUERY_PERFORMANCE_LEVEL（MQPL）规定单条查询可达到的最高性能级别，范围为XS至4XL，通常可从原标准仓库规模上调一级作为起点；它是严格上限，不代表所有查询都会按该规模运行。QUERY_THROUGHPUT_MULTIPLIER（QTM）则控制新查询开始排队前允许进入执行的并发工作负载数量，用于应对突发流量。两者分别对应查询延迟和高负载资源上限、整体吞吐与排队策略。