Spark向量化执行引擎选型与落地实践：从原理到调优

做了五年多的 Spark 调优，我越来越觉得很多团队把精力都放在资源配置、数据倾斜和 Shuffle 优化上，反而忽略了执行引擎本身带来的瓶颈。前段时间帮一个团队做专项性能优化，几十个核心 ETL 任务跑下来，最明显的规律不是某个查询写得差，而是 CPU 大量消耗在逐行处理、虚函数调用和 Java 对象序列化上，换了向量化执行引擎之后，单查询耗时直接砍半。这篇文章想把 Spark 向量化执行引擎的技术选型思路和落地实践完整梳理出来，给正在评估这个方向的团队一个可以照着做的参考。

这套方案到底能解决什么问题，一句话说清楚：如果你的 Spark SQL 任务以扫描、过滤、聚合、Join 这类重 CPU 计算为主，并且明显感受到集群 CPU 跑满但数据量不算夸张，那向量化执行引擎的收益通常非常可观。适合的读者包括数据平台工程师、Spark 运维同学，以及正在做执行引擎预研的技术负责人。接下来我按“为什么需要、怎么选型、如何落地、怎么排查”的顺序一步步讲。

1. 为什么需要向量化执行引擎：传统执行模型的瓶颈

1.1 火山模型的一次一行困境

Spark SQL 的默认执行模型继承自经典的火山迭代模型（Volcano Iterator Model），每个物理算子对外暴露一个 next() 接口，上层算子每调用一次，下层算子就往上传一行数据。这个模型优点是抽象清晰、算子之间解耦非常好，但代价也藏在里面：每一行数据穿过整棵算子树时，都要经过多次虚函数调用，CPU 的分支预测几乎失效，Java 对象的创建和回收也把 JVM 的 GC 压力拉得很高。

如果只是行数少、计算逻辑简单，这点开销不算什么。可一旦面对大宽表扫描，动辄几千万行甚至上亿行，行数乘上每个算子之间的调度成本，累加起来就是非常可观的 CPU 浪费。熟悉 JVM 的同学应该能理解，行式处理模式下，一行数据通常对应一个 Java 对象数组，列与列之间在内存里往往是离散的，CPU 从内存加载数据时 cache line 利用率很低，可能为了拿到一个字段，把一整条缓存行加载进来但是大部分字节都没用上。

这就带来了一个很现实的问题：很多 Spark 任务表面看是集群资源不够，其实本质上是 CPU 在做大量无用功。你把 executor 数量加一倍，确实能缩短时间，但成本也跟着翻倍。与其横向堆资源，不如从执行模型上做一次改造。

1.2 向量化执行到底做了什么

向量化执行的核心思路是“一次处理一批，而不是一次处理一行”。它会将数据以列式批量组织，每个批次包含固定行数，比如 1024 行或 4096 行，整批数据以列数组的形式在内存中连续存放，所有算子按列批量计算。

这个转变带来的好处是结构性的。第一，内存访问局部性大幅提升，CPU 遍历列数组时能够充分利用缓存，缺页和 cache miss 明显降低。第二，虚拟函数调用的次数从“每行一次”降为“每批一次”，算子调度开销几乎可以忽略。第三，列式批量数据天然适合 SIMD 指令，像 AVX2 这类单指令多数据技术，可以对一整个短整型数组做并行加法，性能提升非常直观。

如果你把行式处理类比成超市收银员对着购物清单一样一样扫码，那向量化执行就相当于整箱商品从传送带上过一遍扫码设备，速度完全不在一个量级。这也是很多 C++ 原生数据库引擎性能出色的底层原因之一。

1.3 与 WholeStageCodegen 的关系

提到向量化，很多人会问：Spark 不是早就有 WholeStageCodegen 了吗？这俩到底有什么关系？

WholeStageCodegen 是 Project Tungsten 引入的代码生成技术，它把一条查询链路中的多个算子融合成一个 Java 方法，消除了大量虚拟函数调用，这部分优化确实非常有效。但要注意，WholeStageCodegen 本质上还是在做行式数据运算，只是省去了算子间的调度开销，并没有改变“逐行处理”这个事实，也没有用到 SIMD 指令。

向量化执行引擎做的事情更底层，它连数据的组织方式都改了，从行式变成列式批处理。可以说两者并不冲突，但向量化的天花板明显更高。特别是一些复杂表达式计算，列式批量配合 SIMD 后，CPU 效率能够提升数倍甚至一个数量级。这也是为什么近年来 Spark 生态里向量化引擎越来越受关注。

