本文PPT，在微信公眾號(hào)「DataFunSummit」，回復(fù)「20220423」領(lǐng)取

導(dǎo)讀：今天分享的主題是《Kyuubi 在小米大數(shù)據(jù)平臺(tái)的應(yīng)用實(shí)踐》，主要分為四部分內(nèi)容：

• Kyuubi 在小米的落地過(guò)程
• 打造易用和高可用的 Kyuubi 服務(wù)
• 基于 kyuubi 的改進(jìn)
• kyuubi的一些新特性在業(yè)務(wù)場(chǎng)景的應(yīng)用

01

Kyuubi 在小米的落地過(guò)程

第一個(gè)主題：關(guān)于Kyuubi在小米的大數(shù)據(jù)平臺(tái)落地過(guò)程和實(shí)施路徑的分享。

1. 背景介紹

先介紹一下背景，小米的大數(shù)據(jù)體系在不斷更新和迭代，隨著業(yè)務(wù)架構(gòu)、組織架構(gòu)和技術(shù)架構(gòu)的調(diào)整，內(nèi)部大數(shù)據(jù)平臺(tái)逐漸出現(xiàn)一些狀況：

• 出現(xiàn)了多個(gè)基于SQL的大數(shù)據(jù)平臺(tái)服務(wù)，服務(wù)于各個(gè)業(yè)務(wù)部門，各自定位又有一定的差異，這樣就給用戶帶來(lái)了困擾，到底選擇哪個(gè)平臺(tái)好，而且我們?cè)谟脩糁С值倪^(guò)程中發(fā)現(xiàn)，同一業(yè)務(wù)可能需要跨多個(gè)數(shù)據(jù)服務(wù)平臺(tái)，流程繁瑣。
• 對(duì)于底層表資源的使用存在多套賬號(hào)和權(quán)限體系：

a. MySQL/Doris: 系統(tǒng)的自有的 User&Password 認(rèn)證和權(quán)限體系

b. Hive/Kudu基于 Kerberos 認(rèn)證和 Sentry 的權(quán)限體系

c. Talos是基于小米內(nèi)部平臺(tái)組織和團(tuán)隊(duì)的認(rèn)證與授權(quán)體系

• 給用戶使用和管理上帶來(lái)了麻煩，沒(méi)有統(tǒng)一的資源管理和權(quán)限管理視角，并且底層系統(tǒng)服務(wù)賬號(hào)會(huì)直接暴露給用戶，還會(huì)存在安全風(fēng)險(xiǎn)。

2. 構(gòu)建一站式的大數(shù)據(jù)開發(fā)平臺(tái)

上述現(xiàn)象直接導(dǎo)致了如下問(wèn)題：

①對(duì)用戶：

• 多個(gè)平臺(tái)和多體系給用戶體驗(yàn)較差，開發(fā)數(shù)據(jù)流程長(zhǎng)，不能快速上手。
• 開發(fā)管理效率成本高，資源成本結(jié)算和任務(wù)管理沒(méi)有統(tǒng)一的視圖。

②對(duì)平臺(tái)：

• 各自的側(cè)重點(diǎn)不同，都不能完全覆蓋大數(shù)據(jù)場(chǎng)景下的能力需求，同時(shí)還有能力重復(fù)建設(shè)問(wèn)題，導(dǎo)致資源浪費(fèi)。
• 出現(xiàn)問(wèn)題排查和維護(hù)困難，需要堆人力解決。

面對(duì)數(shù)據(jù)平臺(tái)難用的情況，提出了構(gòu)建統(tǒng)一易用的大數(shù)據(jù)服務(wù)平臺(tái)整體目標(biāo)。整體架構(gòu)能力圍繞數(shù)據(jù)鏈路解決方案、數(shù)倉(cāng)解決方案、數(shù)據(jù)服務(wù)解決方案來(lái)進(jìn)行建設(shè)，提供統(tǒng)一的元數(shù)據(jù)管理和權(quán)限管理體系。

在這個(gè)大背景和動(dòng)機(jī)下，統(tǒng)一的數(shù)據(jù)入口服務(wù)成為了一個(gè)非常重要的能力，它主要解決：

