VLDB 2026：International Conference on Very Large Data Bases 是数据库与数据管理领域的顶级国际会议之一，长期汇聚学术界与工业界在数据库系统、数据管理和大规模数据分析方向的前沿研究成果。VLDB 2026（第 52 届）将于 2026 年 8 月 31 日至 9 月 4 日在美国波士顿举办。 

PKU-DAIR实验室的论文《MFTune: An Efficient Multi-fidelity Framework for Spark SQL Configuration Tuning》被 VLDB 2026 接收。 

MFTune: An Efficient Multi-fidelity Framework for Spark SQL

Configuration Tuning

作者：Beicheng Xu, Lingching Tung, Yuchen Wang, Yupeng Lu, Bin Cui

代码链接：https://github.com/Elubrazione/MFTune

问题背景与动机

Apache Spark SQL 已成为工业界大数据处理的首选。在实际场景中，Spark SQL 工作负载往往包含多条查询并处理海量数据（数百 GB 到数 TB），导致执行时间长达数小时甚至数天。同时，Spark SQL 的性能严重依赖 200 多个配置参数，而默认配置往往次优。由于每次评估成本高昂、配置空间巨大，手动调优既耗时又难以达到最优。因此，现有方法通常采用贝叶斯优化（Bayesian Optimization, BO）框架，通过采样配置、建模性能与参数关系来自动寻找最优配置。然而，这些方法面临三个根本性挑战：

图1：多精度机制分析

挑战一：评估成本过高。 鉴于 Spark SQL 工作负载的长时运行特性，评估配置极为昂贵。现有调优方法往往依赖全精度评估（执行完整的原始工作负载），这限制了在有限调优预算内能够探索的配置数量。一个潜在的解决方案是采用多精度优化（Multi-Fidelity Optimization）：利用更快但近似的低精度评估高效过滤差配置，将搜索引导至最优区域。我们的初步分析表明（见上图），在 48 小时预算内，MFTune 通过多精度优化成功评估了 43 个配置，其中多数达到了高性能；相比之下，仅依赖全精度评估的变体只评估了 29 个配置，且大多落入高延迟区间甚至执行失败。这表明单纯依赖全精度评估无法在实际预算内有效探索巨大的搜索空间。

图2：精度相关性对比

挑战二：现有多精度优化方法不适用。 多精度优化的核心挑战在于确保低精度代理能够保持配置在全精度下的相对排序。然而，AutoML 中的标准精度划分技术——如在数据子集上训练或训练更少轮数——并不能有效迁移到 Spark SQL。如上图所示，通用的 AutoML 低精度代理无法在 Spark SQL 中保持与全精度性能的可靠相关性。缩减数据量会导致相关性急剧下降，因为小数据集无法触发全规模下的真实瓶颈。除通用代理外，我们还尝试适配 DBMS workload 压缩方法（ISUM、GSUM、距离法等）。然而，同一张图显示它们仍提供较弱的全精度相关性，因为这些方法是为索引调优等不同下游目标设计的，而非为 Spark SQL 多精度优化保持配置排序。相比之下，我们提出的 SQL Selection 即使在极低精度水平下也保持了高 Kendall-tau 相关性（>0.8）。这些发现表明，为 Spark SQL 领域定制精度划分至关重要。

挑战三：搜索空间巨大且压缩困难。 Spark SQL 的搜索空间过于庞大，无法在有限预算内穷举探索。现有工作大多仅聚焦于通过敏感度分析或投影减少 knob 数量。只有少数方法尝试压缩取值范围，但它们基于分桶或边界的策略对离群点敏感，可能错过有希望但探索不足的区域。因此，鲁棒且细粒度的搜索空间压缩仍是一个开放挑战。

MFTune 框架

为应对这些挑战，我们提出 MFTune——一个为 Spark SQL 配置调优量身定制的高效多精度框架。针对挑战一，我们设计了一个多精度优化框架，在不同精度级别上进行迭代评估，提前剪枝差配置以最大化预算效率。此外，我们还整合了专门为多精度范式定制的迁移学习和热启动机制，进一步加速收敛。针对挑战二，MFTune 识别代表性查询子集作为低精度代理，在显著降低评估成本的同时保持与全精度评估的高相关性。针对挑战三，MFTune 整合了基于密度的压缩机制，自动剪除不重要的 knob 并将取值范围收缩至有希望的区域。据我们所知，这是首个将多精度优化引入 Spark SQL 调优的工作。

图3：MFTune 系统架构与工作流