2. 主流向量化执行引擎选型全景

2.1 Apache Gluten：开源社区的头号选手

目前开源领域讨论度最高、社区最活跃的 Spark 向量化执行项目，当属 Apache Gluten（孵化中）。Gluten 的思路非常巧妙：它没有重新实现一套 Spark 解析器和优化器，而是通过 Spark 的插件机制介入执行计划，把 Spark 的物理计划转换成 Substrait 中间表示，交给底层的原生向量化引擎执行。

这种做法带来的好处是巨大的。对上层业务来说，SQL 解析、逻辑优化、Adaptive Query Execution（AQE）、动态分区裁剪这些 Spark 已有的能力全部保留，不需要业务方改写任何 SQL。对底层引擎来说，它可以聚焦在真正的执行加速上，不用操心调度和容错。

Gluten 还内置了完善的回退机制，遇到原生引擎不支持的算子或数据类型，它可以自动回退到 Spark 原生执行，保证任务至少能跑。这个特性对生产环境非常关键，因为复杂 SQL 场景里总会出现一些边角语法或第三方 UDF，完全让原生引擎吃掉所有执行链路是不现实的。

2.2 Velox 与 DataFusion 底层运行时怎么选

Gluten 本身也是一个框架，它底下需要一个真正干活的 C++ 执行引擎。目前主流的两条技术路线是 Meta 开源的 Velox 和 Apache Arrow 社区的 DataFusion。

Velox 是 Meta 在 Facebook 大规模数据场景中打磨出来的 C++ 数据库引擎，性能调优和内存管理做得非常细，支持多种数据类型和算子，对复杂 Join、聚合、窗口函数的支持都很成熟。目前 Gluten 默认集成路线大多选择 Velox，社区压测数据也比较好看。

DataFusion 是 Rust 实现的 SQL 引擎，它在 Arrow 生态里位置很稳，代码质量和安全性都很好，而且 Rust 语言带来的内存安全优势能让很多隐蔽 bug 少很多。如果你的团队对 Rust 有积累，或者本身在 Arrow 生态里已经有其他组件，DataFusion 路线会更合适。

两条路线怎么选，我建议这样判断：如果你的核心诉求是极致性能、并且愿意接受相对复杂的 C++ 原生依赖，选 Velox；如果你更看重代码安全和与现有 Arrow 组件的协同，选 DataFusion。另外可以多关注两个社区的 release 频率和 issue 关闭速度，技术选型不是一锤子买卖，以后迭代维护的成本也很重要。

2.3 商业方案和云上托管服务

商业层面的向量化执行引擎最有名的就是 Databricks Photon。Photon 在 Databricks 的商业版 Spark 里默认启用，针对大规模 SQL 工作负载做了深度优化，性能提升非常明显，但代价是闭源且绑定 Databricks 平台。如果你的技术栈完全在 Databricks 上，不需要纠结，直接用 Photon 是最省事的选择。

云上托管服务也值得提一句。主流云厂商在推出 Serverless Spark 产品时，很多都在底层内置了类似的执行加速能力。这些服务的好处是开箱即用，不需要自己编译部署原生库；坏处是对实施细节不可见，遇到性能问题时排查手段受限，而且成本模型和自建集群差异较大。

我不建议一上来就一股脑投奔商业方案，先想清楚团队的可观测能力和问题定位手段是怎么构建的。开源方案虽然要踩坑，但坑是透明的，踩完自己能掌握整套调优方法论。

2.4 选型决策矩阵

为了更直观地比较几条路线，我整理了一张选型参考表。这张表基于我自己的项目经验，不代表绝对的数值结论，但方向值得参考。

3. 选型指标与落地前评估

3.1 技术兼容性评估

技术兼容性是我每次做选型时第一个要卡的硬指标。首先要确认你的 Spark 版本和 Scala 版本是否在引擎支持的范围内，向量化引擎跟随 Spark 版本迭代通常有一定滞后，如果集群还停留在比较老的 Spark 2.4，那基本不用考虑了，先升级 Spark 3.x 再谈向量化。

其次要盘点现有 SQL 的算子覆盖度。比如你的任务是不是大量使用自定义 UDF、用户自定义聚合函数（UDAF）、复杂数据类型嵌套，这些向量化引擎往往支持不完整。传统思路下，业务方随手写一个 UDF 是很常见的事情，但在向量化执行链路里，UDF 会导致整段执行退回行式模式，性能收益大打折扣。

