15个配置项砍到2个，Snowflake自适应计算在改什么？

你运行的每个 Snowflake 标准型虚拟仓库，都拥有独立的计算资源池，与其他虚拟仓库相互隔离。路由至该虚拟仓库的查询可以使用其可用计算容量，而路由至其他虚拟仓库的查询则无法使用。

这种隔离机制为不同工作负载提供了独立的成本控制、服务级别协议（SLA）和成本核算能力。但它也带来一个副作用：当某个虚拟仓库出现查询排队时，另一个虚拟仓库的闲置计算资源无法用于缓解拥堵。

问题在于，能否在保留这些隔离边界的同时，避免资源浪费？自适应计算（Adaptive Compute）给出的答案是：共享计算资源、按查询动态调整计算规模、用两个属性取代原有的 15 个以上配置项，以及支撑这一切的准入控制机制。

四项原则，对应四个旧问题

自适应计算建立在四项核心原则之上。每一项原则都针对标准型虚拟仓库模式中的一个问题：过去需要用户提前做出的配置决策，现在可以由平台根据实时情况作出更合理的判断。

• 共享计算（Shared Compute）：多个工作负载共享同一个计算资源池，无需每个虚拟仓库分别保留闲置容量。
• 自动调整计算规模（Autosizing）：每条查询都能获得与其需求相匹配的计算规模，无需预先选定一个固定规模并将其应用于所有查询。
• 最新硬件与软件加速能力：自动使用最新的硬件和查询加速技术，无需手动升级或重新配置。
• 易用性：标准型虚拟仓库需要管理 15 个以上的配置属性，而自适应计算将其简化为两个。

虚拟仓库规模、多集群设置、查询加速服务（Query Acceleration Service）配置，以及自动挂起和恢复策略，都不再需要用户自行管理。

共享计算：从资源孤岛到账户级资源池

自适应计算通过改变虚拟仓库底层的计算资源组织方式来实现资源共享。账户中所有自适应虚拟仓库的任务，都会被路由至该账户专属的计算资源池。这个资源池不会与其他账户共享，也不会与其他类型的虚拟仓库共享。

各个虚拟仓库仍然是相互独立的访问端点，用于组织、治理工作负载并生成相关报告，但执行查询的底层计算资源已经实现池化。

在传统模式下，你看到的并不是一个统一的资源池，而是许多个彼此隔离的计算资源孤岛。每个正在运行的虚拟仓库都是一座独立的孤岛，分别配置计算规模、分别计费。每座孤岛内部的计算容量，只能由路由至对应虚拟仓库的查询使用。

这是一个架构层面的问题。一旦计算资源按照虚拟仓库进行划分，每个虚拟仓库都必须为自身的峰值负载预留容量。而当峰值尚未到来时，这些容量便无法被其他工作负载利用。

客户组织计算资源主要有三种方式，在自适应计算推出之前，用户只能选择前两种：

1. 独立虚拟仓库：每个虚拟仓库都预留了无法充分利用的闲置容量，因此无法获得资源整合带来的成本节约。
2. 少量大型整合式虚拟仓库：可以重新利用闲置计算资源，但会增加查询路由的复杂性，同时削弱成本控制和服务级别协议所依赖的工作负载级隔离边界。
3. 共享计算：既能获得资源整合带来的成本节约，又能保留工作负载级的隔离边界。

这里还有一项会不断累积的收益。迁移至自适应计算的虚拟仓库越多，资源池汇聚的总需求就越大，系统高效调度查询的机会也越多。这也解释了为什么仅迁移一个虚拟仓库时，获得的收益通常最少。

每条查询都有自己的计算规模

传统虚拟仓库要求所有查询使用统一的计算规模：对于小型查询而言，资源可能过剩；对于大型查询而言，资源又可能不足。自适应计算则可以管理不同查询的计算规模分布，为每条查询分配适合其需求的计算规模。

真实世界中的工作负载几乎不可能完全一致。同一个虚拟仓库可能既要处理只扫描少量数据分区的仪表板刷新任务，又要执行涉及数十亿行数据连接操作的夜间数据转换任务。标准型虚拟仓库要求你提前选定一个统一的计算规模，无论选择哪种规模，两端的查询都会受到影响。

逐条查询进行资源分配决策，正是效率提升的来源。小型查询不再消耗自身无法充分利用的计算资源，由此节省的容量可以为计算密集型查询提供额外的资源余量。在相同的支出下，系统能够处理更多工作负载。

但更快的速度并非没有成本。每条查询都有自己的性能曲线：随着计算资源增加，查询速度逐步提升，但最终会遇到扩展瓶颈。在达到 2XL 之前，查询几乎能够实现理想的线性扩展，即计算规模每提升一级，执行速度就翻倍。但随后便遇到了扩展瓶颈：从 2XL 升级至 3XL，计算资源翻倍，执行速度只提升了 50%；从 3XL 升级至 4XL，计算资源再次翻倍，执行速度却仅提升了 25%。

因此，并不存在一个适用于所有查询的唯一正确规模。真正存在的是一条成本与性能之间的权衡曲线，而不同工作负载适合停止增加资源投入的位置各不相同。

