近日举办的 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 我的项目能够很好地填补行业在这里的空白。
2. Gluten 我的项目是什么？
Gluten 这个单词在拉丁文中有胶水的意思，Gluten 我的项目的作用也正像胶水一样，次要用于“粘合”Apache Spark 和作为 Backend 的 Native Vectorized Engine。Backend 的选项有很多，目前在 Gluten 我的项目中曾经明确开始反对的有 Velox[3]、Clickhouse 和 Apache Arrow。
从这个定位登程，咱们联合下图能够大抵看到 Gluten 我的项目须要提供哪些能力：
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 并不会引入简单的线程模型，具体示意可参考下图：
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 告诉时都会开释内存。
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 社区的工作：
- 实现在 TPC-DS 数据集上的验证和性能测试工作
- 欠缺数据类型和函数的反对工作
- 欠缺数据源对接、数据源格局的反对工作
- 欠缺 CICD 流程和测试笼罩
- 尝试 Remote Shuffle Service 的对接工作
- 尝试其余硬件加速的工作
心愿越来越多的同学们关注 Gluten 社区的停顿，并应用和奉献到这个我的项目，咱们的我的项目地址是：https://github.com/oap-projec…，如果你喜爱这个我的项目，别忘了在 Github 上给咱们点个 🌟
想理解更多对于 Gluten 的信息，欢送大家点击链接 预约 报名加入 7 月 21 日举办的 Data & AI Meetup，咱们将带来对 Gluten 的首发中文解读，更多精彩内容周四见～
对于 Kyligence
上海跬智信息技术有限公司 (Kyligence) 由 Apache Kylin 开创团队于 2016 年开办，致力于打造下一代企业级智能多维数据库，为企业简化数据湖上的多维数据分析（OLAP）。通过 AI 加强的高性能剖析引擎、对立 SQL 服务接口、业务语义层等性能，Kyligence 提供老本最优的多维数据分析能力，撑持企业商务智能（BI）剖析、灵便查问和互联网级数据服务等多类利用场景，助力企业构建更牢靠的指标体系，开释业务自助剖析后劲。
Kyligence 已服务中国、美国、欧洲及亚太的多个银行、证券、保险、制作、批发等行业客户，包含建设银行、浦发银行、招商银行、安全银行、宁波银行、太平洋保险、中国银联、上汽、Costa、UBS、MetLife 等寰球知名企业，并和微软、亚马逊、华为、Tableau 等技术领导者达成寰球合作伙伴关系。目前公司曾经在上海、北京、深圳、厦门、武汉及美国的硅谷、纽约、西雅图等开设分公司或办事机构。