導讀：Kyuubi 社群于早前釋出了 1.5.0-incubating 版本，帶來了重大特性更新。本文由來自網易數帆的軟體工程師、Apache Kyuubi (Incubating) PPMC 成員潘成結合 Kyuubi 的架構設計，為大家帶來該版本的特性解讀。
全文主要内容包括：架構設計、引擎擴充、功能增強、未來可期。
--
01
架構設計
1. 計算引擎服務化演進
早期的計算引擎使用方式多以“胖用戶端”模式為主，其中比較典型的有 Hive、Spark-sql，其特點是在用戶端節點直接啟動一個較重的主要節點（如Spark Driver），該元件将承擔 SQL 編譯、資源申請、Task 配置設定等職責，主節點會随着任務的結束而自動退出。
“胖用戶端”模式具備極佳的隔離性，若單個任務導緻的主節點崩潰，如查詢大結果集導緻 Spark Driver OOM，不會影響其他的任務的正常運作。同時，與強隔離性對應的是低資源使用率，多任務并發執行時，每一個任務啟動一個計算引擎主要節點對用戶端機器有非常高的要求，如一個典型的 Spark Driver 需要記憶體 2~8GB；如果任務本身較小，如 DDL 語句，計算引擎的冷啟動時間也将不可忽略，如一個 Yarn Application 典型的啟動時間為 15s~3min。
随着計算引擎的發展，逐漸向“瘦用戶端”模式演進，其中比較典型的有 HiveServer2、Spark Thrift Server。“瘦用戶端”采用集中式的服務化管理模式，在計算引擎主要節點上暴露一個 API，使用者隻需使用“瘦用戶端”将 SQL 送出給計算引擎服務并等待任務結束取回結果即可。“瘦用戶端”采用資源共享的模式，大幅提升了資源使用率；避免了冷啟動開銷，提升了查詢響應速度；集中式的管控模式，降低了計算引擎管理和疊代的成本。同時，共享的服務使得穩定性大幅降低，一個任務導緻服務崩潰會導緻所有任務失敗，比如 UDF 資源洩露、大結果集導緻的服務 OOM 将影響大量任務；為了提升穩定性，又引入了高可用機制，通過叢集部署實作多節點的 HA 降低單個計算引擎服務故障的影響。
整體來看，縱使“瘦用戶端”模式相較“胖用戶端”模式有一定的劣勢，“瘦用戶端”模式仍是計算引擎服務化的一個重大進步，但還有巨大的改進空間。
仔細分析，前面提到的所有不穩定因素，其實是“計算引擎主要節點”不穩定，在“瘦用戶端”模式的基礎之上，如果将 API 服務與計算引擎程序分離，然後兩者通過 RPC 通信，即可大幅提升 API 服務的穩定性。
程序分離後，API 服務程序對資源的要求大幅降低，因為兩者使用 RPC 通信，計算引擎節點也不必局限于必須啟動在相同的節點，可以直接啟動在 YARN/K8s 等資源管理系統中，進而降低對 API 服務節點的伺服器資源需求。
程序分離也意味着 classpath 的隔離，API 服務無需與特定版本的計算引擎強綁定，可以同時支援多種計算引擎（如 Spark、Flink）和多個版本的計算引擎（如 Spark 3.1、Spark 3.2）。
更近一步，計算引擎的生命周期可以由 API 服務程序管控，當接到連接配接請求時，若有可用的計算引擎直接連接配接，否則延遲啟動計算引擎；等計算引擎閑置一段時間後，自動停止釋放資源。
2. Kyuubi 高可用彈性架構
在 API 服務與計算引擎程序分離的基礎之上，通過定義計算引擎路由規則，即可在隔離性和資源共享之間靈活取舍，滿足不同場景的需求。
比如在 ad-hoc 場景中，使用者期望自己的查詢能直接複用計算引擎，加速響應，但并不期望自己的查詢影響到他人，該場景下，可以定義路由政策，将相同使用者的查詢路由到相同的計算引擎，既提升了查詢響應速度、節約了資源，又保證了使用者粒度的隔離性；在離線排程場景中，使用者期望任務之間互不幹擾，可以為每個查詢都路由到單獨的計算引擎，實作強隔離性。
以上即是 Kyuubi 的基本架構設計。在具體實作上，為了相容現有 Hive、Spark 生态，Kyuubi API 服務直接相容了 Hive Thrift 協定，并且也基于 Zookeeper 實作了與 Hive Thrift 相容的 HA 協定，是以所有 Hive Client，包括 Beeline、Hive JDBC driver、pyhive 等，可以無需修改直接連接配接 Kyuubi Server。除此之外，Kyuubi Server 還提供 MySQL、RESTful API。
在計算引擎路由規則的實作上，Kyuubi 使用 Zookeeper 路徑定義路由規則，引入了引擎共享級别（engine share level）的概念，并提供了 USER、CONNECTION、SERVER、GROUP 等預設，可以滿足多種典型場景的需求。在社群實踐中，也有對 Kyuubi 改造，基于 K8s label、Etcd 實作引擎路由規則的案例。
在計算引擎的支援上，Kyuubi 提供了非常成熟的 Spark 支援，同時正在引入 Flink、Trino、Hive 等引擎的支援。
--
02
引擎擴充
1. Spark 引擎
Kyuubi 對 Spark 的引擎是非常成熟的，在業界有衆多大規模生産環境落地案例。在各種部署模式下都支援對 Spark 元件進行完整的生命周期管控。
Kyuubi 相容 Spark 3.0+ 的所有版本，并相容所有的部署模式。
從 Spark 3.1 版本起，Kyuubi 提供了一些列企業級擴充插件，如增強了 AQE，提供自動小檔案合并功能；支援限制查詢的最大分區掃描數量，限制查詢結果大小；支援開箱即用的 Z-Order 優化，支援計算、寫入 Stage 的配置隔離；同時 Kyuubi 社群正在開發 Spark 權限、血緣插件，以及更多的企業級功能。
2. Flink 引擎
得益于 Kyuubi 的多引擎架構，社群在 1.5 版本中新增了 Flink 引擎的支援，目前适配了 Flink 1.14 版本。
在開發過程中，我們意識到了 Flink 與 Spark 在架構設計上整體上比較相似，但又有很多不同。其中與 Kyuubi 內建工作相關的主要的不同點有：
- Spark Local、Yarn、K8s 等部署模式下，可以直接将任務送出到資源管理系統，而 Flink Local，Flink Session 模式需要先預先啟動 Flink Cluster，然後再将 Flink 任務送出到 Flink Cluster；在上述模式下，Flink Cluster 的聲明周期不受 Kyuubi 管控。PerJob、Application 模式則無需預先啟動 Flink Cluster，這些模式下，Kyuubi 支援對 Flink 應用的所有元件生命周期管控。
- Spark Driver 負責 SQL/DataFrame 作業編譯、執行，同時是可程式設計的，我們可以直接在 Driver 中啟動 Kyuubi RPC endpoint 與 Kyuubi Server 通信；Flink 中類似的角色是 Job Manager，但與 Spark Driver 不同的是，在除了 Application 模式下，Job Manager 隻負責作業執行，是不可程式設計的，SQL/Table 作業編譯需在送出節點完成，是以我們隻能将 Kyuubi RPC endpoint 啟動在送出程序内，整體上不夠優雅。Flink 最新引入的 Application 模式，将原本在送出節點的工作，轉移到了 Job Manager，整體架構上類似于 Spark Cluster 模式，與 Kyuubi 的架構更加契合。
總體來看，Kyuubi 1.5 在 Flink 支援上邁出了重要的一步。感謝來自 T3 出行和阿裡雲同學的不斷探索，使得我們認識到 Flink 與 Spark 引擎的異同，并找到了 Kyuubi 與 Flink 最佳的內建方式，為未來的內建工作指明了方向。
3. Trino 和 Hive 引擎
來自江蘇移動的開發者還為 Kyuubi 貢獻了 Trino 引擎的支援，并且在内部有生産落地驗證。在 Trino 引擎的內建上，Kyuubi 将 Trino 叢集看成常駐服務，僅能管控 Trino Client 節點，整體上來說管控能力較弱。
同時社群正在計劃支援 Hive 引擎，期望能達到動态拉起、釋放 HiveServer2 的效果。或許還可以更進一步，直接将 Hive engine 在 YARN 上排程，讓 Hive 煥發新的活力！
--
03
功能增強
前文提到了 Kyuubi 内置多種路由政策（引擎共享級别），可以适應不同的場景，在隔離性個資源率上取得平衡。目前，Kyuubi 支援 4 種引擎共享級别，并且附帶 POOL 模式，可以與其他 4 種引擎共享級别組合使用。
具體包括（假設使用者隻使用單個計算引擎，如隻使用 Spark SQL）：
- CONNECTION：每個連接配接都會啟動一個新的引擎，連接配接斷開立即釋放。
- USER（預設）：将同一個使用者的請求路由到同一個引擎。當所有連接配接斷開後，引擎進入閑置（idle）狀态，閑置一段時間後，引擎退出。
- SERVER：所有的連接配接共享一個引擎；同 USER 模式一樣，有閑置釋放政策。
- GROUP（1.5新增）：相同組（Hadoop Group）的使用者使用共享一個引擎；同 USER 模式一樣，有閑置釋放政策。
上述的引擎共享級别滿足了大部分場景，在 Kyuubi 1.5 中，我們還引入了 POOL 模式可以和上述引擎共享級别組合使用，如 POOL 與 USER 共享級别組合使用，一個 USER 可以對應一組計算引擎。該模式比較典型的應用場景是複雜報表計算，當頁面定時重新整理是，可能瞬間有大量的圖表并發重新整理，通過增加 POOL 大小可以線性提升并行度。
在具體實作上，Kyuubi 使用 Zookeeper 路徑實作引擎的路由規則。路徑中包含了 share_level、user_name、pool 等要素，具體規則如圖所示，可以結合案例了解。
當用戶端接入時，Kyuubi 會按照規則從 Zookeeper 指定路徑上查找合适的引擎連接配接資訊，若找不到，則建立一個新的引擎并等待，新的引擎初始化完成後，會将自身的連接配接資訊注冊到 Zookeeper 上，供 Kyuubi 連接配接。
在第二個案例中，我們可以看到，使用 CONNECTION 共享級别時，路徑中包含了 UUID，是以每個新的連接配接請求在查找路由時，都不會命中已有的引擎，而是建立并等待新的引擎注冊。
我們看一下 POOL 的實作原理，以及更多靈活的使用方式。
在 Zookeeper 路徑中，有一個 Subdomain 變量，可以通過 kyuubi.engine.share.level.subdomain 進行配置，預設為 default。在 Kyuubi 的配置體系中，允許 client 在連接配接時提供一些自定義參數，優先級比在 kyuubi-defaults.conf 裡定義的更高。是以在上述引擎共享級别的基礎上，通過攜帶 subdomain 配置參數，還可以進一步更細粒度的控制引擎的路由。
如圖中的案例，我們期望在 GROUP 模式下，提供兩個 Engine Pool，分别為 normal-pool，size=3 和 sla-pool，size=3。
POOL 模式的實作即利用了 Subdomain 機制。首先在 kyuubi-defaults.conf 中增加配置：
- kyuubi.engine.share.level=GROUP
- kyuubi.engine.pool.name=normal-pool
- kyuubi.engine.pool.size=3
假設使用者 A、B、C、D 同屬于 ads 組：
- 當使用者 A 不攜帶任何參數接入時，會被随機路由到 subdomain 為 normal-pool-[1~3] 的引擎上。
- 當使用者 B 指定 pool_name=sla-pool時，會被随機路由到 subdomain 為 sla-pool-[1~3] 的引擎上。
- 當使用者 C 指定 pool_name=sla-pool 并且 pool_size=2 時，會被随機路由到 subdomain 為 sla-pool-[1~2] 的引擎上。
- 當使用者 D 指定 subdomain=sla-pool-3 時，則會被精确路由到 subdomain 為 sla-pool-3 的引擎上。
這就是 Kyuubi 路由規則背後的實作，在摸清了原理之後，還可以有更多的玩兒法，比如将 subdomain 設定為 queue name，即可實作在内置引擎共享級别的基礎之上，按隊列隔離引擎。
Kyuubi 1.5 中在 Spark SQL 的支援之上，引入了 Spark Scala 的支援，該模式可以看做是一個服務化的 Spark Shell，可以使用 JDBC、Beeline、PyHive 直接接入，并在 SQL、Scala 模式間自由轉換。
SQL + Scala 混編模式的支援，使得 Kyuubi 可以覆寫更多的場景，降低使用者的使用成本。
--
04
未來可期
自 2021 年 6 月加入 Apache 孵化器以來，Kyuubi 社群發展迅速，已經釋出了 3 個特性版本。随着社群發展和多方的參與，我們的定位也在悄然發生轉變，Kyuubi 的願景從最初的 Serveless Spark 轉變到 Serverless SQL on Lakehouse。
Kyuubi 項目開發者社群持續活躍，目前已經累計有71位開發者操作1800次的代碼送出，現有 9 位 PPMC 成員和 4 位 committer，進入孵化器發版節奏穩定，保持每 1~ 3 的發版頻率。
最後，我們要感謝 Kyuubi 社群的使用者，他們為 Kyuubi 貢獻了大量的回報和實踐案例。
今天的分享就到這裡，謝謝大家。
分享主題：Apache Kyuubi (incubating) v1.5.0 特性解讀
分享嘉賓：潘成 網易數帆 軟體工程師
出品平台：DataFunSummit
01/分享嘉賓
潘成｜網易數帆 軟體工程師/Apache Kyuubi(Incubating) PPMC
潘成，網易數帆軟體工程師，Apache Kyuubi (Incubating) PPMC，開源軟體愛好者。長期活躍于開源社群，Spark ClickHouse Connector 作者。
02/關于我們
DataFun：專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章800+，百萬+閱讀，15萬+精準粉絲。