摘要：导读本文源于#数据库架构 峰会，由陈韦廷老师分享，主题为“Apache Gluten 的现在与未来”。本次分享聚焦于一个负责将基于 JVM 的 #SQL 引擎的执行任务分流到#原生引擎处理 的中间层设计的项目 Apache Gluten。

导读本文源于#数据库架构 峰会，由陈韦廷老师分享，主题为“Apache Gluten 的现在与未来”。本次分享聚焦于一个负责将基于 JVM 的 #SQL 引擎的执行任务分流到#原生引擎处理 的中间层设计的项目 Apache Gluten。

本期内容围绕着以下几点展开：

1. Apache Gluten 背景介绍

2. Apache Gluten 性能实现

3. Apache Gluten 应用现状与客户实践

4. Apache Gluten Roadmap

5. Q&A

分享嘉宾｜陈韦廷 英特尔 Software Manager

编辑整理｜王震南

内容校对｜李瑶

出品社区｜DataFun

01

Apache Gluten 背景介绍

首先介绍一下 Apache Gluten 项目要解决的问题。

1. 面临的问题

（1）问题一：Spark 性能提升瓶颈

最初发现的问题是存在于 #Spark 框架中的性能问题。Spark 是一个基于 Java 的大数据处理架构，其查询优化器采用基于行式的优化策略进行处理。

通过 TPCH 经典查询，对 Spark 1.6 至 Spark 3.2 版本中 HashAgg（聚合操作）、HashJoin（高效连接操作）、TableScan（全表扫描）等特定 operator 的性能指标进行测试，数据表明，从 Spark 2.4 版本后就不再有大幅度性能提升。

（2）问题二：Spark 在 Intel CPU 的健壮性不足导致瓶颈

Databricks 公司在应用中发现，Intel 的 CPU 是瓶颈所在。通过 TPCH 技术进行监控，得出的数据显示，在绝大部分查询执行时，CPU 的使用率都会达到 80%-90% 的程度。因此尝试采用基于 C++ 而不是 Java 的实现方式，改用本地计算引擎来提升性能。

另外，传统的 Spark 架构在实际执行时，只有一开始的扫描是以列为单位，之后的算子会基于行式驱动进行数据处理，使 Intel 本身的一些特质难以得到发挥，例如 AVX 技术必须要基于列式计算才能发挥作用。

为解决上述问题，成立了 Gluten 的前身——Gazelle 项目，核心目标为：

2. Gluten 项目概要

Apache Gluten 是由英特尔（Intel）和 Kyligence 发起的第二代 Spark 原生 SQL 引擎。主要工作包括：

#Gluten 项目的核心目标是构建一个承上启下的“桥梁”，以 Substrait 为基础，打造统一的标准化查询计划中间层。从结构上，自上而下地结合 Spark 框架，中间经过 Spark 物理计划设置，然后转到 Gluten 中间层转成Substrait plan 做一个统一的定义，之后再结合到不同种类型的原生后端。

进入本地计算库，Spark 从基于 Java 转成基于 C++，因为不同的后端引擎会在本地计算，所以定义了统一的 JNI 接口。这一层 JNI 架构设计，实现了算子下推到本地计算引擎（Native）的方式，而不使用 JVM 的方式执行，因此可以得到更好的性能提升。

Gluten 项目存在 fallback 机制，即当查询计划不能执行，或者有程序崩溃时，也能保证任务执行。因为项目初期功能表现欠佳，现阶段与 Spark JVM 协作，当有算子或是功能支持失败时，就会回退到 JVM 执行，以保证查询计划的执行成功。

02

Apache Gluten 性能实现

1. Gluten 项目架构

Gluten 以中间层为核心，向上承接 Spark 框架，向下对接不同种类型的后端本地计算引擎。

在Gluten1.1版本，团队决定投入到两个比较主流的计算引擎：Velox，ClickHouse。

ClickHouse 的工作是交给 Kyligence 团队来维护，包括源码管理和规划；Gluten 团队主要负责 Velox 相关工作，包括查询计划的转换、算子下推等。

有部分查询任务可能会在中间层实现，不一定是所有的算子都会往下推到本地库。如果有新的后端技术出现，也可以通过 Gluten，迅速与 Spark 框架结合。一些 FPGA 厂商已将 Gluten 整合到其产品中，以 Gluten 作为中间层，针对特定算子下推到 FPGA 做加速。

2. 核心特性

（1）Spark 框架保留

Spark 框架被证实是可以运算 TB 甚至 PB 量级数据的卓越计算框架，因此 Gluten 保留了 Spark 的 Driver\Worker\Executor 节点，直到 Task 执行过程。

