Kyuubi 實(shí)踐 | Apache Kyuubi 在網(wǎng)易的深度實(shí)踐
分享的內(nèi)容主要包括三個(gè)內(nèi)容：
1)Kyuubi是什么？介紹Kyuubi的核心功能以及Kyuubi在各個(gè)使用場(chǎng)景中的解決方案；?
2)Kyuubi在網(wǎng)易內(nèi)部的定位、角色和實(shí)際使用場(chǎng)景；?
3)通過(guò)案例分享Kyuubi在實(shí)際過(guò)程中如何起到作用。
Kyuubi是什么
開源Kyuubi是網(wǎng)易秉持開源理念的作品。Kyuubi是網(wǎng)易第一款貢獻(xiàn)給Apache并進(jìn)入孵化的開源項(xiàng)目。Kyuubi主要應(yīng)用在大數(shù)據(jù)領(lǐng)域場(chǎng)景，包括大數(shù)據(jù)離線計(jì)算、數(shù)據(jù)倉(cāng)庫(kù)、Ad Hoc等方向。通過(guò)Kyuubi進(jìn)入Apache的自我描述，可以知道Kyuubi是一個(gè)分布式、支持多用戶、兼容DBC或ODBC的大數(shù)據(jù)處理服務(wù)。Kyuubi采用了Apache Spark作為計(jì)算引擎，并帶來(lái)了很好的性能收益。Kyuubi未來(lái)也可能會(huì)支持其他的類似執(zhí)行引擎，比如：Apache Flink。Kyuubi在2018年由網(wǎng)易開源到Github， 2021年成功進(jìn)入Apache進(jìn)行孵化，現(xiàn)在是處于孵化階段。
1.1關(guān)鍵字
大規(guī)模數(shù)據(jù)處理能力：需求分成兩種情況：
?第一種情況是數(shù)據(jù)量的規(guī)模。比如：SQL查詢，可能需要處理的數(shù)據(jù)量是GB或者TB級(jí)別的龐大規(guī)模，這就需要大規(guī)模數(shù)據(jù)處理能力來(lái)處理這種規(guī)模的數(shù)據(jù)；
?第二種情況是并發(fā)查詢的規(guī)模。當(dāng)任務(wù)非常多，每天會(huì)有幾萬(wàn)個(gè)或者幾十萬(wàn)個(gè)SQL查詢?nèi)蝿?wù)在Kyuubi 上運(yùn)行時(shí)，就需要有一個(gè)足夠強(qiáng)大的處理能力，保證服務(wù)端可以及時(shí)響應(yīng)用戶的請(qǐng)求。
開箱即用：Kyuubi的務(wù)實(shí)、親民設(shè)計(jì)理念，追求讓用戶以最低的成本、獲取最好的效果。
1.2主流查詢引擎對(duì)比
圖 3?1.2主流查詢引擎一覽表
?
與目前主流的SQL大數(shù)據(jù)計(jì)算引擎進(jìn)行對(duì)比，Kyuubi有著自己獨(dú)特的優(yōu)勢(shì)：
?對(duì)外接口：都是基于Hive JDBC，如果使用Hive Server2遷移到Kyuubi時(shí)，整個(gè)切換是無(wú)縫、自然的使用Kyuubi；
?計(jì)算引擎：由計(jì)算引擎相關(guān)經(jīng)驗(yàn)可以知道，Hive Server2基于MapRedeuce；Spark Thrift Server基于Spark，Kyuubi同樣采用Spark計(jì)算引擎；
?多版本能力：Kyuubi在Spark基礎(chǔ)上，具備提供多版本Spark的能力。在歷史的迭代或產(chǎn)品的升級(jí)中，都會(huì)存在歷史版本在測(cè)試和生產(chǎn)環(huán)境中，因此支持多版本的能力也非常重要；
?SQL解析優(yōu)化：簡(jiǎn)單看就是毫秒級(jí)別或者是秒級(jí)別的優(yōu)勢(shì)，其實(shí)還有很多映射關(guān)系。比如Spark查一張表，需要Hive的全局鎖，或者需要Hive全局鎖控制整個(gè)的請(qǐng)求過(guò)程。在這個(gè)基礎(chǔ)上，如果有多個(gè)用戶同時(shí)去查詢，可能會(huì)出現(xiàn)阻塞或者單點(diǎn)瓶頸的問(wèn)題。Kyuubi可以把整個(gè)流程下推到引擎上，保證服務(wù)端可以及時(shí)的、快速的響應(yīng)用戶的請(qǐng)求，并且可以保持用戶之間的引擎完全隔離；
?多租戶：是企業(yè)級(jí)應(yīng)用系統(tǒng)的基本功能，Kyuubi同時(shí)支持并保證多租戶的數(shù)據(jù)安全性；
?動(dòng)態(tài)資源配置：Hive的SQL基于MapReduce；Spark Thrift Server的資源配置并不是很靈活，原因在于Spark是全局單實(shí)例的方式，無(wú)論用戶多少，都只能擁有一套資源配置場(chǎng)景。而Kyuubi提供了基于引擎粒度的資源配置，幫助用戶實(shí)現(xiàn)任務(wù)間的快速隔離；
?高可用：是企業(yè)級(jí)SQL引擎的基本特性。Spark Thrift Server不具備這種能力；而Kyuubi提供了基于ZooKeeper的高可用解決方案，以支持高可用特性；
?并發(fā)查詢能力：Kyuubi在基于高可用特性的基礎(chǔ)上，可以輕松的在服務(wù)端進(jìn)行橫向的水平擴(kuò)展，以保證并發(fā)查詢能力，而Spark Thrift Server不支持并發(fā)查詢特性；
?云原生：是近幾年比較熱門的話題，它可以幫助用戶把整個(gè)集群進(jìn)行混合部署，節(jié)省用戶的資源使用。Kyuubi也同樣支持以上云原生場(chǎng)景；
?云原生集成測(cè)試：在云原生的基礎(chǔ)上，Kyuubi提供了與云原生相關(guān)的集成測(cè)試。Kyuubi是基于Minikube組件實(shí)現(xiàn)集成測(cè)試，這一環(huán)節(jié)在很多主流的技術(shù)組件中被忽視。通過(guò)完整的集成測(cè)試流程和高測(cè)試覆蓋率，可以極大的降低用戶在工作環(huán)境中出現(xiàn)bug的可能性。
1.3?Kyuubi的架構(gòu)
Kyuubi的架構(gòu)請(qǐng)看下面的具體的架構(gòu)圖。從左到右整張架構(gòu)圖可以分成三個(gè)部分：
圖 4 ?kyuubi的架構(gòu)示意圖
?
1)?客戶端：是用戶可以接觸到的部分。比如：Hive Beeline、JDBC或ODBC接口，在內(nèi)部，網(wǎng)易有數(shù)也是以客戶端的角色連接到 Kyuubi；
2)?Kyuubi服務(wù)端：通過(guò)和客戶端建立一些會(huì)話（KyuubiSession），會(huì)話最終被路由到實(shí)際的執(zhí)行引擎。
3)?實(shí)際執(zhí)行引擎：會(huì)話路由的過(guò)程比較靈活，甚至可以由用戶自定義。在這張架構(gòu)圖展現(xiàn)的案例就是用戶A用戶B共享引擎，即使用了同一個(gè)引擎；而用戶C用了另一個(gè)引擎。在這個(gè)場(chǎng)景下，用戶的整個(gè)引擎資源實(shí)現(xiàn)了隔離，并且引擎之間也可以部署在不同級(jí)資源管理集群，比如：支持Spark On Yarn或者Spark On Kubernetes。在這種很靈活的配置環(huán)境下，用戶可以輕松的、讓自己的任務(wù)跑在任意集群。這些都是Kyuubi架構(gòu)的優(yōu)勢(shì)。
Kyuubi在網(wǎng)易的應(yīng)用
Kyuubi在網(wǎng)易的應(yīng)用包括兩方面：
1)?用戶畫像：有哪些人、哪些團(tuán)隊(duì)使用Kyuubi大數(shù)據(jù)引擎組件；
2)?業(yè)務(wù)場(chǎng)景：Kyuubi的使用場(chǎng)景和業(yè)務(wù)場(chǎng)景，以及對(duì)應(yīng)不同業(yè)務(wù)場(chǎng)景的解決方案。
1.1?用戶畫像
Kyuubi使用者可以分成三個(gè)大類：
圖5 ?Kyuubi 用戶畫像
?
1)?數(shù)倉(cāng)團(tuán)隊(duì)：數(shù)倉(cāng)團(tuán)隊(duì)又細(xì)分成三種：
?傳統(tǒng)數(shù)倉(cāng)團(tuán)隊(duì)，使用MySql或Oracle做數(shù)據(jù)分析，沒(méi)有大數(shù)據(jù)、大數(shù)據(jù)引擎的處理能力，不知道SQL查詢?cè)谟?jì)算引擎上的整個(gè)執(zhí)行過(guò)程，只知道數(shù)據(jù)的結(jié)果；
?有一些Hive或者Spark的使用經(jīng)驗(yàn)，部分了解配置優(yōu)化；
?關(guān)注性能和成本，不接受任務(wù)跑得很快，但占用很多資源的情況。
2) BI團(tuán)隊(duì)：專注于面向業(yè)務(wù)開發(fā)，工作時(shí)間相對(duì)集中在工作日的白天，對(duì)成本不敏感，更關(guān)注 SQL 查詢的執(zhí)行性能；
3) Spark團(tuán)隊(duì)：Kyuubi重度使用者。Spark團(tuán)隊(duì)有三個(gè)方面的任務(wù)：
?日常管理Spark版本。不同于社區(qū)，網(wǎng)易內(nèi)部有很多Spark分支，每個(gè)月或者定期會(huì)發(fā)布修復(fù)Bug的Spark版本、或增加新功能；
?進(jìn)行插件管理。由于Spark插件多種多樣，比如：SQL的插件可以優(yōu)化SQL；權(quán)限控制插件，幫助用戶做數(shù)據(jù)脫敏加密；
?完成配置管理。當(dāng)客戶端分布在各個(gè)節(jié)點(diǎn)的時(shí)候，維護(hù)配置比較困難；而Kyuubi面對(duì)這樣的場(chǎng)景，可以統(tǒng)一在服務(wù)端實(shí)現(xiàn)維護(hù)，整個(gè)過(guò)程很簡(jiǎn)捷。
1.2?業(yè)務(wù)場(chǎng)景
在Kyuubi的使用過(guò)程可以分成四個(gè)大類：
1)?海量任務(wù)；
2)?復(fù)雜環(huán)境；
3)?復(fù)雜任務(wù)；
4)?多入口。
圖 6業(yè)務(wù)場(chǎng)景一覽
2.2.1?海量任務(wù)
由于網(wǎng)易內(nèi)部的團(tuán)隊(duì)和業(yè)務(wù)部門很多，Kyuubi的任務(wù)數(shù)量也非常多，每天有幾萬(wàn)或幾十萬(wàn)個(gè)SQL任務(wù)，高峰期每秒鐘都會(huì)有很多Kyuubi請(qǐng)求任務(wù)。
2.2.2?復(fù)雜任務(wù)
任務(wù)復(fù)雜程度也需要考慮，由于Kyuubi的用戶人群很多，如上所述有：數(shù)倉(cāng)、BI或者其他的開發(fā)人員，其任務(wù)的復(fù)雜度也各不相同。比如：數(shù)倉(cāng)任務(wù)如果是細(xì)數(shù)據(jù)，需要做簡(jiǎn)單的清洗類似ETL類型，屬于IO密集型任務(wù)；如果是一個(gè)輕量聚合或者匯總層的任務(wù)，整個(gè)過(guò)程比較簡(jiǎn)捷，屬于CPU密集型任務(wù)。這些場(chǎng)景在Kyuubi上的任務(wù)是非常復(fù)雜的。
2.2.3?復(fù)雜環(huán)境
?多集群混合管理能力
由于支持On Yarn或者On Kubernetes，有些用戶需求出于穩(wěn)定性或成本的考慮，提出Query的部分SQL分別跑在On Yarn或On Kubernetes上，Kyuubi具備支撐這種多集群混合管理的能力。
?多版本能力
能夠管理多個(gè)Spark版本，以及Spark依賴不同版本的Hive，整個(gè)環(huán)境非常復(fù)雜。
2.2.4?多入口
由于網(wǎng)易有數(shù)的很多產(chǎn)品線接入了Kyuubi，比如：BI或者AI的平臺(tái)；網(wǎng)易在做的自助分析和離線開發(fā)的SQL任務(wù)，也已經(jīng)接入了Kyuubi。Kyuubi需要控制和維護(hù)這么多入口，有相當(dāng)?shù)膲毫Α?/span>
下面分別分析不同場(chǎng)景下Kyuubi的實(shí)際解決方案和使用經(jīng)驗(yàn)。
1.3?業(yè)務(wù)場(chǎng)景?– 數(shù)據(jù)倉(cāng)庫(kù)
圖 7數(shù)據(jù)倉(cāng)庫(kù)業(yè)務(wù)場(chǎng)景
?
在數(shù)倉(cāng)類離線任務(wù)的使用場(chǎng)景下，有三個(gè)核心痛點(diǎn)：
1) SQL任務(wù)綁定用戶權(quán)限。就是需要數(shù)據(jù)隔離或數(shù)據(jù)讀寫的安全性以保證數(shù)據(jù)的安全。
在這個(gè)背景下，Kyuubi支持kerberos多租戶的認(rèn)證，同時(shí)支持：
?用戶代理模式；
?keytab的認(rèn)證方式，通過(guò)靈活的配置就可以滿足用戶在不同業(yè)務(wù)場(chǎng)景下的需求疊加。
2) SQL任務(wù)數(shù)量大，調(diào)度集中。比如數(shù)倉(cāng)任務(wù)大部分都在凌晨一兩點(diǎn)的時(shí)候任務(wù)提交啟動(dòng)。在這個(gè)場(chǎng)景下，Kyuubi提供：
?HA能力，保證服務(wù)的高用性和SLA指標(biāo)；
?提供服務(wù)端水平擴(kuò)展，業(yè)務(wù)線可以部署兩臺(tái)或以上Kyuubi服務(wù)，保證每個(gè)Kyuubi負(fù)載均勻，確保能夠快速響應(yīng)用戶的請(qǐng)求。
3)?性能參差不齊?？紤]到歷史任務(wù)不可能把每個(gè)任務(wù)都已經(jīng)跑到目標(biāo)性能，有些任務(wù)連一些常見Spark配置都沒(méi)有改，或者SQL本身也不規(guī)范。在這個(gè)事實(shí)基礎(chǔ)上，Kyuubi提供了標(biāo)準(zhǔn)化SQL插件、來(lái)標(biāo)準(zhǔn)化SQL任務(wù)。由于SQL腳本數(shù)量非常巨大，成千上萬(wàn)的又不可能讓用戶逐個(gè)去修改，標(biāo)準(zhǔn)化SQL任務(wù)的方式就會(huì)非常有效果。
Kyuubi提供了集中式SQL任務(wù)的標(biāo)準(zhǔn)化，其中最核心的兩個(gè)功能是：
?提高任務(wù)的性能下限，任務(wù)性能再差，也比上Kyuubi之前的性能要好；
?統(tǒng)一解決小文件問(wèn)題。小文件問(wèn)題是一個(gè)老生常談的問(wèn)題，不同的公司會(huì)有不同的解決方案。Kyuubi提供的統(tǒng)一解小文件問(wèn)題方案，可以極大減輕整個(gè)集群的存儲(chǔ)壓力，保證了每個(gè)任務(wù)的瓶頸產(chǎn)生文件都是期望大小，比如200MB以上。?
1.4?業(yè)務(wù)場(chǎng)景?– Ad hoc
圖 8 ?Ad?hoc業(yè)務(wù)場(chǎng)景
?
Ad hoc業(yè)務(wù)場(chǎng)景是BI團(tuán)隊(duì)會(huì)遇到的場(chǎng)景，Ad hoc場(chǎng)景中遇到的痛點(diǎn)和方案如下：
1) SQL任務(wù)性能敏感?？焖夙憫?yīng)的任務(wù)，以秒為單位進(jìn)行計(jì)時(shí)，如果超過(guò)指定時(shí)長(zhǎng)，就會(huì)直接放棄這個(gè)任務(wù)結(jié)果。在這種需求下，Kyuubi提供了引擎共享能力：
?會(huì)話熱啟動(dòng)：當(dāng)用戶創(chuàng)建會(huì)話時(shí)，Kyuubi的計(jì)算指令引擎已經(jīng)處于活躍狀態(tài)，比如：和 Hive Metastore 的連接已經(jīng)連接成功，整個(gè)的Spark機(jī)制都已經(jīng)運(yùn)轉(zhuǎn)起來(lái)，無(wú)需再處理這些過(guò)程。整個(gè)Query會(huì)非?？?，極大減輕了整個(gè)SQL啟動(dòng)時(shí)間。比如：SQL本身執(zhí)行需要十幾秒，整個(gè)任務(wù)的起效時(shí)間大概需要十秒，甚至由于資源管理器不一樣、或者Kubernetes出現(xiàn)資源挑戰(zhàn)，都可能需要幾十秒的時(shí)間，整個(gè)過(guò)程非常緩慢。Kyuubi提供的會(huì)話熱啟動(dòng)的能力，相當(dāng)于把每一個(gè)SQL ?Query的查詢時(shí)間提升50%或者100%，使得性能有明顯的提升。
?引擎池：目前在Kyuubi社區(qū)還在討論如何進(jìn)一步開發(fā)。核心目標(biāo)就是為了解決：當(dāng)某些用戶的SQL吞吐量非常大，單個(gè)引擎實(shí)力滿足不了需求時(shí)，需要多個(gè)引擎同時(shí)在線提供服務(wù)。在這種場(chǎng)景下，Kyuubi通過(guò)引擎池，配套負(fù)載均衡或者類似Round-Robin這種隨機(jī)引擎選擇策略，用戶就可以優(yōu)雅地增加查詢能力。
2) SQL任務(wù)幾乎都在白天跑。常見的SQL任務(wù)的工作時(shí)間是九點(diǎn)到下午十七點(diǎn)，在這段時(shí)間使用頻率很高；在晚上整個(gè)集群就基本上都處于閑置狀態(tài)。Kyuubi在這個(gè)場(chǎng)景下可以支持云原生能力，幫助用戶把Ad hoc任務(wù)或者Ad hoc的Kyuubi集群、以及背后的引擎資源，全部可以部署到Kubernetes上，讓整個(gè)處于閑置狀態(tài)下的資源充分利用起來(lái)，避免出現(xiàn)浪費(fèi)，從而降低用戶的資源成本。
3) SQL任務(wù)更加注重?cái)?shù)據(jù)查詢。數(shù)據(jù)查詢相對(duì)于數(shù)據(jù)寫入場(chǎng)景的場(chǎng)景來(lái)說(shuō)，SQL Query的結(jié)果數(shù)量可能很少，只有幾條或十幾條數(shù)據(jù)肉眼可見的數(shù)據(jù)規(guī)模。在這種場(chǎng)景下，可以把整個(gè)計(jì)算引擎的配置都標(biāo)準(zhǔn)化為優(yōu)先并發(fā)的配置，即不考慮小文件問(wèn)題。此時(shí)不存在小文件，就可以把整個(gè)分區(qū)或者分區(qū)處理的文件大小，控制在諸如32兆或者16兆更小的數(shù)據(jù)規(guī)模，從而保證整個(gè)SQL Query的高性能。此外還提供了配置模板的特性方案，主要功能是把整個(gè)SQL任務(wù)進(jìn)行分類。比如：數(shù)據(jù)查詢是一大類，這個(gè)粒度比較粗，后面將針對(duì)用戶的任務(wù)，定義更細(xì)粒度的類型，并給出相應(yīng)的配置模板。在不同配置模板下，就可以發(fā)揮出計(jì)算引擎強(qiáng)大的性能。比如：發(fā)揮Spark計(jì)算引擎的強(qiáng)大性能，從而幫助提升用戶的查詢效率，加快查詢速度。
1.5?業(yè)務(wù)場(chǎng)景?– 內(nèi)部系統(tǒng)
在業(yè)務(wù)場(chǎng)景中會(huì)有難以描述的內(nèi)部系統(tǒng)，具體也不清楚該系統(tǒng)是用來(lái)做什么業(yè)務(wù)，或者有那些隱藏在背后的用戶。針對(duì)這樣的內(nèi)部系統(tǒng)業(yè)務(wù)場(chǎng)景，其解決方案如下：
圖9內(nèi)部系統(tǒng)業(yè)務(wù)場(chǎng)景
?
1)?由于接入Kyuubi的門檻很低，用戶通過(guò)JDBC或者Hive Beeline就可以輕松接入Kyuubi，整個(gè)過(guò)程是很輕量級(jí)。對(duì)于已經(jīng)接入Hive ?Server2的系統(tǒng)，Kyuubi完全兼容Hive的接口，用戶任務(wù)的遷移周期非常短。對(duì)于開發(fā)者來(lái)說(shuō)，Kyuubi把背后的引擎優(yōu)化成Spark，提供了緩存、插件等，僅僅改一兩行代碼就可以帶來(lái)很大的收益，可以讓用戶得到更好的性能效果。
2)?對(duì)于意料之外接入的系統(tǒng)，Kyuubi提供了整套全生命周期管理的配套措施。不管用戶創(chuàng)建了會(huì)話、通過(guò)會(huì)話創(chuàng)建的引擎實(shí)例，還是在引擎實(shí)例跑的SQL任務(wù)，Kyuubi對(duì)于各個(gè)層級(jí)、各個(gè)粒度資源，都做了生命管控。
例如：一個(gè)引擎實(shí)例已經(jīng)閑置了十分鐘，Kyuubi就會(huì)主動(dòng)釋放引擎資源，而不會(huì)再浪費(fèi)整個(gè)集群資源。通過(guò)這種方式可以降低歷史任務(wù)、或意料之外的任務(wù)浪費(fèi)集群資源，保證集群的穩(wěn)定性。
案例分析
以上講述了Kyuubi在網(wǎng)易內(nèi)部的一些使用場(chǎng)景和相應(yīng)的解決方案。最后分享一個(gè)具體案例，讓大家感受如何實(shí)際使用Kyuubi，以及Kyuubi發(fā)揮的價(jià)值。
2.1 案例痛點(diǎn)1：
1)?案例背景和矛盾：有用戶的任務(wù)跑在Hive ?On Yarn的場(chǎng)景，用戶想優(yōu)化整個(gè)任務(wù)、或改Spark跑、或改到Kubernetes上做任務(wù)。
圖 10 Hive ?On Yarn優(yōu)化案例
?
2)?整個(gè)案例的痛點(diǎn)：Hive任務(wù)的自身優(yōu)化空間比較小，加了幾個(gè)或十幾個(gè)配置之后，還沒(méi)有達(dá)到用戶的預(yù)期，用戶就切換背后的執(zhí)行引擎到Spark。由于任務(wù)的整個(gè)執(zhí)行時(shí)間上的規(guī)律、或執(zhí)行時(shí)間分散，用戶想用Kubernetes進(jìn)一步的降低成本。在推出Spark 3.0之后，推出了基于AQE的、基于運(yùn)行中的數(shù)據(jù)計(jì)算信息、優(yōu)化每一個(gè)Stage的功能。用戶想用該功能，但是如果直接切到 Spark，整個(gè)過(guò)程非常通過(guò)。而采用Kyuubi將會(huì)讓整個(gè)遷移過(guò)程變得更加平滑
2.2 案例痛點(diǎn)2：
1)?案例背景和矛盾：由于歷史原因，每個(gè)公司或者每個(gè)團(tuán)隊(duì)都有整個(gè)任務(wù)的調(diào)度體系。
?
圖 11古老腳本的遷移案例
?
2)?整個(gè)案例的痛點(diǎn)：對(duì)于這個(gè)案例，之前的SQL腳本大家都保存在shell腳本里面，再通過(guò)一些Hive執(zhí)行SQL腳本，整個(gè)過(guò)程都是非常原始，沒(méi)有統(tǒng)一的管理系統(tǒng)。對(duì)于外部系統(tǒng)想接入或者想做更新和優(yōu)化非常困難。
對(duì)于這個(gè)遷移性項(xiàng)目，給用戶帶來(lái)的收益可以看成是三部分內(nèi)容：
?遷移舊系統(tǒng)的代價(jià)；
?舊系統(tǒng)的代價(jià)減去新系統(tǒng)的代價(jià)；
?再減去遷移成本，這才是用戶最終得到的收益。
如果降低了用戶的遷移成本，保留了用戶的使用習(xí)慣之后，給用戶帶來(lái)的收益也是增加的。并且在用戶的舊任務(wù)遷移完成之后，用戶新任務(wù)的開發(fā)也有很大收益。因此 Kyuubi 選擇保留用戶的使用習(xí)慣。
2.3 案例痛點(diǎn)3：
1)?案例背景和矛盾：遷移周期和遷移效果的矛盾。
?
圖 12遷移周期與經(jīng)營(yíng)效果案例
?
2)?整個(gè)案例的痛點(diǎn)：整個(gè)遷移數(shù)據(jù)的SQL任務(wù)數(shù)會(huì)很多，比如：2000多的任務(wù)，每個(gè)任務(wù)也非常復(fù)雜；想要達(dá)到的效果目標(biāo)很高，比如：每個(gè)任務(wù)平均性能提升40%，也就是之前100秒跑完的任務(wù)，現(xiàn)在想要40秒就能跑完，資源節(jié)省30%。這樣資源和性能是兩個(gè)矛盾點(diǎn)。
當(dāng)資源充足的情況下，性能自然就能提升；但資源和性能都要提升，這在一定條件下是非常困難的。
2.4 案例痛點(diǎn)的解決方案：
根據(jù)前面Kyuubi的特性，Kyuubi針對(duì)以上三個(gè)痛點(diǎn)提出了解決方案：
圖 13 案例痛點(diǎn)的解決方案
?
1)?完全兼容Hive JDBC接口。用戶只需要改beeline的JDBC連接串就可以非常輕量、無(wú)縫的、平滑的切換到Kyuubi。在切換到Kyuubi之后，不管背后是Spark On Yarn或者Spark On Kubernetes，用戶都無(wú)需關(guān)心整個(gè)運(yùn)行集群或運(yùn)營(yíng)配置。只要跑在Kyuubi上，剩下工作的交給Kyuubi就可以。整個(gè)遷移的流程非常平滑，對(duì)用戶也非常簡(jiǎn)單。
2) Kyuubi提供了AQE的線下增強(qiáng)插件。在Spark社區(qū)分支的基礎(chǔ)上，Kyuubi提供了增強(qiáng)版AQE。同時(shí)Kyuubi項(xiàng)目組也向Spark社區(qū)提交了大約20多個(gè)AQE的補(bǔ)丁，對(duì)Spark進(jìn)行了優(yōu)化。
增強(qiáng)插件的核心需求有兩個(gè)：
?小文件合并。把每一個(gè)SQL任務(wù)，標(biāo)準(zhǔn)化成帶小文件合并的SQL任務(wù)，這樣就讓用戶的每個(gè)SQL任務(wù)、產(chǎn)出的文件數(shù)保持一定規(guī)模。比如：每個(gè)任務(wù)產(chǎn)出平均文件的大小都是200或500多兆，可以對(duì)齊HDFS 的 Block 大小，或者對(duì)齊更大的文件需求。
?基于Stage的配置隔離。Stage是Spark的一個(gè)概念，Spark對(duì)于每個(gè)shuffle切割Stage，Stage粒度的配置隔離，意味著可以對(duì)shuffle進(jìn)行優(yōu)化，向用戶提供更多優(yōu)化的可能性，同時(shí)提高了任務(wù)的優(yōu)化上限。?
3)?支持混部集群。Kyuubi本身支持Spark On Yarn 和Spark On k8s兩種Spark調(diào)度模式。用戶遷移到了Kyuubi之后，無(wú)需再二次遷移。用戶可以自由選擇Spark任務(wù)執(zhí)行的集群環(huán)境，比如任務(wù)a跑到y(tǒng)arn集群，任務(wù)b跑到kubernetes集群。整個(gè)切換非常絲滑，只需要修改一些配置。
這些都是對(duì)于案例痛點(diǎn)提出的解決方案。
2.5?案例發(fā)展史
?
下圖是Kyuubi項(xiàng)目的整個(gè)發(fā)展時(shí)間線或者進(jìn)度條。
圖 14?Kyuubi項(xiàng)目發(fā)展史
?
從上圖可以看到整個(gè)案例的發(fā)展史，按照時(shí)間進(jìn)度可以分為三個(gè)階段：
1)?第一階段：遷移原本跑在 Hive 上的 beeline 腳本到kyuubi。接下來(lái)只需在Kyuubi層面完成工作，整個(gè)過(guò)程雖然非常復(fù)雜，但是不會(huì)影響到用戶腳本里的代碼，從而減少遷移人員的工作量，要知道改歷史代碼是每個(gè)公司最不想面對(duì)的事情。
2)?第二階段：Spark On Yarn階段。遷移的首要目標(biāo)是考慮穩(wěn)定性，Kyuubi具有很高的SLA保證率。由于Spark On k8s技術(shù)對(duì)于Spark并不是特別成熟，而On Yarn已經(jīng)存在了5~6年或者更長(zhǎng)的時(shí)間，整個(gè)構(gòu)架和體系都是經(jīng)過(guò)考驗(yàn)，用戶會(huì)把關(guān)鍵性任務(wù)遷移到Spark On Yarn環(huán)境。在此基礎(chǔ)上才會(huì)考慮進(jìn)一步壓縮成本。比如：把一些非關(guān)鍵性或者有周期性的任務(wù)跑在k8s上。
3)?第三階段：接入Kyuubi之后一鍵上云。比如：用戶在第二次遷移到k8s的時(shí)候，就不需要再走一遍之前的過(guò)程，只需加一個(gè)配置去選擇需要的k8s環(huán)境，整個(gè)過(guò)程是非常簡(jiǎn)單。
在支持k8s之前，Kyuubi已基于minikube做集成測(cè)試，之后會(huì)繼續(xù)增加測(cè)試的覆蓋率，包括增加TPCDS在k8s環(huán)境的測(cè)試。Kyuubi On k8s可以進(jìn)一步展示Kyuubi服務(wù)端所占用資源的情況，可以幫助用戶更加靈活、更加彈性的部署Kyuubi。
2.6?案例成果分析
下面講一個(gè)遷移項(xiàng)目帶來(lái)收益的案例。
圖 15項(xiàng)目遷移到Kyuubi收益案例
?
這個(gè)項(xiàng)目大概持續(xù)了3個(gè)多月，時(shí)間不算長(zhǎng)。目前大部分任務(wù)都已經(jīng)遷移到了k8s環(huán)境上，整個(gè)任務(wù)規(guī)模數(shù)量在2000任務(wù)，整體大概有70%的性能提升，就是之前用100秒跑的任務(wù)，現(xiàn)在任務(wù)只要跑30秒，個(gè)別任務(wù)可能更夸張。因?yàn)檫@個(gè)性能提升70%是平均的性能提升。
最后一點(diǎn)是資源節(jié)省，也是用戶非常關(guān)心的特點(diǎn)。在性能提升70%的同時(shí)，通過(guò)控制CPU和內(nèi)存的資源成本線，整個(gè)資源可以節(jié)省50%，可幫助用戶獲得更多的成果。
?
本次分享到此結(jié)束。
答疑
問(wèn)題1：大家熟悉的Spark計(jì)算框架在運(yùn)行Spark任務(wù)時(shí)，對(duì)小文件控制的不好。Kyuubi自帶小文件問(wèn)題解決方案，在運(yùn)行任務(wù)的過(guò)程中，會(huì)對(duì)小文件進(jìn)行合并。請(qǐng)具體講一下Kyuubi采取了如何實(shí)現(xiàn)小文件的合并？
答：小文件合并是Spark的老大難的問(wèn)題。從Spark流行開始一直有小文件問(wèn)題，而且Spark可以非常輕易的產(chǎn)生小文件。比如：在動(dòng)態(tài)分析插入的場(chǎng)景中，小文件的產(chǎn)生量用指數(shù)級(jí)的爆炸來(lái)描述也不過(guò)分。
1) Kyuubi對(duì)于動(dòng)態(tài)場(chǎng)景做了一個(gè)小文件自動(dòng)合并的方案，這個(gè)方案解決兩個(gè)問(wèn)題：一個(gè)問(wèn)題是靜態(tài)分區(qū)插入，另一個(gè)是動(dòng)態(tài)分區(qū)插入。對(duì)于靜態(tài)分區(qū)插入，整個(gè)過(guò)程比較簡(jiǎn)單，直接在最后的stage后面，追加一個(gè)額外的Shuffle stage。
2)?上面也提到過(guò)Kyuubi的插件、還有另外的一些功能，比如：stage粒度的配置隔離。在配置隔離的基礎(chǔ)上，新增的Shuffle就可以靈活地控制每個(gè)分區(qū)的處理能力（處理的數(shù)據(jù)量）。比如：每個(gè)分區(qū)可以處理200或者500多兆的數(shù)據(jù)量，這個(gè)數(shù)據(jù)量和最終產(chǎn)生的文件大小是相關(guān)的。如果增加配置或增加了某個(gè)分區(qū)的數(shù)據(jù)處理量，也就增加了產(chǎn)生的最終文件的大小。
3)?另一個(gè)解決方案是動(dòng)態(tài)分區(qū)插入，稍微復(fù)雜一點(diǎn)。它的分區(qū)是在計(jì)算完成之后，才會(huì)感知到想生成哪些分區(qū)、在哪些分區(qū)上產(chǎn)生了哪些文件。Kyuubi對(duì)于這樣的場(chǎng)景，額外增加一個(gè)對(duì)于分區(qū)字段的Shuffle，也就是先對(duì)分析字段做Hash，然后把相同分區(qū)值分布到同一部分之內(nèi)，從而保證不會(huì)過(guò)多。
4)?在這個(gè)基礎(chǔ)上，Kyuubi提供了一些額外的配置，比如：動(dòng)態(tài)分區(qū)會(huì)產(chǎn)生數(shù)據(jù)傾斜的隱患。Kyuubi提供一些配置緩解這樣的問(wèn)題。比如：每一個(gè)分區(qū)可以指定產(chǎn)生的文件數(shù)，來(lái)解決數(shù)據(jù)信息的問(wèn)題。另外 Kyuubi 社區(qū)的一些技術(shù)同學(xué)也積極給Spark社區(qū)提新的特性-rebalance。所以在Spark3.2.0之后會(huì)有新的解決方法，帶給我們更優(yōu)秀的小文件合并能力。
?
問(wèn)題2：在Kyuubi使用過(guò)程中，涉及到腳本外部傳參， Kyuubi后續(xù)規(guī)劃里面有沒(méi)有針對(duì)腳本傳參的規(guī)劃。
答：腳本傳參的場(chǎng)景，第一個(gè)是參數(shù)， Spark的參數(shù)有靜態(tài)和動(dòng)態(tài)。靜態(tài)的參數(shù)是非SQL類參數(shù)，比如：資源配置，內(nèi)存、CPU之類的配置是靜態(tài)的，不允許在使用過(guò)程中動(dòng)態(tài)修改。動(dòng)態(tài)的參數(shù)是可以動(dòng)態(tài)修改。比如：SQL的配置、Shuffle的分區(qū)數(shù)。對(duì)于靜態(tài)的配置，在Kyuubi端也是無(wú)法修改，因?yàn)镵yuubi和Spark是一樣流程。
對(duì)于這部分內(nèi)容，Kyuubi之后可能會(huì)提供更細(xì)粒度的引擎實(shí)現(xiàn)，做到動(dòng)態(tài)的、資源修改的解決方案，可以對(duì)比當(dāng)前的引擎實(shí)例和期望的引擎實(shí)例的資源配置；如果不滿足可以做一些其他判斷。比如：創(chuàng)建一個(gè)額外的引擎、或替換當(dāng)前的引擎都有可能。不過(guò)目前來(lái)說(shuō)這些都還只是設(shè)想，沒(méi)有實(shí)際的方案。如果你有一些其他想法或思路，也可以來(lái)社區(qū)提出更明細(xì)的問(wèn)題，可能跟開發(fā)聊這些事情會(huì)更方便，然后可以討論出更好的解決方案。
?
問(wèn)題3：HUE能跟Kyuubi集成嗎？
答：可以。Kyuubi的官方文檔就提供了HUE的quick start，這些文檔可以教你如何一步一步的把HUE接入到Kyuubi。
?
問(wèn)題4：高并發(fā)下Kyuubi的Server端壓力大不大？
答：確實(shí)會(huì)有壓力，但這個(gè)壓力和整個(gè)的調(diào)度模式有關(guān)，比如：用Spark On Client模式去調(diào)度， Server端的壓力就會(huì)自然增長(zhǎng)，原因是Spark ?Driver進(jìn)程會(huì)一直跑在Server端。如果用其他的調(diào)度模式Server端的壓力會(huì)降低。
?
問(wèn)題5：負(fù)載均衡池如何做到負(fù)載均衡？
答：負(fù)載均衡池是依賴于Hive Client，基于Zookeeper可以獲取Kyuubi的所有實(shí)例，然后進(jìn)行隨機(jī)選取，然后做到負(fù)載均衡。
之后會(huì)推進(jìn)Kyuubi自己的Client，在這個(gè)基礎(chǔ)上，就可以更加靈活的控制、如何選擇更合適的Kyuubi Server。
目前還是依賴于Hive Client端的負(fù)載均衡方式。
?
問(wèn)題6：請(qǐng)簡(jiǎn)單總結(jié)一下Kyuubi在性能優(yōu)化的方式。
答：性能優(yōu)化很寬泛，需要通過(guò)一系列的手段影響產(chǎn)生性能優(yōu)化的結(jié)果。比較大的影響因素包括：Kyuubi提供了一個(gè)會(huì)話緩存或者說(shuō)引擎快速啟動(dòng)特性，幫助用戶最大可能減少在引擎啟動(dòng)的調(diào)度耗時(shí)；資源釋放或者資源申請(qǐng)的時(shí)間；提供插件，比如：提供了Spark插件，帶來(lái)SQL層面上的優(yōu)化。
?
問(wèn)題7：Kyuubi從架構(gòu)上跟Hive Server2的架構(gòu)基本完全一致。從語(yǔ)法層面Hive SQL的語(yǔ)法能與Spark SQL的語(yǔ)法完全能兼容嗎？有沒(méi)有細(xì)節(jié)方面之類的差異？
答：肯定會(huì)有，因?yàn)镠ive ?SQL有很多自己的方言；Spark SQL對(duì)應(yīng)的也有自己的方言。在大部分場(chǎng)景或者99%的case基本上都是兼容的。
Kyuubi在遷移的過(guò)程中，也遇到過(guò)不兼容的場(chǎng)景。Hive ?SQL的一些語(yǔ)法，在Spark SQL得不到承認(rèn)。這些是一些比較細(xì)微的、或者跟性能沒(méi)有關(guān)系的一些語(yǔ)法。只要能把整個(gè)Query語(yǔ)法解釋一遍，或者說(shuō)分析一遍就可以了。這個(gè)過(guò)程是非?？斓?。
?
問(wèn)題8：關(guān)于Kyuubi生產(chǎn)部署環(huán)境的案例。
答：Kyuubi在整個(gè)網(wǎng)易內(nèi)部的很多Spark查詢已經(jīng)很廣泛，整個(gè)Kyuubi項(xiàng)目在網(wǎng)易有數(shù)對(duì)外的商業(yè)化版本里面。整個(gè)Kyuubi的生產(chǎn)環(huán)境有很多，商業(yè)化項(xiàng)目也有好幾百個(gè)，也都會(huì)默認(rèn)帶上Kyuubi。
網(wǎng)易內(nèi)部是一個(gè)很重要場(chǎng)景，每天有幾十萬(wàn)的任務(wù)量，在內(nèi)部、外部都有很好的落地的應(yīng)用。可以關(guān)注Kyuubi公眾號(hào)和微信群進(jìn)行更多的交流。
?
問(wèn)題9：Kyuubi和Spark SQL有什么區(qū)別？
答：Kyuubi使用了Spark SQL作為底層的執(zhí)行引擎。橫向的對(duì)比對(duì)象是Spark Thrift Server。對(duì)比SQL引擎管理、整個(gè)數(shù)據(jù)鏈路、或者整個(gè)查詢生命周期的維護(hù)，Kyuubi會(huì)提供更多諸如：HA、緩存、插件機(jī)制，這些Spark SQL都是不支持的。Kyuubi是強(qiáng)依賴于Spark SQL的性能，Kyuubi的計(jì)算引擎還是Spark SQL。
這兩個(gè)內(nèi)容不在同一層面上，難以進(jìn)行對(duì)比。Kyuubi是在Spark SQL的上面做了很多諸如：隔離等工作，而SparkSQL本身是不涉及這些內(nèi)容的。
分享嘉賓：尤夕多?網(wǎng)易資深大數(shù)據(jù)開發(fā)工程師，目前就職于網(wǎng)易數(shù)帆有數(shù)產(chǎn)品線，專注于開源大數(shù)據(jù)領(lǐng)域，Apache Kyuubi (Incubating) Committer & PPMC / Apache Spark Contributor。