一、Apache Kyuubi 簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一些流行的發(fā)行版，比如 CDH，不提供 spark-sql 命令和 ThriftServer 組件。很多企業(yè)的基礎(chǔ)設(shè)施團(tuán)隊(duì)，出于可管控、安全的角度，不希望向業(yè)務(wù)團(tuán)隊(duì)直接提供 Hadoop 客戶端機(jī)器登錄權(quán)限，僅通過平臺(tái)向用戶暴露提交 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，我們計(jì)劃在 2025 上半年也將 PySpark 和 Scala 的集成推送到開源社區(qū)。

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

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

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

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

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

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

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

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

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

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

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

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

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

Spark Connect 是由 Databricks 主導(dǎo)開發(fā)的一項(xiàng)新特性，其全新的架構(gòu)可能會(huì)改變未來 Spark 主流的使用方式。

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

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

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

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

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

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

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

五、Q&A

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

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

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

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