Data 开始 S 上雕花了？Spark Native 执行引擎请求出战

大数据相关的技术已经过了高速发展的阶段，这两年颠覆性的创新几乎已经绝迹了，业界基本上是在现有的能力上做优化（通俗一点说就是 shift 上雕花）。不少在大厂的朋友也纷纷表示 Data 部门比较养老，每天的主要工作就是在群里回答用户问题、修修bug、摸摸鱼，除了要写日报、周报、应付其他团队的内卷之外，性价比还是挺高的。

这一方面说明 Data/Infra 这个方向是业界不可或缺的一部分，能穿越周期，找一份工作还是比较容易的。而另一个方面也说明了 Data 进入了瓶颈期，表现在技术已经逐渐成熟、创新匮乏等。

据我所知，目前 Data 有几个方向还在持续创新，值得深入研究，一个是 Native 执行引擎，一个是多模态数据，再有就是向量+搜索，可能还得算上云原生，但是云原生方向的创新也已经到了瓶颈。

这篇文章我们先来聊聊 Native 执行引擎。

Vol.1

什么是 Native 执行引擎？Native 执行引擎也叫向量化执行引擎，关于它的定义可以参考 ChatGPT 的回答。

简单来说就是一次让 CPU 处理多条数据，极致的压榨 CPU 性能，最早把这件事做到极致的就是 ClickHouse。所以到现在为止，Clickhouse 身上的暴力美学标签一直都没撕掉，业界对它的刻板印象就是“手摇高速发动机”，优点是高速，缺点就是需要手摇。

几年前使用 Spark、Trino 这些技术做 ETL、OLAP、数仓的基建已经非常成熟了，已经解决了有没有的问题，下一步要解决的就是快不快和成本的问题。

其实在一家稍微成规模的厂子里，Data 部门总要给自己找点事情干（尤其是开源节流的当下），而性能提升、成本降低带来的价值无疑是最显而易见的，也是最容易量化的。

再叠加 Spark 的母公司 Databricks 在自己闭源的版本里实现了向量化执行引擎，性能上吊打开源，甚至可以说现在 Spark 开源版本处于摆烂状态。一时之间出现了众多要给 Spark 提供向量化执行引擎的方案。

Vol.2

上述提到的方案中有这么几种流派：

先强调一点，开源界的方案几乎都不成熟，真正敢在生产环境使用 Spark Native 执行引擎的公司还是极少数。不妨先看一下这几个流派的方案，方便日后选型。

首先是做的比较早的 Gluten 项目 https://github.com/apache/incubator-gluten, 最早是 Intel 开源的 OAP，我记得三四年前接触他们的时候 TPC-H 性能只比原始 Spark 快 20% 左右，个别查询确实能快 3-4倍。后来 Kyligence 和 Intel 的负责人勾兑了一下，一起联合开发，把名字改成了 Gluten。

其实它做的事情相对稳重一些，底层的后端支持了 ClickHouse 和 Velox，中间通过序列化协议把 Spark 的 Physical Plan 转换成 ClickHouse 的查询或者是 Velox 的执行计划。去年的时候 Gluten 发布了相对成熟 1.x 版本，一些简单的坑算是踩完了，今年捐献给了 Apache 基金会孵化。从用户质量来看，还是有不少知名的公司试用的。

Gluten 走的是 Velox 和 ClickHouse 流派，还有个流派基于 Arrow/Datafusion，关于 Arrow 的介绍参见聊聊数据领域年轻的 OG。

先是有快手开源过 Blaze 项目 https://github.com/kwai/blaze，也有将近两年的时间了。从 Github 的 issue 来看，大概率是又是个大厂开源的玩票项目，随着人员的变动或者资源的变动，最终会不了了之。

最近 Datafusion 项目从 Arrow 的子项目升级成了正式的 Apache 顶级项目， Datafusion 作为一个完整的计算引擎，有了更广阔的发展空间，所以他们在刚刚升级没两天，就马不停蹄地开了 datafusion-comet 这个子项目，目的是拓展 Datafusion 的生态。从刚开源 3 个月就收获了 400 个 star 来看，成绩还算不错。值得一提的是 Datafusion-comet 也进入了 Apache 孵化器，没准有一天也变成了顶级项目。

这几个流派虽然有些差异，使用的向量化执行引擎有所差异，甚至执行引擎的开发语言也各异，Velox 和 ClickHouse 是 c++，Datafusion 是 Rust。但其背后的思路都大同小异，沿用 Spark 的 DataFrame 和 SQL API，只把最终的物理执行计划以某种格式序列化，并且通过跨语言的FFI接口传递给后端执行引擎，执行引擎先试着计算，如果成功那么万事大吉，如果失败则回退到 Spark 原始的物理执行引擎。

https://github.com/apache/datafusion-comet

Vol.3

上一章节介绍了几种开源技术，算是相对比较成熟的了，但还远远称不上成熟。如果要硬着头皮从中选择一个用，我会选 Gluten + ClickHouse 的方案，原因无非是 ClickHouse 的计算能力已经得到了充分验证，但是这个方案的主要贡献方 Kyligence 把 Gluten 相关的研发裁得差不多了，也挺让人捉急的。至于 Velox到现在为止都没有一个哪怕是 0.x 的版本号，根本不敢在生产放心使用。而 Datafusion-comet 刚刚开源三个月，很多能力还没补齐，还在快速迭代中。至于Blaze，如果想入职快手，倒是可以试试，否则以大厂们开源的风格，不太建议用。

不过从长远来看，我个人更看好 Datafusion-comet，毕竟是有一些正儿八经的社区和公司在维护，Datafusion 背后的公司也在积极维护。

其实看了一圈这些 Spark Native 执行引擎，总感觉不伦不类。不妨回想一下 Native 执行引擎的优势在哪里，肯定是快、省资源，但如果是使用 Spark 做 ETL，Native执行引擎确实会带来效率提升，但也间接造成系统不稳定，明显有些得不偿失，毕竟对于 ETL 任务来说稳定比高效很多时候更重要。

如果是基于 Spark 做 OLAP、数据湖查询的场景，追求效率、性能其实有更多更好的选择，比如直接用 ClickHouse，或者 Doris、Trino 这些专职的 OLAP 数据库，甚至近两年出现的新兴的 OLAP 数据库，已经把向量化作为标配，再抱着十几年前的 Spark 技术做 OLAP，实在是没必要。

所以，如果是 5 年前，业界没有更好的方案，给 Spark 加 Native 执行引擎是个很好的选择，这也是为啥 Databricks 把自研的 Native 执行引擎闭源了的原因，确实有不小的壁垒。但是现在重新再看，这件事就没那么有必要了，所以这些项目看上走在技术的前沿，其实可能一开始的方向就错了，我本人一个都不看好。那么，有没有更好的选择？后续的文章中我们再来讨论。