2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！
你运行的每个 Snowflake 标准型虚拟仓库（Standard Warehouse），都拥有独立的计算资源池，与其他虚拟仓库相互隔离。路由至该虚拟仓库的查询可以使用其可用计算容量，而路由至其他虚拟仓库的查询则无法使用。这种隔离机制为不同工作负载提供了独立的成本控制、服务级别协议（SLA）和成本核算能力，但也意味着，当某个虚拟仓库出现查询排队时，另一个虚拟仓库的闲置计算资源无法用于缓解拥堵。
问题在于，能否在保留这些隔离边界的同时，避免资源浪费？本文将深入解析自适应计算（Adaptive Compute）如何实现这一目标：共享计算资源、按查询动态调整计算规模、用两个属性取代原有的 15 个以上配置项，以及支撑这一切的准入控制机制。
四项核心原则
自适应计算建立在四项核心原则之上。每一项原则都针对标准型虚拟仓库模式中的一个问题：过去需要用户提前做出的配置决策，现在可以由平台根据实时情况作出更合理的判断。
共享计算（Shared Compute）： 多个工作负载共享同一个计算资源池，无需每个虚拟仓库分别保留闲置容量。某个工作负载暂时不需要的计算资源，可以用于执行其他工作负载的查询，避免资源被预留后长期闲置。
自动调整计算规模（Autosizing）： 每条查询都能获得与其需求相匹配的计算规模，无需预先选定一个固定规模并将其应用于所有查询。
最新硬件与软件加速能力： 自动使用最新的硬件和查询加速技术，无需手动升级或重新配置。
易用性： 标准型虚拟仓库需要管理 15 个以上的配置属性，而自适应计算将其简化为两个。虚拟仓库规模、多集群设置、查询加速服务（Query Acceleration Service）配置，以及自动挂起和恢复策略，都不再需要用户自行管理。
共享计算
自适应计算通过改变虚拟仓库底层的计算资源组织方式来实现资源共享。
账户中所有自适应虚拟仓库的任务，都会被路由至该账户专属的计算资源池。这个资源池不会与其他账户共享，也不会与其他类型的虚拟仓库共享。
各个虚拟仓库仍然是相互独立的访问端点，用于组织、治理工作负载并生成相关报告，但执行查询的底层计算资源已经实现池化。
要理解这一变化的重要性，需要跳出单个虚拟仓库的视角，从整个账户使用的计算资源来看。
在传统模式下，你看到的并不是一个统一的资源池，而是许多个彼此隔离的计算资源孤岛。每个正在运行的虚拟仓库都是一座独立的孤岛，分别配置计算规模、分别计费。
每座孤岛内部的计算容量，只能由路由至对应虚拟仓库的查询使用。无论账户中的其他地方多么需要这些资源，都无法跨虚拟仓库调用。
这是一个架构层面的问题。一旦计算资源按照虚拟仓库进行划分，每个虚拟仓库都必须为自身的峰值负载预留容量。而当峰值尚未到来时，这些容量便无法被其他工作负载利用。
我们观察到，客户主要通过以下三种方式组织各个虚拟仓库的计算资源。在自适应计算推出之前，用户只能选择前两种：
独立虚拟仓库： 每个虚拟仓库都预留了无法充分利用的闲置容量，因此无法获得资源整合带来的成本节约。
少量大型整合式虚拟仓库： 这种方式可以重新利用闲置计算资源，但会增加查询路由的复杂性，同时削弱成本控制和服务级别协议所依赖的工作负载级隔离边界。
共享计算： 既能获得资源整合带来的成本节约，又能保留工作负载级的隔离边界。
这里还有一项会不断累积的收益。
迁移至自适应计算的虚拟仓库越多，资源池汇聚的总需求就越大，系统高效调度查询的机会也越多。规模经济效应因此能够发挥作用。这也解释了为什么仅迁移一个虚拟仓库时，获得的收益通常最少。
自动调整计算规模：每条查询都有自己的计算规模
传统虚拟仓库要求所有查询使用统一的计算规模：对于小型查询而言，资源可能过剩；对于大型查询而言，资源又可能不足。自适应计算则可以管理不同查询的计算规模分布，为每条查询分配适合其需求的计算规模。
真实世界中的工作负载几乎不可能完全一致。同一个虚拟仓库可能既要处理只扫描少量数据分区的仪表板刷新任务，又要执行涉及数十亿行数据连接操作的夜间数据转换任务。标准型虚拟仓库要求你提前选定一个统一的计算规模。无论选择哪种规模，两端的查询都会受到影响。自适应虚拟仓库则根据每条查询自身的特征决定计算规模，使计算资源分配能够匹配实际需求，而无需受限于事先设定的固定值。
上图：固定规模的虚拟仓库在整个分布中划定了一条统一的计算规模线。位于该线左侧的查询承担了过高的计算成本，右侧的查询则面临计算资源不足的问题。
下图：自适应虚拟仓库根据每条查询的实际需求，为其分配相应的计算规模。
效率收益从何而来
逐条查询进行资源分配决策，正是效率提升的来源。小型查询不再消耗自身无法充分利用的计算资源。由此节省的容量，可以为计算密集型查询提供额外的资源余量。这也意味着，在相同的支出下，系统能够处理更多工作负载。
更快的速度并非没有成本
然而，更快的速度并非没有成本。每条查询都有自己的性能曲线：随着计算资源增加，查询速度逐步提升，但最终会遇到扩展瓶颈。超过这一临界点后，继续增加计算资源所带来的速度提升将十分有限。
在达到 2XL 之前，查询几乎能够实现理想的线性扩展，即计算规模每提升一级，执行速度就翻倍。但随后便遇到了扩展瓶颈。从 2XL 升级至 3XL，计算资源翻倍，但执行速度只提升了 50%，而非 100%。从 3XL 升级至 4XL，计算资源再次翻倍，执行速度却仅提升了 25%。因此，并不存在一个适用于所有查询的唯一正确规模。真正存在的是一条成本与性能之间的权衡曲线，而不同工作负载适合停止增加资源投入的位置各不相同。确定应该在曲线上的哪个位置停止增加资源投入，就是自适应虚拟仓库调优的核心。
Snowflake 能够在查询执行之前预测这条性能曲线。在编译阶段，系统已经掌握数据量、连接操作结构，以及任务中可以并行执行的工作比例。这些信息足以帮助系统估算查询在各个可用计算规模下的执行速度和成本。
因此，系统能够理解不同计算规模对应的成本与性能权衡。但系统无法自行判断的是：你愿意接受怎样的权衡。假设计算资源增加一倍，可以让查询速度提升 1.5 倍。对于后台批处理任务而言，这可能并不划算；对于正在等待报表结果的用户来说，这可能完全合理。即便处于同一条性能曲线上的同一个位置，是否值得投入额外成本，也取决于工作负载的业务属性。这是一项业务判断，而非单纯的查询技术指标。
正是因为系统能够衡量的内容，与只有用户才能决定的取舍之间存在差异，自适应计算才提供了两个配置属性。MAX_QUERY_PERFORMANCE_LEVEL（MQPL，最大查询性能级别） 用于规定单条查询可以沿成本与性能曲线提升到什么程度，也就是你愿意为更快的查询速度支付多少成本。QUERY_THROUGHPUT_MULTIPLIER（QTM，查询吞吐量倍数） 用于规定虚拟仓库在新查询开始排队之前，允许多少并发工作负载进入执行，也就是你愿意为应对突发流量投入多少资源。两者结合后，系统便能够针对每条查询执行你设定的成本与性能权衡策略，而无需你逐条干预。
关于业务，你需要回答的三个问题
应该在性能曲线上的哪个位置停止增加资源投入，最终是一项业务决策。以下三个问题可以帮助你确定这一位置。这三个问题关注的都是业务需求，而非数据本身。
1. 对于这类工作负载，延迟究竟有多重要？对谁重要？是有人正在等待仪表板加载完成？是某份关键报表可能无法在工作日开始前生成？还是一项只需在第二天早晨之前完成的夜间批处理任务？这些差异决定了典型查询应该以多大程度的额外成本来换取执行速度。
2. 对于计算需求异常高的查询，我愿意允许它消耗多少资源？计算需求最高的查询，可能有充分理由使用远超普通查询的计算资源。为这些查询保留额外的资源空间是有价值的，但这种投入也应有上限，避免单条查询产生无法接受的成本。
3. 突发流量会对业务造成什么影响？请求量激增时，查询是否会持续排队，直到用户失去耐心？还是说，这只会让夜间报表晚一点完成，但仍然能够在规定时间内交付？单条查询能够消耗多少资源，并不能说明当 50 条查询同时到达时，系统应该如何应对。
回答完这三个问题，你就明确了自己的业务策略。两个配置属性负责记录这些答案：第一个属性对应前两个问题，第二个属性对应第三个问题。
MAX_QUERY_PERFORMANCE_LEVEL（MQPL）
MQPL 对应问题 1 和问题 2，用于设定单条查询在成本与性能曲线上能够达到的最高级别。
一个合理的起点，是将 MQPL 设置为比原有标准型虚拟仓库规模高一级。原有标准型虚拟仓库的计算规模，代表了日常查询已经适应的性能范围（问题 1）；在此基础上增加一个级别，则可以为偶尔出现、能够充分利用更多资源的重型查询保留空间（问题 2）。如果将 MQPL 设置为与原有标准型虚拟仓库相同的规模，就意味着放弃了为异常高负载查询预留的额外空间，同时也需要接受日常查询的性能基准可能低于此前使用标准型虚拟仓库时的水平。
MQPL 的作用是什么？MQPL 是一个上限，而且是严格执行的上限。即便对于某条查询而言，继续提高一个计算级别能够以相对有限的额外成本换来明显的速度提升，MQPL 仍然会阻止查询超过设定的上限。
因为再划算的性能提升，也意味着更高的账单，而你已经通过 MQPL 告诉系统，自己愿意在哪个位置停止增加投入。
MQPL 不是什么？它并不意味着所有查询都必须按照该级别执行，也不等同于虚拟仓库的固定规模。在标准型虚拟仓库中，选定的规模就是所有查询使用的计算规模。而在自适应虚拟仓库中，MQPL 表示单条查询可以达到的最高计算规模。大多数查询会根据自身能够有效利用的资源量，在低于该上限的规模下执行。这个上限只负责限制计算需求最高的查询。
MQPL 使用熟悉的 T 恤尺码体系表示，范围从 XS 到 4XL。一旦完成设置，通常无需反复调整，因为它表达的是你对成本与性能权衡的偏好，而非对当前工作负载状态的临时判断。
图中的典型查询标记，表示日常查询通常使用的计算规模；MQPL 则是在此基础上提高一级设定的上限。
左图中，典型查询的计算规模为 XL，上限设置为 2XL。这个位置恰好是该查询性能不再随计算资源翻倍而翻倍的临界点，因此系统不会允许查询越过这一扩展瓶颈。右图中，日常查询的计算需求更高，已经达到 2XL。因此，同样保留一级额外资源空间，会使上限达到 3XL。
这意味着查询将越过扩展瓶颈：计算资源增加一倍，却只能获得额外 50% 的速度提升。相同的设置原则，会根据实际工作负载落在不同的位置。两者都不能被视为唯一正确的答案。当业务对延迟的重视程度高于边际成本时，右图的选择就是可以接受的。
应该在哪里停止增加资源投入，取决于业务判断。扩展瓶颈并不意味着 MQPL 必须设置在这一位置。对于大多数工作负载，在扩展瓶颈附近或达到瓶颈时停止增加资源投入，是比较合理的默认选择。但某些工作负载可能值得投入更多资源，例如必须在严格截止时间前完成的报表，或者处于所有下游任务关键路径上的查询。MQPL 正是用于记录这一业务判断的配置属性。
这里使用与图 4 左图相同的 MQPL 上限（2XL），但这条查询的并行扩展瓶颈从 Medium 级别就已经开始，因此超过 Small 级别后，继续增加资源所带来的速度提升已经十分有限。自适应计算只为其分配 Small 级别的计算资源，因为这是该查询能够有效利用的规模，2XL 的上限根本不会发挥限制作用。你负责设定上限，而每条查询自身的扩展特征决定其实际运行规模。这样，系统就不会消耗那些无法转化为查询速度提升的计算资源。
当自适应计算无法对某条查询作出足够有把握的判断时，例如遇到不熟悉的查询类型、新的执行计划，或者缺乏足够的历史数据，系统会优先采取避免负面影响的策略，而非贸然猜测。此时，查询将按照此前本应获得的计算级别执行。另一项保护机制则为查询规模的向下调整设置了下限。这两项措施都是为了应对当前预测能力仍存在的不确定性，并非架构设计中永久不变的组成部分。
QUERY_THROUGHPUT_MULTIPLIER（QTM）
QUERY_THROUGHPUT_MULTIPLIER（QTM，查询吞吐量倍数）对应问题 3，用于调整虚拟仓库在查询开始排队之前允许执行的并发工作量。它是一个倍数，而非具体的查询数量：能够获得的并发能力取决于 MQPL 的设置。
工作负载很少以稳定不变的速率到达。上午 9 点，所有仪表板可能同时刷新。某条数据流水线可能并行触发 40 个转换任务。一场演唱会开始售票后，大量请求可能在短短几分钟内集中涌入。
QTM 决定自适应计算应该同时处理多少突发工作量，以及应该让多少查询暂时留在队列中等待。队列并不仅仅是一种限制机制，也是一种控制手段。让部分查询等待，实际上是业务施加背压（Backpressure）的一种方式。这样，系统就无需为了满足每次流量峰值而无限扩展计算资源、承担相应成本。你可以自行决定，为应对一次突发流量，愿意投入多少资源。
提高 QTM： 更多查询能够同时执行 → 延迟降低，但峰值成本更高。
降低 QTM： 更多查询进入等待队列 → 高负载下执行速度变慢，但支出受到限制。
查询排队就是在延迟与成本之间进行权衡的调节手段，而 QTM 则是设置这一权衡的位置。QTM 表示为所选 MQPL 的倍数，因此其默认配置已经考虑了你要求的性能级别。与标准型虚拟仓库中的 MAX_CLUSTER_COUNT（最大集群数量）类似，QTM 提供的是应对负载峰值的额外容量空间，而非固定分配的资源。如果工作负载没有产生需要使用额外容量的突发流量，那么即使将 QTM 设置得更高，也不会影响账单。但如果突发流量确实使用了这些额外容量，费用就可能相应增加。
较低的 QTM 会限制突发工作负载的并发执行规模，让部分查询等待，从而限制峰值支出。较高的 QTM 则允许系统扩展并发执行能力，让更多查询同时运行，但峰值成本也会随之提高。两种方式没有绝对的优劣，应该选择哪一种取决于业务需求。查询排队机制则负责执行这一决策。
MQPL 与 QTM 共同取代了标准型虚拟仓库需要管理的十多个配置属性：一个控制单条查询的性能，另一个控制吞吐量以及突发负载带来的成本。
底层机制：准入控制
MQPL 和 QTM 不仅仅是两个调优参数。两者共同定义了一个准入控制 token 预算（Admission-Control Token Budget）。每条查询在进入共享计算资源池执行之前，都必须经过准入控制。准入控制机制正是根据这一 token 预算，决定哪些查询可以立即执行，哪些查询必须等待。
其工作原理并不复杂。MQPL 与 QTM 共同确定虚拟仓库的准入控制预算，并以一定数量的 token 表示。这两个属性的组合方式，也解释了 QTM 名称中“倍数”的含义：QTM 是 MQPL 的倍数，系统会根据所选性能级别，按相应倍数提供 token 预算。粗略来说，这些 token 足以支持当前 QTM 配置所对应数量的并发查询，前提是每条查询都按照 MQPL 设定的最高规模执行。例如，如果 MQPL 设置为 Large，QTM 设置为 4，那么虚拟仓库就能够同时执行相当于 4 条 Large 级别查询的计算工作量。一个属性决定单条查询最多可以使用多少计算资源，另一个属性决定能够同时承担多少这样的查询。两者的乘积，就是准入控制的 token 预算。
这一 token 预算代表虚拟仓库可用于执行查询的计算容量。在编译阶段，系统会根据每条查询所需的资源，为其分配一个抽象的 token 需求量。当可用容量足够时，查询便开始执行。在查询运行期间，对应的 token 会被预留；查询完成后，这些 token 将被归还。如果可用容量不足，新到达的查询就需要等待，直到有足够的容量释放。
共享计算还会改变查询的 token 成本。查询消耗的 token 数量，取决于实际分配给它的计算单元，而非每条查询统一收取固定数量的 token 。如果某条查询独占一个计算单元，就需要承担该计算单元的全部 token 成本；如多条查询共享一个计算单元，每条查询则只承担与其使用份额对应的 token 成本。由于共享计算单元的查询占用的 token 更少，系统就能够同时准入更多查询。
token 具有可互换性
token 机制使整个预算具备了可互换性和灵活分配能力。它并不是四个固定的、只能容纳 Large 级别查询的执行槽位，而是一个可以根据实际工作负载灵活组合使用的资源池。
例如，同一份预算可以支持：
-
4 条 Large 级别查询；
-
8 条 Medium 级别查询；
-
16 条 Small 级别查询；
-
或者任何其他符合预算限制的查询规模组合。
这正是为什么查询规模差异较大的工作负载，能够在同一个自适应虚拟仓库中高效运行。
相同的 QTM × MQPL 预算，可以支持 4 条 Large 查询、8 条 Medium 查询、16 条 Small 查询，或者任何符合预算的混合组合。无法纳入当前预算的查询，需要等待正在运行的查询完成并归还 token 后，才能开始执行。
总结
标准型虚拟仓库将计算资源分割成彼此隔离的孤岛，同时要求计算需求各异的工作负载使用统一的计算规模。这使得成本与性能之间的权衡变成了一项管理难题：每当工作负载发生变化，都需要重新调整配置。
按照查询规模将工作负载拆分至多个虚拟仓库，虽然能够在一定程度上恢复资源使用效率，却会牺牲按照业务目的进行报告和治理的能力。
自适应计算则能够在避免资源碎片化的同时，实现更高的计算效率。通过共享计算模型，系统可以为每条查询匹配其能够有效利用的计算资源，使单个虚拟仓库能够同时支持不同规模的查询，而成本核算和遥测数据仍然与对应工作负载保持关联。你无需再为基础设施逐一确定计算规模，只需要定义工作负载的需求。剩下的工作，交给 Snowflake。
点击链接立即报名注册：https://www.snowflake.com/events/snowflake-ascent-china/更多 Snowflake 精彩活动请关注专区