• 用戶的易用性（一致的入口體驗(yàn)）
• SQL流量治理（代理多引擎）
• 數(shù)據(jù)訪問(wèn)的安全性管控（入口收斂和降低安全風(fēng)險(xiǎn)）

3. 小米SQL服務(wù)歷史發(fā)展情況

從上面的背景問(wèn)題中可以看到，小米內(nèi)部有幾套大數(shù)據(jù)處理的SQL服務(wù)入口，總體還是圍繞經(jīng)典的SQL On hadoop架構(gòu)體系來(lái)構(gòu)建，逐步從ThriftServer演進(jìn)到向上抽象一層的SQL Proxy服務(wù)，在底層集成了Hive/Spark/Doris等引擎為ETL作業(yè)、Ad-Hoc查詢提供支持。

抽離的SparkThriftServer的實(shí)現(xiàn)模塊作為獨(dú)立的SQL Proxy服務(wù)，提供：

• ETL 場(chǎng)景下的HiveServer和Spark APP代理（非常駐）
• Ad-Hoc 場(chǎng)景下的STS、Kylin、Druid代理

從這里可以看到SQL Proxy和Kyuubi Server的定位非常相似，但是存在很多不足：

a. SQL Proxy 沒(méi)有完全剝離STS的實(shí)現(xiàn)，通過(guò)反射的方式進(jìn)行復(fù)用，代碼耦合很高，依賴Spark特定版本，升級(jí)困難

b. 底層引擎代理層沒(méi)有統(tǒng)一抽象，與其他引擎適配困難，對(duì)底層引擎擴(kuò)展性差

c. 無(wú)法本地調(diào)試，依賴Hadoop配置，在辦公和服務(wù)環(huán)境網(wǎng)絡(luò)隔離情況下，必須在開發(fā)機(jī)上完成完整的功能測(cè)試和調(diào)試，開發(fā)和部署路徑長(zhǎng)

4. 基于Kyuubi 構(gòu)建統(tǒng)一SQL入口

(1) 為什么選擇Kyuubi

通過(guò)上面的分析，我們發(fā)現(xiàn)在業(yè)務(wù)和架構(gòu)上都存在著一些問(wèn)題需要解決。

① 業(yè)務(wù)上：

• 在重新打造統(tǒng)一的大數(shù)據(jù)體系的推動(dòng)下，構(gòu)建統(tǒng)一的SQL入口服務(wù)勢(shì)在必行。
• 需要更快的分析引擎，這里我們選擇了Trino。
• 一套易用、高可用并可以持續(xù)演進(jìn)的服務(wù)架構(gòu)，提升大數(shù)據(jù)研發(fā)的生產(chǎn)力。

SQLProxy架構(gòu)需要升級(jí)：

• 完全兼容HiveThrift協(xié)議。
• 松耦合的實(shí)現(xiàn)，基于STS實(shí)現(xiàn)的完全剝離。
• 靈活可擴(kuò)展的代理多引擎的適配。

Kyuubi的優(yōu)勢(shì)在于：

• 與STS和HS2的完全兼容一致
• 高可用和資源隔離
• 清晰簡(jiǎn)潔的架構(gòu)，可測(cè)試、可維護(hù)、可擴(kuò)展
• 社區(qū)高質(zhì)量實(shí)現(xiàn)和業(yè)界生產(chǎn)環(huán)境大量運(yùn)用

SQLProxy和Kyuubi的架構(gòu)非常相似，切換成本低。在業(yè)務(wù)需求和架構(gòu)升級(jí)的雙重推動(dòng)下，我們選擇了Kyuubi。

（2）架構(gòu)升級(jí)

升級(jí)過(guò)程和效果與我們的預(yù)期一致，可以看到架構(gòu)相比SQLProxy更加簡(jiǎn)潔，擴(kuò)展底層引擎非常容易，而且本地可測(cè)試可調(diào)試，極大提升了開發(fā)效率。從開發(fā)到上線新架構(gòu)兩周時(shí)間就完成了平滑遷移。

升級(jí)新架構(gòu)帶來(lái)的效果也非常明顯，相比之前的架構(gòu)不論代碼質(zhì)量、服務(wù)穩(wěn)定性、可維護(hù)性和可擴(kuò)展性上都有了重大提升：