还有一个很多人容易忽略的点是文件格式。向量化执行对 Parquet 和 ORC 这类列式格式天然友好，但如果你的表大量使用 JSON 或 CSV 纯文本格式，那向量化的加速效果会明显打折，因为光解析文本就已经耗费了大量 CPU。落地前先做一次表格式盘点，把高频任务的数据源情况摸清楚。

3.2 业务收益测算

选型不能只谈技术，收益测算是决策的重要一环。我常用一个简单公式来估算收益空间：一个查询在向量化前后的耗时差，主要取决于 CPU 计算占比；如果查询时间里有 70% 花在纯计算上，向量化引擎大概率能带来 2 倍以上提速；如果 70% 时间花在数据读取和网络传输上，那换引擎的效果就会很有限。

更靠谱的做法是在测试环境选 10 个左右线上真实 SQL，带真实数据量跑一轮基准测试，对比执行时间、CPU 使用率、GC 时间三个指标。这些 SQL 最好覆盖宽表扫描、多表 Join、大聚合、窗口函数这几类最典型的场景。用真实任务做测试，比跑 TPC-DS 得到的数据更有说服力，因为线上 SQL 的复杂度和测试集差距很大。

成本角度也要算一笔账。开源的 Gluten 虽然本身免费，但引入 C++ 原生依赖后，executor 的 off-heap 内存需求通常会上升，部署和排查也需要更多人力成本。如果性能提升只有 20%，那可能不建议折腾；如果能稳定提升 50% 以上，而且任务量足够大，这个项目就值得推进。

3.3 团队与运维准备

引入向量化引擎后，运维层面的变化比想象中更大。最直接的问题就是排查链路变长，以前 Spark 任务出问题，看 driver 日志、executor 日志基本能搞定，现在还要看原生侧的 crash 日志、core dump、gdb 堆栈，这对团队技能栈有要求。

如果团队里没有人熟悉 C++ 调试，至少要安排一到两个同学专门研究 Gluten 和 Velox 的日志体系和常见 crash 类型。另外要建议团队提前设计好灰度发布机制，保证可以先让小部分低优任务试跑，观察稳定后再逐步放量。这类引擎升级最忌讳一把梭，一旦出现大规模回退，业务方对平台的信任度会受很大影响。

3.4 灰度策略制定

灰度策略我会拆成三层来做。第一层是任务灰度，选择一批非核心、运行频繁、业务容忍度高的 SQL 任务开启向量化执行；第二层是资源灰度，让这些任务跑在独立的 executor 资源池里，即使出现 native crash 也不会影响核心链路；第三层是时间灰度，先从低峰期开始，观察 3 到 5 天后再慢慢覆盖高峰时段。

灰度期间要重点关注失败率、重试率、执行时间分位数这三个指标。如果遇到异常，优先检查是不是算子回退导致的性能劣化，而不是只盯着执行失败。我有一次就是因为某个查询热路径上的 Hive UDF 导致整体回退，性能反而比原生 Spark 慢，后来排查日志才发现是回退问题。

4. Gluten + Velox 部署实操

4.1 编译打包与二进制准备

以 Gluten + Velox 这条路线为例，落地前首先要解决二进制的问题。Gluten 本身是一个 Spark 插件 jar，但底层的 Velox 是 C++ 原生库，需要通过编译把 libgluten.so 和一系列依赖库一起打出来。

编译这块我强烈建议避开手动从头编译。除非你的构建环境非常干净且网络条件好，否则编译 Velox 依赖的第三方库非常消耗时间，踩坑概率也高。推荐直接到 Gluten 的 GitHub Release 页面下载预编译产物，或者使用社区提供的 Docker 镜像来做编译。自己编译时，命令大概是下面这个样子：

git clone https://github.com/apache/incubator-gluten.git cd incubator-gluten mvn package -Pbackends-velox -Prss -Pspark-3.3 -Pfull-scala-compiler -DskipTests

编译产物里最重要的两个东西是 gluten-velox-xxx.jar 和 libgluten.so。拿到这两个文件后，需要确保原生的动态库依赖能被 executors 找到，一般通过设置 LD_LIBRARY_PATH 环境变量或者把库文件放到统一系统路径下来解决。

4.2 环境部署三步走

部署过程概括下来就三步。

第一步，把 gluten-velox 的 jar 放入 Spark 的 jars 目录，或者通过 spark.jars 配置项显式指定路径。第二步，在 Spark 配置里启用 Gluten 插件，并指定后端引擎为 Velox。第三步，设置原生内存相关配置，保证 C++ 执行引擎有足够的 off-heap 空间可用。最小化配置模板如下：

