一、Apache Kyuubi 簡介

首先簡單介紹一下 Kyuubi 這個項目。Kyuubi 是一個分布式、多租戶的企業(yè)級大數(shù)據(jù)網(wǎng)關，在基礎設施組件中，Kyuubi 處在接入層的位置。

Kyuubi 提供多種 API 以供不同類型的工作負載接入，典型的使用場景包括：使用 JDBC/BeeLine 以及各種 BI 工具，連接 Kyuubi 進行交互式的數(shù)據(jù)分析；使用 RESTful API向Kyuubi 提交 SQL/Python/Scala/Jar 批作業(yè)。

作為一個企業(yè)級組件，Kyuubi 深度適配了 Hadoop 生態(tài)標準的 Kerberos 安全體系，同時也支持企業(yè)常用的 LDAP 安全認證協(xié)議。特別的，客戶端可以選擇使用 LDAP 認證接入 Kyuubi，無縫橋接到開啟 Kerberos 的 Hadoop 集群，簡化用戶接入成本。

除了作為網(wǎng)關的主體功能外，Kyuubi 項目還包含一系列可以獨立使用的 Spark 插件，比如細粒度權限管理、Hive 表小文件治理、Z-Order、SQL 血緣提取、限制查詢數(shù)據(jù)掃描量等常用功能。

為幫助大家更清晰地了解 Kyuubi，首先回答幾個新接觸 Kyuubi 同學常問的問題。

首先要明確的是，Kyuubi 不是計算引擎，而是一個網(wǎng)關；Kyuubi 與計算引擎處在不同的生態(tài)位，Kyuubi 搭配計算引擎可以構建企業(yè)級解決方案：

• Kyuubi 為不同的計算引擎，如 Spark、Trino，提供統(tǒng)一的接入?yún)f(xié)議、認證方式，簡化了企業(yè)級場景多引擎的接入和管理成本。
• 對于部分計算引擎，比如 Spark、Flink，Kyuubi 可以按需拉起、銷毀計算引擎實例，管理計算引擎的生命周期，實現(xiàn)極致的資源彈性。以 Spark 為例，當客戶端發(fā)起到 Kyuubi Server 到連接后，Kyuubi Server 會首先到服務發(fā)現(xiàn)中心查詢合適的計算引擎，若找不到，會調用 spark-submit 啟動一個計算引擎；啟動后的計算引擎會將自己的連接信息注冊到服務發(fā)現(xiàn)中心，然后 Kyuubi Server 即可通過內(nèi)置 RPC 與計算引擎通信。要注意的是，Kyuubi 目前僅支持 spark-submit 而非 Spark Operator，此項選擇的考慮將會在后文詳述。
• Kyuubi 提供了靈活的路由機制，支持按用戶、組等規(guī)則將查詢路由到指定計算引擎實例，滿足多種場景下的多租戶需求。

另一個很多用戶關心的問題是，Kyuubi 既然支持多種計算引擎，是否也支持 SQL 方言轉換呢？其實 Kyuubi 社區(qū)有很多用戶提過此類需求，經(jīng)過一系列的討論，核心開發(fā)者總體并不期望涉足此方向：一方面由于不同引擎的固有差異，SQL rewrite 不能盡善盡美；另外這是一個相對獨立的方向，我們看到比如由 LinkedIn 開源的 Coral 項目是專注于此領域的項目。因此，Kyuubi 不支持 SQL 方言轉換，但會提供開發(fā)者 API，允許用戶結合其他項目自定義插件去按需改寫 SQL。

目前，Kyuubi 已經(jīng)提供了 Session 級別的插件 API，允許管理員為每個會話注入不同的配置，可以實現(xiàn) HBO 優(yōu)化、將計算引擎路由到不同的集群等功能。在 2025 上半年，我們計劃開放 Query 級別的插件 API，允許管理員為每個查詢注入特定的配置、改寫查詢語句。

二、Kyuubi 支撐多種 Spark 使用場景

Spark 是一個靈活的計算引擎，提供多種 API，針對不同的業(yè)務場景，用戶也有各種各樣的使用姿勢，接下來介紹一下 Kyuubi 作為 Spark 網(wǎng)關，最典型的幾類使用場景。

首先是純 SQL 場景，尤其是用戶已有基于 Hive 的數(shù)倉業(yè)務，期望遷移到 Spark SQL 以降本增效。

Kyuubi 完全兼容 HiveServer2 的 thrift 通信協(xié)議，因此用戶無需調整客戶端，只需簡單修改連接地址即可將 SQL 發(fā)送到 Kyuubi 執(zhí)行；再加上 Spark SQL 高度兼容 Hive 語法，絕大部分 SQL 無需任何改動，少部分 SQL 做微調即可實現(xiàn) Hive 到 Spark SQL 地平滑遷移。

相較于 Spark 內(nèi)置的 Thrift Server，Kyuubi 支持 Spark Cluster 模式，將重度邏輯轉移到引擎端 ，大幅增強了 Server 端的穩(wěn)定性；同時 Kyuubi 提供多種引擎共享級別，如默認的 USER 模式，每個用戶的所有查詢復用一個 Spark App，避免了 ad-hoc 查詢的冷啟動時間。CONNECTION 模式更適合 ETL 調度作業(yè)，每個查詢使用單獨的 Spark App，確保作業(yè)之間不會互相干擾，最大程度提升穩(wěn)定性。