• 多引擎的代理能力（主要支持Spark/Trino/Hive/Doris）。
• 基于數(shù)據(jù)平臺(tái)workspace的體系在Kyuubi Server端實(shí)現(xiàn)了權(quán)限驗(yàn)證和資源隔離。
• 更加規(guī)范化的Hive Thrift API支持，各種生態(tài)可視化工具（Redash/Datagrip等）完美兼容。

(3) 統(tǒng)一SQL服務(wù)的現(xiàn)狀

經(jīng)過(guò)半年的遷移推動(dòng)，每日SQL有效處理量從5W提升到現(xiàn)在的50W規(guī)模，已經(jīng)占據(jù)了整個(gè)SQL流量的80%。特別是SparkSQL的流量半年新增到30W。大體流量分布：Spark 36w/ Trino 12w / Hive 2.5w

各個(gè)引擎請(qǐng)求耗時(shí)：

• Spark和Trino持平，平均延時(shí)30秒左右，P50在5秒左右
• Hive的執(zhí)行效率明顯低于以上兩個(gè)引擎，跟Hive的大任務(wù)有關(guān)，ETL偏多

目前Kyuubi Server 承載真實(shí)的SQL流量日均100w左右，可用性仍然可達(dá)99.9%以上，非常穩(wěn)定。

—

02

打造易用易維護(hù)高可用的Kyuubi服務(wù)

1. 構(gòu)建符合業(yè)務(wù)需求的Kyuubi

(1) 整體架構(gòu)

整體架構(gòu)和流程，主要分為入口服務(wù)、認(rèn)證和權(quán)限適配、底層引擎管理及服務(wù)的可觀測(cè)性：

• Kyuubi Server為基礎(chǔ)構(gòu)建了SQL 統(tǒng)一入口服務(wù)
• Kyuubi Engine 作為Spark SQL執(zhí)行引擎層
• 獨(dú)立Engine Manager服務(wù)管理各類計(jì)算引擎
• Kyuubi Server層集成Ranger服務(wù)，支持基于數(shù)據(jù)平臺(tái)的統(tǒng)一權(quán)限驗(yàn)證
• 擴(kuò)展適配Trino/Hive/Doris引擎服務(wù)指標(biāo)和審計(jì)日志的可視化

(2) 用戶使用交互

以工作空間（workspace）粒度來(lái)保計(jì)算資源的隔離的存儲(chǔ)資源（表）安全，與Kyuubi Group 的多租戶類似，我們這里擴(kuò)展到了其他引擎。

一次完成交互過(guò)程：

WorkspaceA下面的用戶使用平臺(tái)發(fā)放的Token，選擇各類客戶端工具，向引擎提交SQL查詢，Kyuubi Server會(huì)自動(dòng)將用戶SQL提交到該空間所屬的計(jì)算引擎上去，來(lái)保證用戶使用資源的隔離性。與其他workspace用戶雖是同一入口，但是資源的使用上是隔離的。

Kyuubi Server服務(wù)并不具體執(zhí)行SQL，同一的入口服務(wù)不會(huì)有太大壓力。

2. 提升用戶側(cè)的易用性

(1) 統(tǒng)一認(rèn)證和表坐標(biāo)的統(tǒng)一

去Kerberos化，采用平臺(tái)統(tǒng)一Token方式，解決:

• Kerberos接入流程繁瑣
• 普通用戶對(duì)kerberos機(jī)制難以理解，出現(xiàn)問(wèn)題排查困難
• 用戶管理不當(dāng)，同一賬號(hào)下用戶膨脹問(wèn)題
• 審計(jì)和追蹤不能精確定位到用戶個(gè)人

表資源命名的統(tǒng)一規(guī)范化，小米內(nèi)部存在多區(qū)域和多類數(shù)據(jù)源，如果使用統(tǒng)一的SQL入口服務(wù)，需要統(tǒng)一SQL語(yǔ)句的表名規(guī)范來(lái)避免沖突和統(tǒng)一的管理：

• 采用Catalog.Schema.Table 三級(jí)表名為唯一表名
• Kyuubi Server端支持JDBC URL預(yù)設(shè)Catalog/Schema，兼容之前SQL中二級(jí)或者一級(jí)表名
• 結(jié)合URL和SQL Table生成完整的三級(jí)表坐標(biāo)，以供用戶權(quán)限認(rèn)證