Snowflake 能够在查询执行之前预测这条性能曲线。在编译阶段，系统已经掌握数据量、连接操作结构，以及任务中可以并行执行的工作比例，这些信息足以帮助系统估算查询在各个可用计算规模下的执行速度和成本。

系统能够理解不同计算规模对应的成本与性能权衡，但无法自行判断的是：你愿意接受怎样的权衡。假设计算资源增加一倍，可以让查询速度提升 1.5 倍。对于后台批处理任务而言，这可能并不划算；对于正在等待报表结果的用户来说，这可能完全合理。这是一项业务判断，而非单纯的查询技术指标。

两个属性：MQPL 与 QTM

正是因为系统能够衡量的内容，与只有用户才能决定的取舍之间存在差异，自适应计算才提供了两个配置属性。

MAX_QUERY_PERFORMANCE_LEVEL（MQPL，最大查询性能级别）用于规定单条查询可以沿成本与性能曲线提升到什么程度，也就是你愿意为更快的查询速度支付多少成本。QUERY_THROUGHPUT_MULTIPLIER（QTM，查询吞吐量倍数）用于规定虚拟仓库在新查询开始排队之前，允许多少并发工作负载进入执行，也就是你愿意为应对突发流量投入多少资源。

MQPL 是一个上限，而且是严格执行的上限。即便对于某条查询而言，继续提高一个计算级别能够以相对有限的额外成本换来明显的速度提升，MQPL 仍然会阻止查询超过设定的上限。它并不意味着所有查询都必须按照该级别执行，也不等同于虚拟仓库的固定规模。大多数查询会根据自身能够有效利用的资源量，在低于该上限的规模下执行。

MQPL 使用熟悉的 T 恤尺码体系表示，范围从 XS 到 4XL。一个合理的起点，是将 MQPL 设置为比原有标准型虚拟仓库规模高一级：原有规模代表日常查询已经适应的性能范围，增加一级则为偶尔出现的重型查询保留空间。

QTM 对应的是突发流量问题。工作负载很少以稳定不变的速率到达：上午 9 点，所有仪表板可能同时刷新；某条数据流水线可能并行触发 40 个转换任务。QTM 决定自适应计算应该同时处理多少突发工作量，以及应该让多少查询暂时留在队列中等待。

提高 QTM，更多查询能够同时执行，延迟降低，但峰值成本更高；降低 QTM，更多查询进入等待队列，高负载下执行速度变慢，但支出受到限制。与标准型虚拟仓库中的 MAX_CLUSTER_COUNT（最大集群数量）类似，QTM 提供的是应对负载峰值的额外容量空间，而非固定分配的资源。如果工作负载没有产生需要使用额外容量的突发流量，那么即使将 QTM 设置得更高，也不会影响账单。

底层机制：准入控制 token 预算

MQPL 和 QTM 共同定义了一个准入控制 token 预算（Admission-Control Token Budget）。每条查询在进入共享计算资源池执行之前，都必须经过准入控制，由这一预算决定哪些查询可以立即执行，哪些查询必须等待。

QTM 是 MQPL 的倍数，系统会根据所选性能级别，按相应倍数提供 token 预算。例如，如果 MQPL 设置为 Large，QTM 设置为 4，那么虚拟仓库就能够同时执行相当于 4 条 Large 级别查询的计算工作量。

在编译阶段，系统会根据每条查询所需的资源，为其分配一个抽象的 token 需求量。当可用容量足够时，查询便开始执行；查询运行期间，对应的 token 会被预留；查询完成后，这些 token 将被归还。如果可用容量不足，新到达的查询就需要等待。

共享计算还会改变查询的 token 成本。查询消耗的 token 数量，取决于实际分配给它的计算单元，而非每条查询统一收取固定数量。如果某条查询独占一个计算单元，就需要承担该计算单元的全部 token 成本；如多条查询共享一个计算单元，每条查询则只承担与其使用份额对应的 token 成本。

token 具有可互换性。同一份预算可以支持 4 条 Large 级别查询、8 条 Medium 级别查询、16 条 Small 级别查询，或者任何其他符合预算限制的查询规模组合。这正是为什么查询规模差异较大的工作负载，能够在同一个自适应虚拟仓库中高效运行。

当自适应计算无法对某条查询作出足够有把握的判断时，例如遇到不熟悉的查询类型、新的执行计划，或者缺乏足够的历史数据，系统会优先采取避免负面影响的策略，而非贸然猜测。此时，查询将按照此前本应获得的计算级别执行。另一项保护机制则为查询规模的向下调整设置了下限。

标准型虚拟仓库将计算资源分割成彼此隔离的孤岛，同时要求计算需求各异的工作负载使用统一的计算规模，这使得成本与性能之间的权衡变成了一项管理难题。自适应计算通过共享计算模型，为每条查询匹配其能够有效利用的计算资源，使单个虚拟仓库能够同时支持不同规模的查询，而成本核算和遥测数据仍然与对应工作负载保持关联。