MFTune 由五个组件构成，围绕一个迭代式调优工作流协同运转：

（1）Controller（控制器）：与用户及 Spark SQL 服务交互，掌控整个调优流程。

（2） Knowledge Database（知识库）：存储当前任务与历史任务的观测数据和 meta-feature。

（3） Search Space Optimizer（搜索空间优化器）：从原始空间中识别出有希望的子空间。

（4） Configuration Generator（配置生成器）：推荐一批有潜力的候选配置。

（5） Multi-Fidelity Optimizer（多精度优化器）：构造精度层级，并在各层级间调度评估。

三个核心技术对应上面三个挑战：基于查询的精度划分（应对 C1/C2）、基于密度的搜索空间压缩（应对 C3），以及两阶段热启动 + 适配多精度的迁移学习（进一步加速收敛）。

基于查询的精度划分：用"代表性 SQL 子集"做低精度代理

MFTune 的关键洞察是：既然缩数据量、提前停止都不行，那就从"选哪些查询来跑"入手。它把在完整工作负载上的评估视为全精度（例如在 1TB 数据上跑 99 条查询），而一个 $\delta$-精度评估只花全精度 $\delta$ 比例的资源成本。问题被形式化为一个组合优化：在成本约束 $\text{Cost}(Q_\delta) \leq \delta \cdot \text{Cost}(Q)$ 下，选出一个能最大化与全工作负载配置排序相关性（用 Kendall-tau 度量）的查询子集 $Q_\delta$。MFTune 用一个贪心算法求解——从空集出发，每次加入使相关性增益最大的查询，直到成本触及 $\delta$。

那么排序相关性从哪来？直接在目标任务上估计需要大量昂贵的全精度评估。MFTune 的解法是从历史任务迁移证据。现实中"相同查询集、不同执行条件"的历史任务大量存在：数据规模演进、硬件/资源迁移、系统性能回归测试等场景下，查询集稳定不变，只是数据量、硬件、Spark 版本或资源环境在变。这些任务恰好能提供选取代表性 SQL 子集所需的证据。

基于密度建模的搜索空间压缩：knob 选择与范围压缩一体化

面对巨大的配置空间，MFTune 提出一个压缩算法。对每个相似源任务，它先取性能优于中位数的配置集合，再用 SHAP 做局部、值级、带符号的归因——只保留那些 SHAP 值为负（即真正降低延迟）的 knob 取值。拿到这些优质取值后，MFTune 不像已有方法那样直接用离散历史值的边界来定范围（这对离群点极其敏感），而是用加权核密度估计（KDE）去估计优质取值的经验密度，找出它们真正聚集的区域。分类型 knob 用离散形式的密度函数统一处理。

这一设计带来三个优势：（1）无需手动指定保留多少个 knob——knob 选择与范围压缩联合完成；（2）密度建模天然平滑噪声、抗离群点，还能保留邻近的未充分探索取值；（3）随着调优中源任务相似度估计越来越准，压缩空间可动态更新。

两阶段热启动 + 适配多精度优化的迁移学习

热启动面临经典的探索-利用权衡：用太少历史配置浪费迁移知识，用太多又挤占目标任务的探索预算。MFTune 设计了两阶段热启动：Phase 1 在调优开始时，从最相似历史任务里挑最优配置做全精度评估；Phase 2 则在多精度优化的每个内循环里，从"优于中位数"的历史配置集合中，按优先级注入一些候选配置，其余位置交给 BO 填充。这样既充分利用了历史观测，又不妨碍探索——弱的 Phase-2 配置会在低精度阶段就被过滤掉，不会浪费资源。此外，MFTune 借鉴 MFES和迁移学习思想，把"历史任务"和"不同精度的观测"统一视为源任务，按相似度加权组合代理模型；并通过对采集函数打分做排序聚合。

自适应历史数据可用性： MFTune 能根据不同的历史数据情况灵活调整策略。（1）当有同查询历史时，从一开始就激活精度划分、迁移学习和空间压缩；（2）当没有同查询历史（只有跨 benchmark 历史）时，先用全精度评估 + 迁移学习 + 空间压缩起步，等目标观测积累够了再在线构造低精度子集、激活多精度优化；（3）即使完全没有历史数据，也会先退化为 vanilla BO，随观测积累自动开启空间压缩和多精度优化。

实验结果