Spark 2.4 版，发展出了一个为拓展 GPU 而设定的 public common API 接口。Gluten 结合这个接口，采用插件形式实现 Spark 对接，使得本地计算引擎得以在 Spark 里运作。实际执行逻辑是在单一任务里去做判断，监测 Operator 是否被本地库执行。若 Operator 执行，就通过 Gluten 插件，对接 JNI 接口下推算子，然后选择后端引擎类型执行。若 Operator 没执行，就执行 fallback，回到 JVM 计算引擎做执行。

资源缩放机制保留在 Spark 中执行，包括资源分配、内存大小、Task 执行调用等。Gluten 监测 Operator 执行，是通过实际单一任务执行时，观测 Operator 能不能够被执行成功。在实际 Gluten 的查询计划 执行中，还需要分多个不同的标签分析，而不仅只看 Operator 执行程度来判断是否下推算子到本地计算库去做执行。

（2）单一后端的执行实现

目前 Gluten 项目只能够选择单一后端引擎，即你选择 Velox 引擎，那么在编译（Compiler）阶段，就是使用 Velox 引擎做编译器。在实际执行阶段，就是使用 Velox 引擎去实际执行。

在未来，尝试通过成本模型（Cost Model）进行后端引擎的消费分析，以进行引擎的策略选用，即有多个不同种类型后端，在实际分析时，通过在 Gluten 中的成本模型，去分析在哪一个后端的消费是最低的，性能是最优的，然后就可以针对 Spark 里的不同策略，调用不同后端去做执行。

当前 Gluten 采用 Velox 进行数据转换。为了提高更好的性能表现，现阶段还是以 Velox 为主。当下 Velox 和 Apache Arrow 本身的数据转换，两个社区已经在沟通做结合和兼容性支持，在未来，希望通过 Apache Arrow 打造中间层的统一的数据转换。

未来，如果 Apache 社区可以实现其愿景，Gluten 将打造一个统一的接口，以及统一的数据资产，在不同类型的后端去做数据转换设计。

为什么不统一用某一个后端引擎？

因为 ClickHouse 采用 LLVM 语言，而 Velox 采用 C++ 语言，两种语言的差异性以及框架本身的不同会导致 query 执行的优势不同。ClickHouse 针对那些比较小型的查询，会有比较好的性能表现；而 Velox 则对较为复杂的查询性能表现更优。

Gluten 当前以 ClickHouse 和 Velox 为主，加速器为辅，未来致力于打造成一个能够自动选择不同后端实现最佳执行效率的超级平台。

3. 重要组件

（1）Plan Conversion

Gluten 的 Plan Conversion 主要负责查询计划的转换与优化。将 Spark 的物理计划下推到 Substrait plan，然后根据后端类型设计不同的 pipeline 去执行。

当前，批框架以 Spark 为主，流框架在国内是以 Flink 为主。Gluten 目前只针对 Spark 做设计，未来也将纳入 Flink，实现统一集成。

因为通过 Substrait 中间层实现统一的查询计划框架，所以在新计算框架引入时，只需要考虑中间层 Substrait plan 的转换问题，而不需要考虑后端转换；同样，在结合不同计算引擎时，也只需要考虑 Substrait plan 如何去转换。

（2）Fallback

当 fallback 产生时，数据本身就会存在一个列式转行式的转换过程。列式转行式的转换过程中，会出现另外一个行式转列式的副本，这就会存在一个内存副本，因为必须做数据本身的转换，就会特别耗时间，这常常是性能表现上的一大痛点。

在 Gluten 项目中把 C2R、R2C 的设计都改为本地原生化，即使用 C++ 去改写框架，用本地计算的方式去执行。

未来的愿景是对所有 operator 都有支持，不会产生 fallback，但短期内仍难以避免。所以在 Gluten 项目中建立了 fallback 策略的调整和优化机制。提供了三种不同类型的 fallback：

针对特定场景设定合适的阈值，以得到最好的性能表现。

（3）列式 Shuffle

Gluten 改写了传统行式 shuffle，使用列式 shuffle 来更好地提速，这样也可以避免 fallback 问题（即 C2R\R2C 的数据转换问题）。

列式 shuffle 还可以带来一些额外好处：

（4）Memory Mgr.

内存管理也是备受关注的一个方面。在 Gluten 项目中，采用 Spark 统一的参数变量，对内存做统一的管理，实现的模式是 Off Heap Memory（堆外内存），这是 Java 中一种不受 JVM 堆内存管理机制约束的内存区域，其分配和释放由操作系统直接管理。

