-46% 还是 -2%?规则改写器只在自己家有效
在 TPC-H 10GB 上,一个学界 SOTA 的规则改写器把平均执行时间从 69.84s 砍到 37.57s,-46%。换到 DSB 10GB,同一个改写器把 32.62s 砍到 31.93s——只有 -2.1%。差距不在 query 难度,而在 benchmark 是不是它的训练集。“规则系统稳定可靠"很多时候是基准过拟合,不是工程事实。
Performance
翻转分支找性能 bug：ETH 的 BFA 方法，以及它对 Spark 意味着什么
ETH 的一篇新论文用「把优化分支翻一下，看谁更快」这一招，在 PostgreSQL、MySQL、CockroachDB、MariaDB 上挖出 21 个此前未知的性能 bug。方法概念简单，Spark 这边的落地接口意外地齐整 —— spark.sql.optimizer.excludedRules 几乎就是现成的翻转开关。
只让 LLM 改 SQL,几乎什么都不会发生
在 TPC-H 10GB 上,直接让 GPT-4o 改写 SQL,平均执行时间从 78.81s 降到 74.92s——几乎等于没改。换一个开源 14B 模型,喂 plan、加 reward、训一遍,同样的工作量降到 29.67s。LLM 在 SQL rewrite 上能不能工作,不取决于 LLM 多强,取决于你愿不愿意给它真正能改 SQL 的信号。
LLM 做 Join Order：从 Databricks 的实验,看 Apache Spark 视角下的三层落地阶梯
Databricks 与 UPenn 把 LLM agent 当成离线 join-order 调优师,在 JOB 113 条查询上拿到 P90 -41% / 几何均值 1.288× 的提速,甚至超过"完美基数估计"。从 Apache Spark 一线视角看,这件事说明了什么、又没说明什么。
深入 Spark SQL Metrics（第六部分）：实战——TPC-DS q99 的 Gluten 指标全解读
SQL Metrics 系列第六部分。以 TPC-DS q99（SF10000，Gluten/Velox）为例，逐算子解读每个指标，展示如何从指标中读懂查询执行的全貌。
深入 Spark SQL Metrics（第一部分）：类型、完整参考和含义
Spark SQL Metrics 三部曲的第一部分。涵盖 5 种指标类型、100+ 指标的完整参考，以及如何正确解读 Spark UI 中的指标数字。
spark-advisor：AI 驱动的 Spark 性能工程师
spark-advisor 是一个 Agent Skill，将你的 AI 编程助手变成 Spark 性能工程师——诊断慢作业、检测数据倾斜、对比基准测试、生成可操作的调优建议。