在網(wǎng)易內(nèi)部的某業(yè)務線實踐中，使用 Kyuubi 將 ETL 作業(yè)從Hive 遷移到 Spark SQL，大幅降低了資源使用，同時提升了性能，獲得綜合 7 倍的收益。

第二個 Spark 比較典型的用戶場景是 Notebook。

一些流行的發(fā)行版，比如 CDH，不提供 spark-sql 命令和 ThriftServer 組件。很多企業(yè)的基礎設施團隊，出于可管控、安全的角度，不希望向業(yè)務團隊直接提供 Hadoop 客戶端機器登錄權限，僅通過平臺向用戶暴露提交 SQL / Jar / PySpark 批作業(yè)的接口，也就限制了用戶直接使用 spark-sql、pyspark、sparkR 等原生命令的能力。

在網(wǎng)易內(nèi)部，所有的 Spark 都是托管的，我們和網(wǎng)易云音樂部門合作，基于 Zeppelin 完成了與 Kyuubi 的對接，支持了交互式的 SQL、Scala、PySpark 模式。其中 SQL 功能已經(jīng)推到了 Zeppelin 社區(qū)上游，詳見 ZEPPELIN-6027，我們計劃在 2025 上半年也將 PySpark 和 Scala 的集成推送到開源社區(qū)。

在企業(yè)中，Spark Jar 任務必然是一個繞不過的話題，Kyuubi 借鑒 Livy 的 batch 模式，在近期的版本中也支持了 Jar/Python 任務的 batch 作業(yè)調度。同時得益于 Kyuubi 使用 spark-submit 提交 Spark App，可以輕易地完成 Spark on YARN 到 Spark on K8s 到切換。

在網(wǎng)易內(nèi)部的一個業(yè)務線中，我們使用 Kyuubi 替換掉了原有的 Livy 服務，幫助業(yè)務方實現(xiàn)從單一的 Spark on YARN 到 Spark on YARN/K8s 的混合調度，用更少的硬件支撐了日均十萬級的 Spark 調度作業(yè)。

三、Kyuubi 對接多樣 Spark 部署形態(tài)

無論是網(wǎng)易集團內(nèi)部不同的業(yè)務線，還是網(wǎng)易數(shù)帆作為一個 B 端服務提供商對接的外部客戶，其提供的基礎設施差異總是巨大的，也對 Spark 的部署有不同的要求。比如即使大家都默認將云原生和 Kubernetes 劃等號，各自的 Kubernetes 集群總是在存儲、網(wǎng)絡、調度器等方面存在巨大的差異。Kyuubi 作為一個通用的網(wǎng)關，必須要盡可能適應不同的 Spark 部署形態(tài)，盡量抹除底層的差異，為用戶提供統(tǒng)一的接入方式。

首先一個常見的部署需求是多版本 Spark 共存，比如用戶可能出于兼容性目的，不想升級 Spark 版本；管理員可能希望灰度測試 Spark 新版本。得益于 Kyuubi 的架構設計和完備的兼容性測試，多版本 Spark 支持是非常友好的，具體表現(xiàn)在：

• Kyuubi Server 與 Spark 完全解耦、進程隔離，僅通過拼接 spark-submit 命令提交 Spark App，因此可以通過覆蓋 SPARK_HOME 環(huán)境變量切換 Spark 客戶端，并自動檢測 Spark 客戶端的 Scala 版本，使用正確 Scala 版本的 engine Jar 提交 Spark App。
• Spark Engine 使用反射等技術支持多個 Spark 版本，并且經(jīng)過充分的集成測試確?？绨姹?Spark 的二進制兼容性，使得一套 Kyuubi 集群同時支持多個 Spark 版本。

另一個常見的需求是 Spark on YARN / K8s 的混合部署，相信大部分 Spark on YARN 的用戶往 Spark on K8s 的遷移不是一蹴而就的，會希望有一個平臺可以靈活地控制將 Spark 作業(yè)提交到 YARN 或 K8s，實現(xiàn)漸進式的平滑遷移。

前面提到，Kyuubi 已經(jīng)提供了 Session 級別的插件 API，允許管理員為每個會話注入不同的配置。我們預置了一個基于配置文件的內(nèi)置實現(xiàn)，允許管理員將一組配置預置到一個 profile 配置文件中，用戶只需指定此 profile 即可加載所有配置。如上的例子中，我們預置了兩組配置，分別對應 yarn-hz 集群和 k8s-gy 集群，本質上即是一些 spark 相關的配置，這樣用戶僅需在提交作業(yè)時，指定 kyuubi.session.conf.profile 即可控制將此 Spark 作業(yè)提交到 YARN 或 K8s 集群。

同樣地，借助上述的 profile 特性，我們也可以預置一些比如 gluten、java17 等配置文件，可以灰度地為一些 Spark 作業(yè)啟用 Native Engine、Java 17 等較新的實驗特性，提升 Spark 作業(yè)執(zhí)行效率。

