“Kyligence 企業級產品源自 Apache Kylin，今天，兩者在離線資料處理、即時查詢分析等方面，都深度整合了 Spark 的能力。透過 Gluten 這一開源專案，Kylin 和 Kyligence 企業級產品將有效提升 OLAP 查詢效能和執行效率，尤其是在雲原生版本 Kyligence Cloud 中，將更大程度地降低整體擁有成本（TCO），提高雲端資料分析的成本效率，加速大型客戶從傳統資料分析架構轉向雲原生資料湖架構的程式。”——Kyligence 聯合創始人兼 CTO 李揚
近日舉辦的 Databricks Data & AI Summit 2022 上，來自 Intel 的陳韋廷和來自 Kyligence 的張智超共同分享了 Intel 和 Kyligence 兩家企業自 2021 年合作共建的全新開源專案「Gluten」。這也是 Gluten 首次在全球平臺上亮相，今天我們將一起透過本文進一步瞭解 Gluten。
Gluten 專案旨在為 Apache Spark 注入 Native Vectorized Execution 的能力，極大最佳化 Spark 的執行效率和成本。目前，Gluten 社群的主要參與方有 Intel、Kyligence 等。
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”，文章詳細描述了 Databricks 如何在 Apache Spark 中整合 Photon 這一 Native 子系統，透過向量化執行等方面的最佳化，為 Apache Spark 帶來執行效能的大幅提升。Gluten 專案在 Photon 公開前就已獨立地立項和啟動，不過我們看到在實現思路和加速效果上兩者具有一定的相似性。
下圖來自 Databricks 公開的演講材料，從圖中可以看出引入 Native Vectorized 引擎（Photon）的效能收益，勝過過去 5 年來所有效能最佳化的總和。而效能的提升又可以帶來 Spark 使用體驗的提升和 IT 成本的下降，這一點在企業使用者動輒使用成百上千臺伺服器用來執行 Spark 作業的今天，是非常誘人的進步。目前 Photon 並不開源，因此 Gluten 專案可以很好地填補行業在這裡的空白。
2、Gluten 專案是什麼？
Gluten 這個單詞在拉丁文中有膠水的意思，Gluten 專案的作用也正像膠水一樣，主要用於“粘合” Apache Spark 和作為 Backend 的 Native Vectorized Engine。Backend 的選項有很多，目前在 Gluten 專案中已經明確開始支援的有 Velox、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 的開源專案，其使用 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 Shuffle
Shuffle 本身就是影響效能的重要一環，由於 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...
想了解更多關於 Gluten 的資訊，可關注 7 月 21 日舉辦的 Data & AI Meetup。
關於 Kyligence
上海跬智資訊科技有限公司 (Kyligence) 由 Apache Kylin 創始團隊於 2016 年創辦，致力於打造下一代企業級智慧多維資料庫，為企業簡化資料湖上的多維資料分析（OLAP）。透過 AI 增強的高效能分析引擎、統一 SQL 服務介面、業務語義層等功能，Kyligence 提供成本最優的多維資料分析能力，支撐企業商務智慧（BI）分析、靈活查詢和網際網路級資料服務等多類應用場景，助力企業構建更可靠的指標體系，釋放業務自助分析潛力。
Kyligence 已服務中國、美國、歐洲及亞太的多個銀行、證券、保險、製造、零售等行業客戶，包括建設銀行、浦發銀行、招商銀行、平安銀行、寧波銀行、太平洋保險、中國銀聯、上汽、Costa、UBS、MetLife 等全球知名企業，並和微軟、亞馬遜、華為、Tableau 等技術領導者達成全球合作伙伴關係。目前公司已經在上海、北京、深圳、廈門、武漢及美國的矽谷、紐約、西雅圖等開設分公司或辦事機構。