向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会

发布时间:2022-08-17 14:35

近日举办的 Databricks Data & AI Summit 2022 上,来自 Intel 的陈韦廷和来自 Kyligence 的张智超共同分享了 Intel 和 Kyligence 两家企业自 2021 年合作共建的全新开源项目「Gluten」。这也是 Gluten 首次在全球平台上亮相,今天我们将一起通过本文进一步了解 Gluten。

Gluten 项目旨在为 Apache Spark 注入 Native Vectorized Execution 的能力,极大优化 Spark 的执行效率和成本。目前,Gluten 社区的主要参与方有 Intel、Kyligence 等。

“ Kyligence 企业级产品源自 Apache Kylin,今天,两者在离线数据处理、即时查询分析等方面,都深度集成了 Spark 的能力。通过 Gluten 这一开源项目,Kylin 和 Kyligence 企业级产品将有效提升 OLAP 查询性能和执行效率,尤其是在云原生版本 Kyligence Cloud 中,将更大程度地降低整体拥有成本(TCO),提高云端数据分析的成本效率,加速大型客户从传统数据分析架构转向云原生数据湖架构的进程。”
                              ——Kyligence 联合创始人兼 CTO 李扬

1. 为什么需要 Gluten

近年来,随着 IO 技术的提升,尤其是 SSD 和万兆网卡的普及,大家基于 Apache Spark 的数据负载场景遇到越来越多的 CPU 计算瓶颈,而不是传统认知中的 IO 瓶颈。而众所周知,基于 JVM 进行 CPU 指令的优化比较困难,因为 JVM 提供的 CPU 指令级的优化(例如 SIMD)要远远少于其他 Native 语言(例如 C++)。

同时,大家也发现目前开源社区已经有比较成熟的 Native Engine(例如 ClickHouse、Velox),具备了优秀的向量化执行(Vectorized Execution)能力,并被证明能够带来显著的性能优势,然而它们往往游离于 Spark 生态之外,这对已经严重依赖 Spark 计算框架、无法接受大量运维和迁移成本的用户而言不够友好。Gluten 社区希望能够让 Spark 用户无需迁移,就能享受这些成熟的 Native Engine 带来的性能优势。

无独有偶,前不久 Databricks 在 SIGMOD 2022 发表了一篇关于 Photon 项目的文章“Photon: A Fast Query Engine for Lakehouse Systems”[1],文章详细描述了 Databricks 如何在 Apache Spark 中集成 Photon 这一 Native 子系统,通过向量化执行等方面的优化,为 Apache Spark 带来执行性能的大幅提升。Gluten 项目在 Photon 公开前就已独立地立项和启动,不过我们看到在实现思路和加速效果上两者具有一定的相似性。

下图来自 Databricks 公开的演讲材料[2],从图中可以看出引入 Native Vectorized 引擎(Photon)的性能收益,胜过过去 5 年来所有性能优化的总和。而性能的提升又可以带来 Spark 使用体验的提升和 IT 成本的下降,这一点在企业用户动辄使用成百上千台服务器用来运行 Spark 作业的今天,是非常诱人的进步。目前 Photon 并不开源,因此 Gluten 项目可以很好地填补行业在这里的空白。

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第1张图片

2. Gluten 项目是什么?

Gluten 这个单词在拉丁文中有胶水的意思,Gluten 项目的作用也正像胶水一样,主要用于“粘合” Apache Spark 和作为 Backend 的 Native Vectorized Engine。Backend 的选项有很多,目前在 Gluten 项目中已经明确开始支持的有 Velox[3]、Clickhouse 和 Apache Arrow。

从这个定位出发,我们结合下图可以大致看到 Gluten 项目需要提供哪些能力:

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第2张图片

 2.1 Plan Conversion & Fallback

这是 Gluten 最核心的能力,简单来讲就是通过 Spark Plugin 的机制,把 Spark 查询计划拦截并下发给 Native Engine 来执行,跳过原生 Spark 不高效的执行路径。整体的执行框架仍沿用 Spark 既有实现,包括消费接口、资源和执行调度、查询计划优化、上下游集成等。

一般来讲,Native Engine 的能力,无法 100% 覆盖 Spark 查询执行计划中的算子,因此 Gluten 必须分析 Spark 查询执行计划中哪些算子是可以下推给 Native Engine 的,并将这些相邻的、可下推的算子封装成一个 Pipeline,序列化并发送给 Native Engine 来执行并返回结果。我们依赖了一个独立的名为 substrait 的开源项目[4],其使用 protobuf 来实现引擎中立的查询计划的序列化。

对于 Native Engine 无法承接的算子,Gluten 安排 fallback 回正常的 Spark 执行路径进行计算。Databricks 的 Photon 目前也只是支持了部分 Spark 算子,应该是采用了类似的做法。

在线程模型的角度,Gluten 使用以 JNI 调用 Library 的形式,在 Spark Executor Task 线程中直接调用 Native 代码,并且严格控制 JNI 调用的次数。因此,Gluten 并不会引入复杂的线程模型,具体示意可参考下图:

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第3张图片

 2.2 Memory Management

由于 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 通知时都会释放内存。

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第4张图片

 2.3 Columnar ShuffleShuffle

本身就是影响性能的重要一环,由于 Native Engine 大多采用列式(Columnar)数据结构暂存数据,如果简单的沿用 Spark 的基于行数据模型的 Shuffle,则会在 Shuffle Write 阶段引入数据列转行的环节,在 Shuffle Read 阶段引入数据行转列的环节,才能使数据可以流畅周转。但是无论行转列,还是列转行的成本都不低。因此,Gluten 必须提供完整的 Columnar Shuffle 机制以避开这里的转化开销。

和原生 Spark 一样,Columnar Shuffle 也需要支持内存不足时的 spill 操作,优先保证查询的健壮性。 

2.4 Compatibility

用户出于所在公司技术栈的考虑,可能会偏向使用兼容不同的 Native Engine。因此,Gluten 有必要定义清晰的 JNI 接口,作为 Spark 框架和底层 Backend 通信的桥梁。这些接口用来满足请求传递、数据传输、能力检测等多个方面的需求。开发者只需要实现这些接口,并满足相应的语义保障,就能利用 Gluten 完成 Spark 和 Native Engine 的“粘合”工作。在 Spark 一侧, 目前的架构设计中也预留的 Shim Layer 用来适配支持不同版本的 Spark。

2.5 其他方面的优化除了使用

Native 代码挖掘向量化执行的性能收益,Photon 的性能收益也来源于其他方面的优化(主要是查询优化器),不过这些优化很多并未开源,Gluten 项目也在不断吸纳这部分的开源版本的优化。

3. Status & Roadmap

目前 Gluten 社区已经完成 Velox Backend 和 Clickhouse Backend 在 TPC-H 数据集上的验证工作。两种 backend 在 TPC-H 1000 数据集下的性能表现如下图所示,可以看到无论是哪种 backend,都收获了较为显著的性能提升。对于所有 TPC-H 的所有查询,我们仅通过简单的集成,在并没有对  backend 做深度定制的前提下就能普遍获得大于两倍的性能提升,这是非常令人振奋的。

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第5张图片

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会_第6张图片

接下来,我们将围绕以下方面展开 Gluten 社区的工作:

  • 完成在 TPC-DS 数据集上的验证和性能测试工作
  • 完善数据类型和函数的支持工作
  • 完善数据源对接、数据源格式的支持工作
  • 完善 CICD 流程和测试覆盖
  • 尝试 Remote Shuffle Service 的对接工作
  • 尝试其他硬件加速的工作

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号