我们在 TPC-H 和 TPC-DS 两个基准上评估 MFTune，覆盖两种数据规模（100GB / 600GB）和 8 种硬件场景（节点数、CPU 核数、内存各异），并额外用 DSB 做可控的查询漂移分析。对比 6 个基线，涵盖不带迁移学习的方法（LOCAT、TopTune、BOHB）与带迁移学习的方法（Tuneful、Rover、LOFTune）。所有方法默认每个目标任务运行 48 小时。主要结论如下：

图4：主实验结果——六种场景下的调优性能

默认设置：MFTune 在两个基准上都取得最优最终结果，相比 6 个基线，在 TPC-H 上降低延迟 25.9%–43.1%，在 TPC-DS 上降低 37.8%–69.3%。带历史的方法整体优于从零开始的方法，而在带历史方法中 MFTune 收敛最强——因为其他方法只用全精度评估，不可避免地在差配置上耗费大量时间，MFTune 则用多精度优化在低精度就过滤掉它们。

跨 benchmark 迁移（源历史任务/目标任务来自不同 benchmark）：即便没有同查询历史，MFTune 也能先用迁移学习起步、再在线激活多精度优化，最终在 TPC-H 上降低 20.0%–32.5%、TPC-DS 上降低 35.7%–50.6%。

冷启动（无任何历史任务，预算延长至 96h）：MFTune 能在线识别并利用低精度代理。一旦多精度优化激活，收敛速度显著提升，最终优于所有无历史基线 16.3%–35.4%（TPC-H） 和 27.4%–48.2%（TPC-DS）。

泛化性能评估

图5：泛化性能——不同数据规模与硬件场景下的迁移效果

数据规模 / 硬件迁移：在实际应用中，历史任务和当前目标任务往往会具备不同数据规模或硬件环境。我们测试了 MFTune 在这些场景下的泛化能力。结果显示，MFTune 在所有场景下都取得最高加速比，在 600→100GB 迁移中峰值加速达 3.96×，硬件迁移中稳定保持 >2.18× 的加速，而基线波动明显。

消融与深入分析

图6：多精度优化消融实验

多精度优化机制：相比 w/o MF、数据量代理（DV）、以及适配后的 SQL-ISUM 代理，MFTune 分别降低延迟 27.8% / 45.1% / 25.6%。在 16 个 TPC-DS 工作负载上，我们的 SQL-Ours 在 1/9 和 1/3 精度下达到 0.847 / 0.968 的平均相关性，远超 SQL-ISUM（0.777 / 0.838）和 Data Volume（0.445 / 0.784）。

图7：搜索空间压缩机制分析

空间压缩：相比 w/o SC、Box、Decrease、Project、Vote 等策略，MFTune 最终降低延迟 14.8%–35.7%；在关闭热启动的压力测试下差距进一步拉大到 20.4%–43.0%，验证了密度建模的鲁棒性。

调优开销：相似度预测约 15s、精度划分 TPC-DS 约 21s，迭代级各项开销均在秒级，相比动辄数千分钟的配置评估可忽略不计。

总 结

本文提出 MFTune—首个面向 Spark SQL 配置调优的多精度框架。它通过基于查询的精度划分用代表性 SQL 子集提供准确、低成本的代理，克服"评估贵"的核心瓶颈；通过基于密度建模的搜索空间压缩联合完成 knob 选择与范围收缩，鲁棒地驾驭巨大的配置空间；并借助两阶段热启动与适配多精度的迁移学习在历史知识复用与高效探索之间取得平衡。在 TPC-H、TPC-DS 上的大量实验表明，MFTune 在默认、跨 benchmark、冷启动、跨规模/硬件、查询漂移等各种设置下均一致优于 6 个 基线方法，且额外开销可忽略，展示了将多精度优化引入大数据系统调优的巨大潜力。

实验室简介

北京大学数据与智能实验室（Data And Intelligence Research Lab at Peking Univeristy，PKU-DAIR实验室）由北京大学计算机学院崔斌教授领导，长期从事数据库系统、大数据管理与分析、人工智能等领域的前沿研究，在理论和技术创新以及系统研发上取得多项成果，已在国际顶级学术会议和期刊发表学术论文200余篇，发布多个开源项目。课题组同学曾数十次获得包括CCF优博、ACM中国优博、北大优博、微软学者、苹果奖学金、谷歌奖学金等荣誉。PKU-DAIR实验室持续与工业界展开卓有成效的合作，与腾讯、阿里巴巴、苹果、微软、百度、快手、中兴通讯等多家知名企业开展项目合作和前沿探索，解决实际问题，进行科研成果的转化落地。