(2) Kyuubi Engine 公共資源池

引入Kyuubi Engine公共池主要解決用戶首次進(jìn)入空間提交SparkSQL的查詢性能問(wèn)題。上面提到的用戶提交的SQL分析統(tǒng)計(jì)，50%的SQL查詢延時(shí)都在5秒以下。在沒(méi)有提前分配的資源的情況下，用戶提交查詢會(huì)冷啟動(dòng)一個(gè)Kyuubi Engine，這是Kyuubi當(dāng)前的機(jī)制。由于小米Yarn提交一個(gè)APP的延時(shí)在分鐘級(jí)別，用戶一個(gè)簡(jiǎn)單的秒級(jí)查詢會(huì)延遲到分鐘級(jí)別，體感非常差。

因此，借助Kyuubi Engine Pool的實(shí)現(xiàn)，對(duì)沒(méi)有提前配置和指定資源的workspace用戶，會(huì)將SQL路由到已經(jīng)預(yù)先啟動(dòng)好的Kyuubi Engine Pool，以加快用戶的查詢速度，提升SQL查詢體驗(yàn)。

3. 升級(jí)Spark2.X到Kyuubi Engine

Kyuubi Engine目前只支持Spark3以上，之前我們內(nèi)部版本都是Spark2，在升級(jí)到Kyuubi Engine之前做了相關(guān)對(duì)比測(cè)試，在Kyuubi 架構(gòu)和SQLProxy架構(gòu)下，有明顯的性能提升：

• 在TPC-DS標(biāo)準(zhǔn)測(cè)試集上，P50延時(shí)有75%的性能提升，長(zhǎng)尾基本和SQLProxy性能持平。
• 在真實(shí)的業(yè)務(wù)場(chǎng)景下，P50延時(shí)也有37%的性能提升，長(zhǎng)尾也基本跟SQLProxy一致，也就是升級(jí)的Kyuubi Engine的性能在多數(shù)情況下要優(yōu)于Spark2，整體上不會(huì)比Spark2更差。

4. Kyuubi Server的容器化

在Kyuubi Server的高可用上利用容器化的方式替換了當(dāng)前Kyuubi Client端通過(guò)ZK進(jìn)行服務(wù)發(fā)現(xiàn)的高可用模式：

• 在K8s上部署Kyuubi Server服務(wù)，充分利用K8s的彈性能力保障高可用。
• Kyuubi Server和Kyuubi Engine的部署徹底解耦，作為一個(gè)單獨(dú)的Thrift RPC代理服務(wù)和HTTP服務(wù)，去除Hadoop相關(guān)的配置環(huán)境依賴，和普通業(yè)務(wù)服務(wù)一樣使用LVS做流量負(fù)載均衡。
• 同時(shí)借助內(nèi)部K8s平臺(tái)的CI/CD能力，實(shí)現(xiàn)了Kyuubi Server服務(wù)的全自動(dòng)灰度發(fā)布，支持一鍵升級(jí)和擴(kuò)縮容。

5. 基于Workspace的計(jì)算資源管理

（1）Engine Manager

由于之前已經(jīng)實(shí)現(xiàn)了對(duì)Spark Engine的管理服務(wù)，我們將Kyuubi Engine的管理直接從Kyuubi Server剝離，形成了單獨(dú)的Engine Manager服務(wù)，負(fù)責(zé)Engine的生命周期管理，配置上下文管理，同時(shí)提供服務(wù)發(fā)現(xiàn)和負(fù)載均衡能力。

• 為管理入口提供引擎配置和生命周期管理。
• 為Kyuubi Server提供SQL路由的能力。
• 為運(yùn)維提供可視化的監(jiān)控能力，包括Engine的服務(wù)狀態(tài)、資源占用以及繁忙程度等，便于快速運(yùn)維。

用戶提交的SQL的流程：

• 首先經(jīng)過(guò)Kyuubi Server入口的認(rèn)證和權(quán)限驗(yàn)證。
• Kyuubi Server向EngineManager可用的Kyuubi Engine地址。
• EngineManager 向ZK獲取當(dāng)前用戶空間下可用的Engine，然后統(tǒng)計(jì)當(dāng)前可用Engine的繁忙指標(biāo)，返回相對(duì)空閑的Engine給Kyuubi Server。
• Kyuubi Server 將SQL提交到EngineManager建議的Engine上去執(zhí)行。

