導讀 本文將對 Apache Kyuubi 1.6.0 版本特性進行解讀。
主要包括以下四個部分：
1. 服務端增強
2. 客戶端增強
3. 引擎外掛
4. 社群展望
分享嘉賓｜蔣曉峰 Bilibili 資深開發工程師
編輯整理｜張建闖
出品社群｜DataFun
01
1. 支援批（JAR）任務提交
Apache Kyuubi 是網易數帆開源的一款企業級的資料湖探索平臺，也是一款分散式和多租戶閘道器，為資料湖查詢例如 Spark、Flink 或者 trino 等提供 SQL 查詢服務。Kyuubi 支援多租戶、高可用以及多工作負載等功能特性，可以滿足企業內部諸如 ETL、BI 報表、互動式分析以及批資料處理等多種大資料場景的應用。首先介紹一下 Apache Kyuubi 1.6.0 針對服務端增強引入了一些新特性。
Kyuubi 1.6.0 支援批（JAR）任務提交。Kyuubi 本身支援 SQL，但是很多公司不僅有 SQL 任務，還有 JAR 任務，在這裡稱之為 Batch 任務，這時 Kyuubi 已有的功能就無法滿足 ETL 需求。在 Kyuubi 1.6.0 版本中提供了一個透過 Restful API 形式提交 Batch 任務，實現 Kyuubi Batch 的功能。Kyuubi Batch 功能的實現設計如圖所示，使用者首先需要透過 POST 方式向 Kyuubi Server 傳送一個 Create Batch 的請求，Kyuubi Server 接收到請求後，會立即返回 BatchId，Kyuubi Server 會使用這個 BatchId 作為一個 tag 傳入 Spark 中，加入到 Spark submit 的 conf 中。這裡是使用 Yarn 作為 resource manager，所以這裡會把這個 tag 傳到 Yarn context 中，這樣 BatchId 同時會和 Kyuubi Server 以及 Yarn 都進行一次繫結。最後能夠透過這個 BatchId 去訪問 Kyuubi Server 獲取 Batch Report，Kyuubi Server 也能夠透過 BatchId 去訪問 Yarn 獲取 application report。同時 Kyuubi Server 也可以去合併 Kyuubi Server 端的一些資訊，比如 Batch 任務的建立時間，建立的節點，這些資訊可以返回給使用者，使用者也能夠透過這個 BatchId 去獲取 Spark submit 的日誌，能夠清楚知道 Spark submit 執行到了哪些階段，以及 Kyuubi Server 端發生了什麼，如果出現異常，也能夠清楚的找到異常資訊。對於使用者來說，還可以透過 DELETE 方式關閉目前正在執行的 Batch 任務，如果 Batch 任務沒有提交到 Yarn 叢集，Kyuubi Server 需要 kill 掉本地的 spark submit 程式，如果已經提交到yarn叢集，對於 Kyuubi Server 來說需要透過 BatchId kill 掉正在執行的 Batch 任務，並返回給使用者這個 close 的結果。在示意圖左半部分的 4 個 API，是針對 Kyuubi 單個節點的，比如拉取 local job，kill 本地程式，都是需要在Kyuubi程式啟動節點處理的。一般在生產環境為了實現 HA 和 SLB，需要部署多臺 Kyuubi 節點，為了實現多個節點的 HA，我們在這個功能特性裡面引入了 Metadata Store，以及 Kyuubi 內部節點的請求的轉發機制。Metadata Store 是用來儲存一些 Batch 任務的後設資料，比如 BatchId，建立 Batch 任務的 conf 和引數，還有 Kyuubi 節點的一些資訊，比如哪個節點建立的 Batch，都會加入到這個後設資料中。有了 Metadata Store 之後，Batch 後設資料會對多個 Kyuubi 節點都可見，包括目前的狀態，以及哪個節點建立的 Batch。關於 Kyuubi Server 之間的 rest 請求轉發，我們可以在這裡舉一個簡單的例子，比如採用 K8S 的 loadbalance 作為 Kyuubi Server 的服務發現，每個 rest 請求都會從這個 loadbalance 中去隨機選擇一個 Kyuubi 節點來處理，比如在處理 Kyuubi Batch 的時候，是在 Kyuubi 節點 1 建立的，當使用者需要拉取 local job 的時候，會向 loadbalance 節點傳送請求，load balance 會選擇 Kyuubi 節點 2 來處理這個請求，這個時候 Kyuubi 節點 2 會首先在記憶體中尋找這個 Batch 任務，如果沒有找到，就會去訪問 Metadata Store，去查詢這個任務的後設資料資訊。此時發現任務是由 Kyuubi 節點 1 建立的，就會把拉取日誌的請求傳送給 Kyuubi 節點 1，由 Kyuubi 節點 1 拉取本地日誌，返回給 Kyuubi 節點 2，Kyuubi 節點 2 這個時候就會把這個結果返回給使用者。這樣使用者就可以成功的透過 Kyuubi 節點 2 獲取到 Spark submit 的日誌。透過 Metadata Store 和節點內部轉發，實現了多節點的 HA，換句話來說，使用者是透過 load balance 連線到任意節點，都可以拿到 Batch 的資訊。透過運用 Metadata Store 和 Kyuubi Server，也可以在服務重啟的時候，做到恢復重啟前在執行的 Batch 任務。如果這個 Batch 任務沒有提交到 Yarn 叢集，Kyuubi Server 會透過 Metadata Store 裡面的元資訊進行重新提交，如果已經提交給 Yarn 叢集，Kyuubi Server 會監控執行的 Batch 任務的狀態。在 Kyuubi1.6.0 版本中，對 Metadata Store 做了一些增強，當 Metadata Store 有問題，比如 MySQL 短時間不可用，這個時候會把更新 Metadata Store 的一些請求儲存在記憶體中，進行非同步的重試，而不是打斷使用者的主執行緒。同時當 Metadata Store 不可用的時候，對於 Batch 任務的狀態請求會 fallback 到 Yarn 上獲取任務的狀態，對這個狀態進行一些補充，然後 Kyuubi Server 會返回給使用者。同時在 1.6.0 版本中，Kyuubi 提供了 restful 的 CLI 和 SDK，可以讓使用者很方便的使用其提供的服務，而不需要使用 curl 命令或者一些很原始的 rest API，直接使用 CLI 對使用者來說更加友好，restful SDK 可以讓平臺層的使用者使用程式設計的方式進行整合。同時擁有這種中心化提交 Batch 任務的服務，可以方便的去監管 Spark submit 的行為，比如做一些提交許可權的校驗，拒絕不合理的 JAR 提交，來提高整個叢集的安全性。
剛才也提到了，Kyuubi1.6.0 提供了 restful SDK 和 Command Line 來給使用者使用。restful 的 SDK 對於一些平臺團隊來說，透過程式設計的方式很容易整合。這裡主要介紹命令列工具的使用，上圖右側展示了命令列的使用，類似於 K8S 的 ctl。命令結構為 kyuubi-ctl + action 命令 + batch + yml 檔案。其中 action 包括 create、get、logs、delete，分別對應前文提到的 4 個 API，還有一個複合命令 Submit，包含了其它 4 個 action。配置檔案中指定了 JAR 的位置，Batch 型別，目前已經支援了 Spark，正在支援 Flink，還有提交 JAR 的主程式和它的引數以及配置。這樣對於使用者來說非常便捷，只需一行命令就能完成任務的提交，不需要配置很多 Spark 的本地環境，這裡會使用最新的 Spark 版本，減少了使用者的維護成本。
在 Kyuubi1.6.0 版本中，統一了 API 介面和認證機制。到 Kyuubi1.6.0 為止提供了 Thrift，Rest、JDBC 和 ODBC 的 API，提供了 Kerberos 和 Password 的認證機制，在之前的版本中，對於 Thrift 協議來說，只支援一種認證機制，在 1.6.0 版本中，兩種認證機制都支援了。對於 rest 請求 1.6.0 之前是不支援認證的，在 1.6.0 版本中，這兩種認證機制也都做了支援。有了統一的 API 和認證機制，1.6.0 基本上覆蓋了使用者所有的使用方式。剛剛介紹的是 1.6.0 服務端的增強，在這個版本中對客戶端也做了增強。② 支援使用 keytab 進行 Kerberos 身份認證。
1.6.0 版本增強了 Beeline，在 Beeline 中可以顯示 Spark 控制檯的進度條，如圖所示，可以清楚地看到 Spark 每個 Stage 的執行情況和總體執行情況。在計算引擎方面，Kyuubi1.6.0 提供了非常成熟穩定的 Spark 支援，同時 Flink、trino 以及 Hive 等計算引擎的支援也得到了充分的驗證。
我們首先來看 Spark 引擎。Kyuubi 作為 Spark 的引擎，支援的已經是非常成熟了，有一套完善的生命週期管控，也經過了很多公司的大規模生產驗證，在業界有眾多的生產環境的落地案例。對於版本支援這塊，Kyuubi Spark Engine 支援了 3.0 到 3.3 的所有版本，對於這些版本也都進行了充分的驗證。在 Spark 引擎中相容了所有的部署模式，比如 Spark on Local/Standalone 或者 Spark on Yarn/K8S，不論是 Client 還是 Cluster mode 都是支援的。Kyuubi Spark Engine 從 Spark3.1 版本開始就提供了一個企業級外掛，比如自動小檔案合併，限制掃描的最大分割槽數，以及限制查詢結果大小，並提供了一個開箱即用的 Z-Order 最佳化來支援計算寫入 Stage 的配置隔離。同時在 1.6.0 中，又新增了 Spark TPC-DS 和 TPC-H 聯結器，以及 Authz 認證的外掛。Kyuubi 社群依然還在陸續開發一些比如像血緣外掛等企業級的功能。
再來看一下 Flink Engine，在 Kyuubi1.6.0 中基本成熟穩定了，並且 Kyuubi 的 Flink Engine 是對所有社群開發者和使用者去關注的，也在不斷的迭代演進中，在 1.6.0 版本中，Flink Engine 支援了 Flink1.14、1.15 版本，1.16 還沒有釋出，社群這邊已經在逐步支援。對於部署模式而言，Flink Engine 支援 on Local、on Yarn(PerJob and Session mode)，關於 on Yarn/K8S Application mode 會在 1.7.0 版本進行釋出，因為 Application mode 非常契合 Kyuubi 的部署模式，目前是在開發階段。3. Kyuubi Trino Engine， Kyuubi Hive/JDBC Engine
Trino Engine 是一個生產可用，經過移動雲等社群使用者的生產驗證狀態。Hive 和 JDBC Engine 提供了一個 Beta 版本，歡迎大家使用反饋，以及生產驗證。社群展望
最後和大家分享一下 Kyuubi 社群的未來展望。
從 2021 年開始加入到 Apache 孵化器之後，Kyuubi 社群一直在發展迭代，到目前為止一共釋出了 4 個大特性版本。隨著社群的發展和社群開發者的參與，Kyuubi 的基礎定位也在發生改變，Kyuubi 的願景從最初的 Serverless Spark 轉變成了現在的 Serverless SQL on Lakehouse。到了 1.6.0 版本，大部分的之前計劃的 roadmap 已經全部實現。後面 Kyuubi 社群還會提供更多的企業級特性。
Apache Kyuubi 社群的發展離不開社群的使用者，有很多企業來使用，為 Kyuubi 貢獻了大量的使用反饋和實踐案例。如果你也在使用 Kyuubi，或者有一些 Kyuubi 的實踐案例，可以在上圖下方連結進行登記。
最後我們來看一下 Kyuubi 社群目前的進展，Apache Kyuubi 社群目前有 12 位 PPMC，以及 17 位 Committer，有 96+ 的 Contributor，dev 的訂閱者已經超過 65 位，Kyuubi 社群最近兩年舉辦了 4 次社群Meetup，參加了 20+ 項活動，比如 ApacheCon 等。對於 Kyuubi 專案本身來說，已經發布了 8 個版本，每個版本由不同的 Release Manager 釋出，1400+PR 被 Merge，900+Issue 被解決。
Apache Kyuubi 其實是一個 Apache 的孵化專案，截止到目前已經經過了孵化畢業的討論，討論已經透過，目前是處於孵化畢業投票的階段，對 Kyuubi 有興趣或正在使用 Kyuubi 的同學歡迎進入投票。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024923/viewspace-2939340/，如需轉載，請註明出處，否則將追究法律責任。