调整 Spark 中的 Off Heap 参数，通过调用这个参数做内存的统一管理，调整过程中，当流转到本地计算库时候，本地计算是可以直接通过 Off Heap 部分的内存做分配，即直接让本地计算的内存调用直接在 Off Heap 内存中使用。

03

Gluten 应用现状与客户实践

1. Gluten 应用现状

以下列举了一些与 Gluten 相似的项目供大家参考：

Gluten 项目以现有 TPC-H/DS 的性能表现作为基础点，基于 Intel 最新平台实测，结果显示，相比于原生 Spark，使用 Gluten 可以达到 H 3.3 倍、DS 2.7 倍。

关于 Gluten 项目中的功能覆盖程度：

常见的 Spark Operators 大概有 90 多个，其中客户有需求的约 37 个，对这 37 个 operator 的覆盖率达到了 84%。

常见的 289 个 Spark Functions 中有 92% 已覆盖。

常见的 16 种数据类型，覆盖率达到 93%。

安装和文档覆盖率达到 60%，这让 Gluten 项目实现了高可用。

应用版本更迭如下图所示。目前最新版本为 Gluten 1.3，预计今年 4 月会发布Gluten 1.4 版本。在 1.3 版本中，包含 1000+ 已合并的 PR。现有规划基本上每季度会更迭一个大版本，每个小版本更迭都是按需排期。

下图中还列出了一些重要的 Customer Milestone，用户涵盖了国内主流大厂，其产品如采用本地计算，都是使用 Gluten 作为产品核心，在此基础上去研发他们各自的产品。

以下是更多性能数据供参考。

2. 客户实践

以下是 Gluten 产品的公开客户清单，在 https://gluten.apache.org/poweredby/ 有详细展示。

最大的客户之一——美团，在私有云环境中，已经有超过 10 万个任务采用 Gluten。

以下是关于 Gluten 应用发表的公开刊物：

04

Gluten Roadmap

最后，分享 Gluten 的未来工作规划。

05

Q&A

Q1：由于 Java 本身存在一定局限性，Gluten能够帮助我们更好地利用硬件能力。但随着 Java 在 Native 计算上增加更多功能，未来是否也可以通过新版本 JDK 实现向量计算等能力呢？

A1：首先，Java 对 Native 列式计算是支持的，但是 Spark 本身的源码并没有迭代，所以 Spark 需要对源码做很大改进才能实现对 Java 的技术支持。当下 Gluten 做过一些评估，实际原生 JDK 如果有支持一些本地化功能，那么性能上比 C++ 并没有很大差距。从硬件角度来看，Intel 希望 C++ 和 Java 都可以支持硬件加速技术（如 AVX）。但现在的 Spark 性能不够优越是因为其无法支持 AVX 这些技术。

Q2：在对硬件加速的尝试中发现，加速能力的实现受到场景限制，比如在一些查询上它的瓶颈不在 CPU，而是可能在 IO 上。Gluten 是否也是有一些特定适用范围呢？

A2：在分享中提到，TPC-H/DS 的性能表现会有 3.3 和 2.7 倍提升。但实际很多用户用 Gluten 实践时，可能并不能达到这样的性能表现，可能只有 1.5 倍。经研究发现，Gluten 在客户平台上的瓶颈改变了，之前的经验是瓶颈在 CPU 使用率上，而客户环境中瓶颈却转移到了 IO 上，这意味如果 IO 没有对应升级，就无法享受到 Gluten 可以带来的加速效果。达到理想的性能提升需要特定的环境：硬件设备包括使用 7-8 块的 NVM 硬盘；网络传输需满足 100GB。

Q3：现在有什么比较好的关于 Spark\Gluten\Velox 单步调试和分析方法吗?

A3：在官网公布了一系列参数，可供参考。后续也会推出一些 Performance Guide 指导用户如何调优。另外，我们也收集了很多客户实际落地的资料，后续也会公布出来。

Q4：Gluten 在数据湖方面的后续动向是什么？

A4：数据湖方面目前主要支持 DeltaLake、Iceberg 和 Hudi，针对不同版本进行了一些绑定，所以实际落地时需要注意版本问题。目前主要支持 Read 的功能。Write 方面，因为涉及不同数据类型，需要进行转换，过程会比较复杂，所以目前只是与一些特定客户合作，根据实际应用场景，定制化对 Write 的支持。

以上就是本次分享的内容，谢谢大家。

来源：DataFunTalk