(2) 用戶提交

圖上是我們的用戶平臺(tái)SQL查詢?nèi)肟?，在workspace下的用戶可以非常方便地啟動(dòng)一個(gè)Kyuubi Engine。為降低用戶的門檻，只暴露了資源相關(guān)和排隊(duì)策略的配置。同時(shí)，用戶還可以配置多個(gè)Kyuubi Engine實(shí)例，來(lái)保障當(dāng)前workspace下的SQL執(zhí)行的高可用。

(3) Engine的高可用

為什么需要Kyuubi Engine的高可用？因?yàn)樵趯?shí)際環(huán)境中，Kyuubi Engine是一直長(zhǎng)時(shí)間運(yùn)行的，Spark的SQL執(zhí)行過(guò)程非常復(fù)雜，時(shí)間一長(zhǎng)其穩(wěn)定性就有了問(wèn)題：

• 開啟動(dòng)態(tài)資源策略后丟事件的Bug，導(dǎo)致資源無(wú)法釋放。
• 大任務(wù)占用時(shí)間長(zhǎng)，可能阻塞一些小任務(wù)的運(yùn)行。
• Driver端JVM Full GC時(shí)間過(guò)長(zhǎng)和OOM。
• SQL不合理導(dǎo)致的Engine頻繁重啟。

因此實(shí)施了一些高可用的保障策略：

• workspace級(jí)別隔離Engine異常，避免影響其他用戶。
• 觀測(cè)Engine 可用指標(biāo)，通過(guò)繁忙和探活信息標(biāo)記是否當(dāng)前可用。
• 同一workspace下多個(gè)Engine實(shí)例（Kyuubi 的Engine Pool機(jī)制），提升整體可用性，同時(shí)提供基于負(fù)載的分發(fā)。
• 發(fā)現(xiàn)異常及時(shí)自動(dòng)重啟。
• 頻繁重啟Engine通過(guò)告警機(jī)制，人工及時(shí)介入。

—

03

基于Kyuubi的改造

1. Trino和Doris的代理

引入Trino和Doris主要解決OLAP場(chǎng)景的查詢效率問(wèn)題。

• Kyuubi 在1.1.0版本還未支持Trino，我們?cè)趉yuubi Server端使用Trino-JDBC完成了對(duì)Trino引擎的適配。
• Trino-JDBC實(shí)現(xiàn)了流迭代器的模式，每次nextResult都會(huì)觸發(fā)一次對(duì)Trino 引擎的請(qǐng)求。
• 當(dāng)前社區(qū)Trino-Client實(shí)現(xiàn)，會(huì)一次性的拉取所有結(jié)果集可能導(dǎo)致OOM的風(fēng)險(xiǎn)。

對(duì)于Doris的適配也采用了JDBC的方式，由于Doris客戶端本身支持Mysql JDBC，MySQL JDBC的實(shí)現(xiàn)方式是全量拉取模式，Kyuubi Server端有OOM的風(fēng)險(xiǎn)。目前通過(guò)限制Doris查詢的超時(shí)時(shí)間來(lái)降低大結(jié)果集導(dǎo)致OOM的風(fēng)險(xiǎn)。

如果大家后面要擴(kuò)展Kyuubi代理其他JDBC的數(shù)據(jù)庫(kù)支持，一定謹(jǐn)慎處理。

2. SQL HTTP API的支持

關(guān)于HTTP API的支持一共實(shí)現(xiàn)了V1版本和V2版本，相比社區(qū)還是有一些區(qū)別。

① V1版本

• 簡(jiǎn)化用戶的交互過(guò)程，簡(jiǎn)化Hive Thrift RPC的調(diào)用流程，用戶直接在上層應(yīng)用程序中通過(guò)HTTP 請(qǐng)求就能提交SQL，對(duì)一些研發(fā)用戶來(lái)說(shuō)是非常友好的。提交SQL根據(jù)QueryID，不斷輪詢獲取結(jié)果。
• 復(fù)用了Thrift backend Service的實(shí)現(xiàn)，水平擴(kuò)展了一層HTTP Fronted Service。底層實(shí)現(xiàn)跟Thrift API完全保持一致。