spark.plugins=org.apache.gluten.GlutenPlugin spark.gluten.sql.columnar.backend.lib=velox spark.memory.offHeap.enabled=true spark.memory.offHeap.size=20g spark.gluten.sql.columnar.columnartorow=true spark.gluten.sql.columnar.maxBatchSize=4096

看到这里你可能会想，配置就这么点？其实 Gluten 的默认参数设计得比较保守，目的是确保开箱能跑。真正要调好，还需要结合自己的任务特征做参数调整，下一节展开讲。

4.3 内存模型与核心参数

这里有个很重要的概念要讲清楚：启用 Gluten 后，执行链路大部分内存都在 JVM 堆外（off-heap），由 Velox 自己的内存管理器来分配和释放。如果 spark.memory.offHeap.size 设置得太小，原生引擎很容易报内存不足；设置太大，又会挤压 YARN 容器里其他内存开销，导致容器被 kill。

我的经验是把 off-heap 大小设置在 executor 总内存的 40% 到 60% 之间，并且留足 system memory overhead。比如一个 executor 分配 8GB 内存，off-heap 给 4GB 左右比较合理。当然这个比例要视任务而定，如果是扫描和 Join 密集的任务，原生内存消耗会明显偏高。

maxBatchSize 也是一个值得关注的参数。它控制向量化引擎每个列批的最大行数，默认 4096。增大这个值通常能提升单批处理效率，但会吃掉更多内存；减小则更适合内存紧张的场景。遇到 off-heap OOM 时，第一反应不一定是加内存，先尝试把批大小调低往往更有效。

4.4 与 Spark SQL 生态的集成验证

部署完成后，先用一个最简单的查询验证链路是否通。比如执行一条全表 count 或者 group by 聚合，观察任务日志里是否有 Gluten 相关的初始化和执行记录。注意，很多老版本的 Spark UI 里不会直接展示底层引擎信息，你需要通过日志确认。

比较实用的验证方式是打开 SQL 的执行计划文本，看物理计划里是否出现了 ColumnarToRow、RowToColumnar 这类节点，这就说明数据确实走了列式转换链路。如果能看到，说明向量化执行已经在起作用。另一种方式是临时把插件禁止掉，跑同一个查询对比时间，用掐表的方式验证加速效果。

我建议部署后专门花半天时间跑一遍核心批处理任务集，不要只测一条 SQL。因为组件之间的兼容性问题，往往在复杂查询上才暴露出来。比如某些 Join 条件涉及复杂数据类型，Velox 可能暂时不支持，就容易触发回退；连插件本身都没生效，这是另一个排查方向，后面问题章节会提。

5. 性能验证与调优实战

5.1 用 TPC-DS 跑出可信基准

部署完成后的第一个动作是建立基准。TPC-DS 是大数据领域公认的决策支持基准测试，覆盖了复杂报表、多表 Join、子查询、窗口函数等丰富场景，用它在 Spark 上验证向量化引擎的收益非常合适。社区也提供了专门生成 TPC-DS 数据和查询语句的工具，可以配合 Spark 官方测试套件使用。

生成数据集时建议按目标环境的内存和 CPU 规模来确定比例因子，比如 1T 数据在中等规模集群上跑一轮完整测试可能耗时比较久，先用 100G 或 300G 快速摸清收益，再到生产数据规模上验证。每个查询建议跑两到三遍，取稳定值，避免集群抖动影响判断。

对比方案建议两组：Spark 原生执行作为 baseline，Spark + Gluten + Velox 作为实验组。统计每组的总执行时间、单个 query 的 P50/P95 耗时、GC 时间和 CPU 利用率。大多数场景下你会看到混合扫描和 Join 的查询提速明显，而设计简单的点查或纯 text 解析场景提升有限，这个结果分布对后续调优方向很有参考意义。

5.2 调优方向与关键参数

基准测试跑完，大概率会遇到一批性能不达预期的查询，这时候不要急着调参数，先做归因。查看这些查询的执行计划里是不是有较多的 RowToColumnar 和 ColumnarToRow 转换节点，这类转换本身有成本，如果转换频繁，可能是因为查询链路中有部分算子不被原生引擎支持，导致数据反复在行式和列式之间切换。

针对这种情况，我会优先调整 SQL 写法，把不支持的表达式改写为支持的等价形式，而不是强行调大内存参数。比如一些复杂的字符串处理函数，在 Velox 里的实现可能不如 Spark 原生完善，此时可以通过改写逻辑规避。

