Gluten 项目主要用于“粘合” Apache Spark 和作为 Backend 的 Native Vectorized Engine。Backend 的选项有很多,目前在 Gluten 项目中已经明确开始支持的有 Velox、Clickhouse 和 Apache Arrow。通过使用Native backend 执行计算,加速 Spark 执行速度,目前在TPCH 测试中使用 velox backend 得到了最多3.6倍加速。下图为 Gluten 整体架构
plan conversion
spark physical plan 作为输入,使用 substrait 将其转换为 substrait plan,substrait plan作为一个统一的执行计划传递给不同的 native library,在不同的 library 中执行相同的的 pipeline,使用 library自己的算子执行 pipeline
buffer passing & sharing
gluten 提供两种方法来进行 spark JVM 和 native engine 之间的数据传输,如下图所示
- 下图中的绿线。使用 apache arrow 作为内存数据格式,将 velox 中的 velox 格式数据转换为 arrow 格式,使用 arrowColumnarVector 和 spark API 通信。
- 第二种方法对第三方数据格式进行了支持,如下图中的红线。对于 clickhouse 数据格式创建了clickhouseVector,使用 clickhouseVector和 spark API 通信。这种方式性能更好,gluten 还在实现下图蓝线使得 velox 性能更好
Fallback Processing
有一个 validate phase 来检验 stage 中的算子是否被 native engine 支持,如果支持则将物理计划的节点替换为 transformer,不支持则仍使用原生 spark的算子,并在算子的前后加上 columnTorow和 rowTocolumn 算子进行格式转换,这两个算子都是用 native library实现的,这会带来额外的开销影响性能
gluten shuffle
为了针对列式数据进行 shuffle ,gluten 实现了面向列式数据的 shuffle operator(重用了 gluten 前身 gazelle 的代码)
memory management
由 spark 来控制 JVM 和 native library 使用的内存,velox 同时也支持在内存不足时将数据 spill 到磁盘。由于 Native 代码和 Spark Java 代码在同一个进程中运行,因此 Gluten 具备了统一管理 Native 空间和 JVM 空间内存的条件。在 Gluten 中,Native 空间的代码在申请内存的时候,会先向本地的 Memory Pool 申请内存,如果内存不足,会进一步向 JVM 中 Task Memory Manager 申请内存配额,得到相应配额后才会在 Native 空间成功申请下内存。通过这种方式,Native 空间的内存申请也受到 Task Memory Manager 的统一管理。当发生内存不足的现象时,Task Memory Manager 会触发 spill,不管是 Native 还是 JVM 中的 operator 在收到 spill 通知时都会释放内存。
debug
如果问题来自spark需要运行spark和native library来debug(阴影部分)。如果问题出在 native library,可以将数据和substrait plan dump 下来,只使用 native library 进行复现问题
参考
https://www.youtube.com/watch?v=0Q6gHT_N-1U
https://gluten.apache.org/