但是也存在一些問(wèn)題：

• Kyuubi Service端是有Session狀態(tài)的，Step1和Step2必須路由的同一個(gè)實(shí)例才能獲取到結(jié)果，采用IP Hash不能完全解決。
• 這樣也導(dǎo)致Kyuubi Server HTTP 服務(wù)無(wú)法水平擴(kuò)展和平滑升級(jí)。

②V2版本

為了徹底解決V1的水平擴(kuò)展性問(wèn)題，在V2版本中將Kyuubi HTTP Server完全無(wú)狀態(tài)化，通過(guò)Kyuubi Engine 直接提供HTTP SQL API。Kyuubi Server只起到出代理的作用。

另外的兩點(diǎn)改進(jìn)：

• 徹底解決大結(jié)果集的導(dǎo)致Kyuubi Engine OOM的問(wèn)題，將查詢類的結(jié)果直接持久化到HDFS，不經(jīng)過(guò)Spark Driver端。
• 用戶在獲取結(jié)果的時(shí)候不經(jīng)過(guò)Kyuubi Engine，直接從HDFS層流式獲取結(jié)果集。

同時(shí)，也不用維持長(zhǎng)鏈接，非常適合ETL的場(chǎng)景。

3. SQL 表列解析

我們?cè)贙yuubi Server端做了權(quán)限認(rèn)證，需要獲取用戶SQL的真實(shí)表名，單獨(dú)開發(fā)了一個(gè)純SQL的解析模塊：支持表列血緣關(guān)系和SQL類型的提取，支持SparkSQL、Trino兩種語(yǔ)法。

具體解析后的格式如圖，包括類型、輸入輸出表和隊(duì)列的列。

后續(xù)在具體實(shí)際場(chǎng)景中該模塊的也應(yīng)用到了其業(yè)務(wù)場(chǎng)景，比如表血緣審計(jì)日志，SQL的統(tǒng)計(jì)請(qǐng)求分析等安全質(zhì)量場(chǎng)景，完全復(fù)用了我們的SQL表列提取的能力。

—

04

Kyuubi 新特性的應(yīng)用

1. 小文件合并

解決用戶寫場(chǎng)景可能導(dǎo)致的小文件過(guò)多的問(wèn)題。用戶一般會(huì)提交兩個(gè)SQL：一個(gè)是業(yè)務(wù)處理SQL，一個(gè)是合并SQL，通過(guò)通過(guò)workflow方式串聯(lián)起來(lái)，維護(hù)不變。

開啟也非常簡(jiǎn)單，可以在Kyuubi Engine啟動(dòng)階段，SQL提交階段開啟開關(guān)。

2. 增量獲取和獲取結(jié)果集限制

• 主要是JDBC下用戶有結(jié)果集的查詢導(dǎo)致的OOM問(wèn)題，開啟增量模式。但有些場(chǎng)景下會(huì)有部分分區(qū)的結(jié)果太大，導(dǎo)致取結(jié)果過(guò)程阻塞，導(dǎo)致有不好的用戶體驗(yàn)。推薦采用HTTP API 異步結(jié)果獲取方式解決。
• 對(duì)用戶一些預(yù)覽數(shù)據(jù)的SQL，如果訪問(wèn)的表非常大，限制查詢條數(shù)輸出是一個(gè)非常好的功能，避免不必要的開銷

3. Z-Ordering

在我們內(nèi)部畫像場(chǎng)景做相關(guān)的測(cè)試，Z-Ordering有顯著的提升。

• 業(yè)務(wù)查詢時(shí)間
• 存儲(chǔ)空間
• 查詢掃描數(shù)據(jù)量
• 文件數(shù)量

在具體應(yīng)用中，Z-Ordering的排序規(guī)則需要根據(jù)實(shí)際業(yè)務(wù)表的數(shù)據(jù)做相應(yīng)調(diào)整：

• 我們畫像場(chǎng)景查詢頻次高的列進(jìn)行排序，效果明顯
• 超過(guò)3個(gè)列后的優(yōu)化并不理想
• 排序列應(yīng)選擇基數(shù)較大且沒(méi)有傾斜的列