如果确认是原生计算侧的瓶颈，再考虑参数调整。常见做法包括适当增大 maxBatchSize、调整 Shuffle 分区数、开启并配合 AQE 使用。Gluten 支持很多 Spark 原有的执行优化，但一些规则可能与向量化引擎冲突，必要时需要在配置里显式关闭不兼容的优化项。参数调整以单变量控制为原则，一次只改一个，对比完再改下一个。

5.3 线上任务迁移策略

基准测试做到位后，开始往线上迁移。别一次性把所有 Spark-SQL 任务全部开启插件，这属于高风险操作。我的建议是按照任务类型分批执行，第一批选执行时间长、CPU 密集型、上游数据稳定的任务，这类任务一旦出问题影响面也比较可控。

迁移过程中要持续关注两个风险点：一是任务失败率有没有升高，二是任务运行有没有出现长尾。向量化引擎因为内存管理模式不同，部分原本正常运行的 JVM 内存参数需要重新调整，否则容易出现 container 被杀。另外，OOM 不一定表现为任务失败，也可能表现为频繁重算，需要结合 Spark UI 里的 Shuffle 读写量和任务重试次数来判断。

还有一个我踩过的坑，就是开启 Gluten 后，某些任务的输出数据量和原生模式不一致。这主要是数据类型转换精度或者字符串处理边界行为差异导致的，尤其是使用浮点数聚合的时候。建议优先在一致性敏感的任务上做数据校验，防止上游数据污染。

6. 常见问题与排查技巧实录

6.1 失效回退怎么识别

回退是 Gluten 最常用的兜底机制，但也是性能问题的隐藏来源。如果你看到查询能正常跑完，但耗时和原生 Spark 几乎没有区别，甚至在 Spark UI 里发现某些执行节点显示的是 Builtin 而不是 Velox，那就说明这部分已经回退了。

排查回退原因时，重点看 driver 日志里 Gluten 输出的 fallback 相关告警。常见触发因素包括：不支持的数据类型、不支持的函数、复杂结构上的某些高阶函数、以及部分自定义序列化逻辑。日志里会明确指出具体是哪个算子和哪个字段触发了回退，定位后优先改写 SQL 或调整数据类型。

如果回退比例控制在较低水平，比如 5% 以下，工程上是可以接受的。但如果核心查询热路径频繁回退，就需要认真评估是否达到了使用向量化引擎的门槛。

6.2 Off-heap 内存溢出处理

在向量化引擎场景里，OOM 大多不是 JVM 堆溢出，而是原生内存不足。表现形态通常是 executor 日志里出现 velox memory allocation 失败，或者 YARN 的 container 被系统 OOM Killer 杀掉。

处理思路从轻到重大概有三种：先减小 maxBatchSize，把单批内存峰值压下来；再适当调大 spark.memory.offHeap.size，不过注意别压榨系统 overhead；最后检查是否存在数据倾斜，倾斜导致单 task 处理的数据量异常，原生内存需求也会被放大。很多时候加内存不是最优解，解决数据倾斜才是根本。

从监控角度，强烈建议给 executor 挂上 native 内存监控。Gluten 项目在后期版本里提供了内存指标导出能力，配合 Prometheus 或 Ganglia 能看到原生引擎的内存使用曲线，这比等 OOM 日志再排查要高效很多。

6.3 Native 崩溃定位方法

原生库崩溃是向量化引擎落地中最头疼的问题。表现为 executor 突然丢失，日志里出现 hs_err_pidXXX.log 或者 core dump。这类问题往往不是 Java 栈能解释的，需要从两个方向入手定位。

第一个方向是检查 Gluten 和 Velox 的版本是否为较新 release，很多崩溃问题其实是底层组件 bug，社区修得很快，升级版本就能解决。第二个方向是收集崩溃现场，把 hs_err 日志、executor 日志、YARN container 日志统一归档，用 gdb 配合 libgluten.so 的调试符号获取 C++ 堆栈，然后到 GitHub Issues 里搜索关键词。这些问题的复现路径通常比较特定，把数据和执行计划反馈给社区，维护者一般能很快定位。

说了这么多，我自己实际用下来最深的体会是，向量化执行引擎不是万能药。它解决的是 CPU 执行效率的问题，对数据倾斜、小文件过多、网络 shuffle 瓶颈这些经典难题，并没有太多直接帮助。所以在引入之前，最好先把基础治理做好：合理的文件大小、规范的分区策略、够用的资源配额，再叠加向量化加速，效果才最明显。如果你的集群里恰好有不少重 CPU 的批处理任务，又愿意花一到两周时间做评估和灰度，那我会建议大胆试一试这条路。