這是一個 Kyuubi 社區(qū)用戶貢獻的案例，他發(fā)現(xiàn)阿里云某個產(chǎn)品提供了一個全托管的 Spark 服務，如果能與 Kyuubi 結合，既可以省去 Spark/YARN/K8s 集群的維護成本，又能享受公有云極致彈性和按量付費的服務。

此托管服務開放的入口有限，僅提供了一個與 spark-submit 兼容的命令行工具，通過解壓也不難看出，這應該僅是對 API 的一個封裝，并非真正的 spark-submit。得益于 Kyuubi 使用 spark-submit 提交 Spark App，該用戶輕易地就完成了對接，實現(xiàn)了公有云上按需付費的 Spark SQL 服務。

四、Kyuubi 在 Spark 4 時代的基于與挑戰(zhàn)

Spark 4 正在如火如荼的開發(fā)中，Spark 4.0 預計將于 2025 年上半年發(fā)布，帶來一系列的新特性，其中一項重磅特性即宣布 Spark Connect GA。

Spark Connect 是由 Databricks 主導開發(fā)的一項新特性，其全新的架構可能會改變未來 Spark 主流的使用方式。

Kyuubi 項目流行的一個重要因素是兼容 HiveServer2 通信協(xié)議，兼容 Hive 生態(tài)。Spark 4 提出了自己的 Connect 協(xié)議，我們也希望 Kyuubi 未來能兼容 Connect 協(xié)議，再次乘得 Spark 生態(tài)的東風。

簡單而言，Spark Connect 是希望將所有以 DataFrame 為主的 Spark Public API 由方法調用變成 gRPC 遠程調用的方式，將客戶端與服務端分離，類似于將 Hive 遷移到 BeeLine 和 HiveServer2 的過程。

理想情況下，Spark Connect 可以將 Spark Jar / PySpark 任務也支持服務化，這會進一步簡化 Spark 的上手成本，比如大幅簡化 PySpark 用戶配置本地環(huán)境和安裝依賴步驟，用戶只需安裝一個 1MiB 多的客戶端，直接連接遠程的 Connect Server 即可運行 Spark 作業(yè)。

在具體實現(xiàn)細節(jié)上，Connect Server 與 Thrift Server 有很多異同之處，如果大家對 Thrift Server 有了解，通過對比可以快速了解 Connect Server。

首先兩者的通信協(xié)議不同，Connect Server 選擇了 gRPC 而非 Thrift，基于 gRPC 目前的生態(tài)，我相信這也是當下最正確的選擇；在 API 數(shù)量上，Thrift 僅需考慮 SQL 場景，而 Connect 覆蓋 DataFrame 幾乎所有 API，API 和數(shù)據(jù)結構數(shù)量上 Connect 要遠多與 Thrift；兩者架構無本質卻別，都是單點的 RPC Server，也僅支持 Client 模式。

Kyuubi 兼容 Thrift Server 的API，但架構創(chuàng)新取得了成功，這是否意味著 Kyuubi 的架構也能適用于 Connect Server，再次取得成功？

對此我們持樂觀態(tài)度，并且已經(jīng)實現(xiàn)了一個 PoC 版本，驗證了此想法的可行性，歡迎有興趣的同學到 GitHub 進一步交流。

五、Q&A

Q1：Kyuubi Server 服務如果崩潰，正在執(zhí)行的 SQL 會失敗嗎？

A1：如果使用 THRIFT_BINARY 協(xié)議，即基于 TCP 長鏈接，socket 斷開后會自動關閉會話并 cancel 所有正在執(zhí)行的 SQL，可以通過配置 kyuubi.session.close.on.discnotallow=true 來改變此行為；如果使用 RESTful Batch API 提交的作業(yè)，則不會受到影響。

Q2：Spark on K8s 場景下，Kyuubi Server 可以部署在 K8s 外部嗎？如果可以，Kyuubi Server 如何與 Spark Driver 通信呢？

A2：可以，只要外部網(wǎng)絡與 K8s 內(nèi)部網(wǎng)絡互通即可。一般情況下，我們使用 Cluster 模式運行 Spark on K8s，Kyuubi Engine（即 Spark App）啟動后，會將 Spark Driver Pod 的 IP 注冊到 Zookeeper 或 ETCD 以供 Kyuubi Server 發(fā)現(xiàn)和連接。默認情況下，K8s 的 Service 和 Pod 運行在與宿主機不同的網(wǎng)段中，其具體實現(xiàn)取決于管理員安裝的 CNI 插件， 常用的網(wǎng)絡插件如 Calico 可以使用 BGP 協(xié)議將 K8s 網(wǎng)絡平面與宿主機網(wǎng)絡聯(lián)通，即可正常通信；在實踐中，我們也看到一些用戶通過使用 Host 網(wǎng)絡模式運行 Spark on K8s，直接規(guī)避了不同網(wǎng)絡平面的通信的問題。這也印證了前面提及的觀點：雖然大家都在向云原生靠攏，但對云原生有不同的理解，Spark 云原生部署依然面臨著巨大的基礎設施差異。