Kyuubi Engine Z-Ordering的實(shí)現(xiàn)非常巧妙，沒(méi)有增加額外的列，直接復(fù)用了parquet的原生能力，所以一次生成可以支持多個(gè)引擎查詢（只要該引擎支持parequet格式的讀?。?/span>

4. PlanOnly 模式

主要用于非SQL執(zhí)行的SQL相關(guān)場(chǎng)景，比如：

• 為數(shù)據(jù)平臺(tái)提供語(yǔ)法語(yǔ)義校驗(yàn)服務(wù)
• SQL 提交前的檢查
• SQL 語(yǔ)法語(yǔ)義兼容性的檢查（Spark2.X->Spark3.X的升級(jí)）

PlanOnly模式下SQL不會(huì)真正執(zhí)行，只會(huì)輸出解析后的LogicalPlan/SparkPlan。目前為數(shù)據(jù)平臺(tái)單獨(dú)提供了語(yǔ)法語(yǔ)義校驗(yàn)服務(wù)，就是采用Kyuubi Engine的PlanOnly模式。

這種應(yīng)用場(chǎng)景也為我們提供了一種新思路：將Kyuubi Engine作為Yarn APP的服務(wù)框架，提供其他場(chǎng)景的服務(wù)，比如校驗(yàn)服務(wù)、血緣關(guān)系提取服務(wù)和SQL的預(yù)計(jì)算服務(wù)等。

5. Scala mode

Scala Code模式完全解放了Kyuubi Engine能力，具備直接通過(guò)JDBC提交Scala 代碼的能力，專門處理一些復(fù)雜邏輯的業(yè)務(wù)。

目前我們的應(yīng)用場(chǎng)景在運(yùn)維這塊做了一些嘗試，主要解決我們的運(yùn)維效率。例如我們要在運(yùn)行時(shí)動(dòng)態(tài)加載用戶自定義的jar包，讀取Thrift格式化的數(shù)據(jù)。相比之前登錄到生產(chǎn)集群機(jī)器打包代碼運(yùn)行的流程大大簡(jiǎn)化。

—

05

未來(lái)規(guī)劃和總結(jié)

規(guī)劃：

• 基于業(yè)務(wù)場(chǎng)景、SQL規(guī)則和執(zhí)行代價(jià)事前預(yù)測(cè)，實(shí)現(xiàn)多引擎下的自動(dòng)路由能力。
• HTTP API代替Thrift API提交的ETL作業(yè)，異步化取代長(zhǎng)連接的方式。

總結(jié)：

• Kyuubi 是非常優(yōu)秀開源實(shí)踐，已經(jīng)成為小米內(nèi)部大 數(shù)據(jù)服務(wù)入口的重要基礎(chǔ)架構(gòu)服務(wù) 。
• 非常感謝Kyuubi的社區(qū)的貢獻(xiàn)，加速了我們統(tǒng)一 SQL服務(wù)的落地 。
• 相信未來(lái)Kyuubi會(huì)成為大數(shù)據(jù)場(chǎng)景下的SQL Gateway標(biāo)桿，與大家一起共建Kyuubi生態(tài) 。

今天的分享就到這里，謝謝大家。

閱讀更多技術(shù)干貨文章、下載講師PPT

請(qǐng)關(guān)注微信公眾號(hào)“DataFunSummit”

分享嘉賓：張耀東 小米 高級(jí)研發(fā)工程師

出品平臺(tái)：DataFunTalk

01/分享嘉賓

02/報(bào)名看直播 免費(fèi)領(lǐng)PPT

03/關(guān)于我們

DataFun：專注于大數(shù)據(jù)、人工智能技術(shù)應(yīng)用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過(guò)100+線下和100+線上沙龍、論壇及峰會(huì)，已邀請(qǐng)超過(guò)2000位專家和學(xué)者參與分享。其公眾號(hào) DataFunTalk 累計(jì)生產(chǎn)原創(chuàng)文章700+，百萬(wàn)+閱讀，14萬(wàn)+精準(zhǔn)粉絲。

歡迎轉(zhuǎn)載分享，轉(zhuǎn)載請(qǐng)私信留言。