LLM 不该替代查询优化器,该接在它后面做 plan-tuner
把 LLM 放在 optimizer 之后,以 JSON Patch 方式做局部计划微调,这条路比让 LLM 替代优化器更经得起工程治理的考验。
把 LLM 放在 optimizer 之后,以 JSON Patch 方式做局部计划微调,这条路比让 LLM 替代优化器更经得起工程治理的考验。
ETH 的一篇新论文用「把优化分支翻一下,看谁更快」这一招,在 PostgreSQL、MySQL、CockroachDB、MariaDB 上挖出 21 个此前未知的性能 bug。方法概念简单,Spark 这边的落地接口意外地齐整 —— spark.sql.optimizer.excludedRules 几乎就是现成的翻转开关。
Databricks 与 UPenn 把 LLM agent 当成离线 join-order 调优师,在 JOB 113 条查询上拿到 P90 -41% / 几何均值 1.288× 的提速,甚至超过"完美基数估计"。从 Apache Spark 一线视角看,这件事说明了什么、又没说明什么。
SQL Metrics 系列第六部分。以 TPC-DS q99(SF10000,Gluten/Velox)为例,逐算子解读每个指标,展示如何从指标中读懂查询执行的全貌。
SQL Metrics 系列第五部分。Gluten 如何将 Substrait 计划节点映射到 Velox 算子、跨管道聚合指标、遍历 MetricsUpdaterTree,以及聚合子阶段和 Shuffle 指标的内部机制。
SQL Metrics 三部曲的第二部分。指标如何从任务流向Driver,以及自适应查询执行(AQE)如何利用 Shuffle 统计信息在运行时重写查询计划。
SQL Metrics 三部曲的第三部分。如何通过 DataSource V2 API 扩展自定义指标、UI 如何渲染指标、以及如何通过 REST API 编程查询指标。
SQL Metrics 系列的第四部分。Apache Gluten 如何将 Velox/ClickHouse 原生指标桥接回 Spark SQL Metrics 框架,添加了 60+ 个原生 Spark 没有的指标。
Spark SQL Metrics 三部曲的第一部分。涵盖 5 种指标类型、100+ 指标的完整参考,以及如何正确解读 Spark UI 中的指标数字。
Apache Spark 4.1 引入了 Spark Declarative Pipelines(SDP),一个全新的声明式数据管道框架。作为 Spark PMC 成员,我来解读这个框架的设计哲学、核心概念,以及它如何改变数据工程的开发方式。