Apache Kyuubi 在網易的深度實踐

語言: CN / TW / HK
分享的內容主要包括三個內容:
1) Apache Kyuubi (Incubating) (以下簡稱Kyuubi)是什麼?介紹Kyuubi的核心功能以及Kyuubi在各個使用場景中的解決方案;
2) Kyuubi在網易內部的定位、角色和實際使用場景;
3) 通過案例分享Kyuubi在實際過程中如何起到作用。

Kyuubi是什麼

開源Kyuubi是網易秉持開源理念的作品。Kyuubi是網易第一款貢獻給Apache並進入孵化的開源專案。Kyuubi主要應用在大資料領域場景,包括大資料離線計算、資料倉庫、Ad Hoc等方向。通過Kyuubi進入Apache的自我描述,可以知道Kyuubi是一個分散式、支援多使用者、相容DBC或ODBC的大資料處理服務。Kyuubi採用了Apache Spark作為計算引擎,並帶來了很好的效能收益。Kyuubi未來也可能會支援其他的類似執行引擎,比如:Apache Flink。Kyuubi在2018年由網易開源到Github, 2021年成功進入Apache進行孵化,現在是處於孵化階段。

1.1 關鍵字

  • 開源:開源把整個專案帶到了社群,在社群中的其它公司或技術開發人員,也會為Kyuubi帶來新穎的想法,從而使Kyuubi可以發展得越來越好;
  • 多租戶:作為一款企業級服務,多租戶是不可缺少的功能,同時需要保證資料的安全性;
  • 相容Hive JDBC:Hive是各大公司主流、常用的大資料處理引擎。相容Hive JDBC可以很輕易幫助Hive使用者無縫遷移到Kyuubi;
  • Spark計算引擎:目前業界公認的、效能最好的、最流行的大資料計算引擎。因此Kyuubi的第一款內建計算引擎也選用Spark計算引擎;
  • 大規模資料處理能力,需求分成兩種情況:
    • 第一種情況是資料量的規模。比如:SQL查詢,可能需要處理的資料量是GB或者TB級別的龐大規模,這就需要大規模資料處理能力來處理這種規模的資料;
    • 第二種情況是併發查詢的規模。當任務非常多,每天會有幾萬個或者幾十萬個SQL查詢任務在Kyuubi 上執行時,就需要有一個足夠強大的處理能力,保證服務端可以及時響應使用者的請求。
  • 開箱即用:Kyuubi的務實、親民設計理念,追求讓使用者以最低的成本、獲取最好的效果。

1.2 主流查詢引擎對比

1.2主流查詢引擎一覽表

與目前主流的SQL大資料計算引擎進行對比,Kyuubi有著自己獨特的優勢:

  • 對外介面:都是基於Hive JDBC,如果使用Hive Server2遷移到Kyuubi時,整個切換是無縫、自然的使用Kyuubi;
  • 計算引擎:由計算引擎相關經驗可以知道,Hive Server2基於MapRedeuce;Spark Thrift Server基於Spark,Kyuubi同樣採用Spark計算引擎;
  • 多版本能力:Kyuubi在Spark基礎上,具備提供多版本Spark的能力。在歷史的迭代或產品的升級中,都會存在歷史版本在測試和生產環境中,因此支援多版本的能力也非常重要;
  • SQL解析優化:簡單看就是毫秒級別或者是秒級別的優勢,其實還有很多對映關係。比如Spark查一張表,需要Hive的全域性鎖,或者需要Hive全域性鎖控制整個的請求過程。在這個基礎上,如果有多個使用者同時去查詢,可能會出現阻塞或者單點瓶頸的問題。Kyuubi可以把整個流程下推到引擎上,保證服務端可以及時的、快速的響應使用者的請求,並且可以保持使用者之間的引擎完全隔離;
  • 多租戶:是企業級應用系統的基本功能,Kyuubi同時支援並保證多租戶的資料安全性;
  • 動態資源配置:Hive的SQL基於MapReduce;Spark Thrift Server的資源配置並不是很靈活,原因在於Spark是全域性單例項的方式,無論使用者多少,都只能擁有一套資源配置場景。而Kyuubi提供了基於引擎粒度的資源配置,幫助使用者實現任務間的快速隔離;
  • 高可用:是企業級SQL引擎的基本特性。Spark Thrift Server不具備這種能力;而Kyuubi提供了基於ZooKeeper的高可用解決方案,以支援高可用特性;
  • 併發查詢能力:Kyuubi在基於高可用特性的基礎上,可以輕鬆的在服務端進行橫向的水平擴充套件,以保證併發查詢能力,而Spark Thrift Server不支援併發查詢特性;
  • 雲原生:是近幾年比較熱門的話題,它可以幫助使用者把整個叢集進行混合部署,節省使用者的資源使用。Kyuubi也同樣支援以上雲原生場景;
  • 雲原生整合測試:在雲原生的基礎上,Kyuubi提供了與雲原生相關的整合測試。Kyuubi是基於Minikube元件實現整合測試,這一環節在很多主流的技術元件中被忽視。通過完整的整合測試流程和高測試覆蓋率,可以極大的降低使用者在工作環境中出現bug的可能性。

1.3 Kyuubi的架構

Kyuubi的架構請看下面的具體的架構圖。從左到右整張架構圖可以分成三個部分:

kyuubi的架構示意圖

1) 客戶端:是使用者可以接觸到的部分。比如:Hive Beeline、JDBC或ODBC介面,在內部,網易有數也是以客戶端的角色連線到 Kyuubi;

2) Kyuubi服務端:通過和客戶端建立一些會話(KyuubiSession),會話最終被路由到實際的執行引擎。

3) 實際執行引擎:會話路由的過程比較靈活,甚至可以由使用者自定義。在這張架構圖展現的案例就是使用者A使用者B共享引擎,即使用了同一個引擎;而使用者C用了另一個引擎。在這個場景下,使用者的整個引擎資源實現了隔離,並且引擎之間也可以部署在不同級資源管理叢集,比如:支援Spark On Yarn或者Spark On Kubernetes。在這種很靈活的配置環境下,使用者可以輕鬆的、讓自己的任務跑在任意叢集。這些都是Kyuubi架構的優勢。

Kyuubi在網易的應用

Kyuubi在網易的應用包括兩方面:

1) 使用者畫像:有哪些人、哪些團隊使用Kyuubi大資料引擎元件;

2) 業務場景:Kyuubi的使用場景和業務場景,以及對應不同業務場景的解決方案。

2.1 使用者畫像

Kyuubi使用者可以分成三個大類:

Kyuubi 使用者畫像

1) 數倉團隊:數倉團隊又細分成三種:

• 傳統數倉團隊,使用MySql或Oracle做資料分析,沒有大資料、大資料引擎的處理能力,不知道SQL查詢在計算引擎上的整個執行過程,只知道資料的結果;

• 有一些Hive或者Spark的使用經驗,部分了解配置優化;

• 關注效能和成本,不接受任務跑得很快,但佔用很多資源的情況。

2) BI團隊:專注於面向業務開發,工作時間相對集中在工作日的白天,對成本不敏感,更關注 SQL 查詢的執行效能;

3) Spark團隊:Kyuubi重度使用者。Spark團隊有三個方面的任務:

• 日常管理Spark版本。不同於社群,網易內部有很多Spark分支,每個月或者定期會發布修復Bug的Spark版本、或增加新功能;

• 進行外掛管理。由於Spark外掛多種多樣,比如:SQL的外掛可以優化SQL;許可權控制外掛,幫助使用者做資料脫敏加密;

• 完成配置管理。當客戶端分佈在各個節點的時候,維護配置比較困難;而Kyuubi面對這樣的場景,可以統一在服務端實現維護,整個過程很簡捷。

2.2 業務場景

在Kyuubi的使用過程可以分成四個大類:

1) 海量任務;

2) 複雜環境;

3) 複雜任務;

4) 多入口。

業務場景一覽

2.2.1 海量任務

由於網易內部的團隊和業務部門很多,Kyuubi的任務數量也非常多,每天有幾萬或幾十萬個SQL任務,高峰期每秒鐘都會有很多Kyuubi請求任務。

2.2.2 複雜任務

任務複雜程度也需要考慮,由於Kyuubi的使用者人群很多,如上所述有:數倉、BI或者其他的開發人員,其任務的複雜度也各不相同。比如:數倉任務如果是細資料,需要做簡單的清洗類似ETL型別,屬於IO密集型任務;如果是一個輕量聚合或者彙總層的任務,整個過程比較簡捷,屬於CPU密集型任務。這些場景在Kyuubi上的任務是非常複雜的。

2.2.3 複雜環境

• 多叢集混合管理能力

由於支援on Yarn或者on Kubernetes,有些使用者需求出於穩定性或成本的考慮,提出Query的部分SQL分別跑在on Yarn或on Kubernetes上,Kyuubi具備支撐這種多叢集混合管理的能力。

• 多版本能力

能夠管理多個Spark版本,以及Spark依賴不同版本的Hive,整個環境非常複雜。

2.2.4 多入口

由於網易有數的很多產品線接入了Kyuubi,比如:BI或者AI的平臺;網易在做的自助分析和離線開發的SQL任務,也已經接入了Kyuubi。Kyuubi需要控制和維護這麼多入口,有相當的壓力。

下面分別分析不同場景下Kyuubi的實際解決方案和使用經驗。

2.3 業務場景 – 資料倉庫

資料倉庫業務場景

在數倉類離線任務的使用場景下,有三個核心痛點:

1) SQL任務繫結使用者許可權。就是需要資料隔離或資料讀寫的安全性以保證資料的安全。

在這個背景下,Kyuubi支援kerberos多租戶的認證,同時支援:

• 使用者代理模式;

• keytab的認證方式,通過靈活的配置就可以滿足使用者在不同業務場景下的需求疊加。

2) SQL任務數量大,排程集中。比如數倉任務大部分都在凌晨一兩點的時候任務提交啟動。在這個場景下,Kyuubi提供:

• HA能力,保證服務的高用性和SLA指標;

• 提供服務端水平擴充套件,業務線可以部署兩臺或以上Kyuubi服務,保證每個Kyuubi負載均勻,確保能夠快速響應使用者的請求。

3) 效能參差不齊。考慮到歷史任務不可能把每個任務都已經跑到目標效能,有些任務連一些常見Spark配置都沒有改,或者SQL本身也不規範。在這個事實基礎上,Kyuubi提供了標準化SQL外掛、來標準化SQL任務。由於SQL指令碼數量非常巨大,成千上萬的又不可能讓使用者逐個去修改,標準化SQL任務的方式就會非常有效果。

Kyuubi提供了集中式SQL任務的標準化,其中最核心的兩個功能是:

• 提高任務的效能下限,任務效能再差,也比上Kyuubi之前的效能要好;

• 統一解決小檔案問題。小檔案問題是一個老生常談的問題,不同的公司會有不同的解決方案。Kyuubi提供的統一解小檔案問題方案,可以極大減輕整個叢集的儲存壓力,保證了每個任務的瓶頸產生檔案都是期望大小,比如200MB以上。

2.4 業務場景 – Ad hoc

Ad hoc業務場景

Ad hoc業務場景是BI團隊會遇到的場景,Ad hoc場景中遇到的痛點和方案如下:

1) SQL任務效能敏感。快速響應的任務,以秒為單位進行計時,如果超過指定時長,就會直接放棄這個任務結果。在這種需求下,Kyuubi提供了引擎共享能力:

• 會話熱啟動:當用戶建立會話時,Kyuubi的計算指令引擎已經處於活躍狀態,比如:和 Hive Metastore 的連線已經連線成功,整個的Spark機制都已經運轉起來,無需再處理這些過程。整個Query會非常快,極大減輕了整個SQL啟動時間。比如:SQL本身執行需要十幾秒,整個任務的起效時間大概需要十秒,甚至由於資源管理器不一樣、或者Kubernetes出現資源挑戰,都可能需要幾十秒的時間,整個過程非常緩慢。Kyuubi提供的會話熱啟動的能力,相當於把每一個SQL Query的查詢時間提升50%或者100%,使得效能有明顯的提升。

• 引擎池:目前在Kyuubi社群還在討論如何進一步開發。核心目標就是為了解決:當某些使用者的SQL吞吐量非常大,單個引擎實力滿足不了需求時,需要多個引擎同時線上提供服務。在這種場景下,Kyuubi通過引擎池,配套負載均衡或者類似Round-Robin這種隨機引擎選擇策略,使用者就可以優雅地增加查詢能力。

2) SQL任務幾乎都在白天跑。常見的SQL任務的工作時間是九點到下午十七點,在這段時間使用頻率很高;在晚上整個叢集就基本上都處於閒置狀態。Kyuubi在這個場景下可以支援雲原生能力,幫助使用者把Ad hoc任務或者Ad hoc的Kyuubi叢集、以及背後的引擎資源,全部可以部署到Kubernetes上,讓整個處於閒置狀態下的資源充分利用起來,避免出現浪費,從而降低使用者的資源成本。

3) SQL任務更加註重資料查詢。資料查詢相對於資料寫入場景的場景來說,SQL Query的結果數量可能很少,只有幾條或十幾條資料肉眼可見的資料規模。在這種場景下,可以把整個計算引擎的配置都標準化為優先併發的配置,即不考慮小檔案問題。此時不存在小檔案,就可以把整個分割槽或者分割槽處理的檔案大小,控制在諸如32兆或者16兆更小的資料規模,從而保證整個SQL Query的高效能。此外還提供了配置模板的特性方案,主要功能是把整個SQL任務進行分類。比如:資料查詢是一大類,這個粒度比較粗,後面將針對使用者的任務,定義更細粒度的型別,並給出相應的配置模板。在不同配置模板下,就可以發揮出計算引擎強大的效能。比如:發揮Spark計算引擎的強大效能,從而幫助提升使用者的查詢效率,加快查詢速度。

2.5 業務場景 – 內部系統

在業務場景中會有難以描述的內部系統,具體也不清楚該系統是用來做什麼業務,或者有那些隱藏在背後的使用者。針對這樣的內部系統業務場景,其解決方案如下:

內部系統業務場景

1) 由於接入Kyuubi的門檻很低,使用者通過JDBC或者Hive Beeline就可以輕鬆接入Kyuubi,整個過程是很輕量級。對於已經接入Hive Server2的系統,Kyuubi完全相容Hive的介面,使用者任務的遷移週期非常短。對於開發者來說,Kyuubi把背後的引擎優化成Spark,提供了快取、外掛等,僅僅改一兩行程式碼就可以帶來很大的收益,可以讓使用者得到更好的效能效果。

2) 對於意料之外接入的系統,Kyuubi提供了整套全生命週期管理的配套措施。不管使用者建立了會話、通過會話建立的引擎例項,還是在引擎例項跑的SQL任務,Kyuubi對於各個層級、各個粒度資源,都做了生命管控。

例如:一個引擎例項已經閒置了十分鐘,Kyuubi就會主動釋放引擎資源,而不會再浪費整個叢集資源。通過這種方式可以降低歷史任務、或意料之外的任務浪費叢集資源,保證叢集的穩定性。

案例分析

以上講述了Kyuubi在網易內部的一些使用場景和相應的解決方案。最後分享一個具體案例,讓大家感受如何實際使用Kyuubi,以及Kyuubi發揮的價值。

3.1 案例痛點1:

1) 案例背景和矛盾:有使用者的任務跑在Hive on Yarn的場景,使用者想優化整個任務、或改Spark跑、或改到Kubernetes上做任務。

Hive on Yarn優化案例

2) 整個案例的痛點:Hive任務的自身優化空間比較小,加了幾個或十幾個配置之後,還沒有達到使用者的預期,使用者就切換背後的執行引擎到Spark。由於任務的整個執行時間上的規律、或執行時間分散,使用者想用Kubernetes進一步的降低成本。在推出Spark 3.0之後,推出了基於AQE的、基於執行中的資料計算資訊、優化每一個Stage的功能。使用者想用該功能,但是如果直接切到 Spark,整個過程非常通過。而採用Kyuubi將會讓整個遷移過程變得更加平滑

3.2 案例痛點2:

1) 案例背景和矛盾:由於歷史原因,每個公司或者每個團隊都有整個任務的排程體系。

古老指令碼的遷移案例

2) 整個案例的痛點:對於這個案例,之前的SQL指令碼大家都儲存在shell腳本里面,再通過一些Hive執行SQL指令碼,整個過程都是非常原始,沒有統一的管理系統。對於外部系統想接入或者想做更新和優化非常困難。

對於這個遷移性專案,給使用者帶來的收益可以看成是三部分內容:

• 遷移舊系統的代價;

• 舊系統的代價減去新系統的代價;

• 再減去遷移成本,這才是使用者最終得到的收益。

如果降低了使用者的遷移成本,保留了使用者的使用習慣之後,給使用者帶來的收益也是增加的。並且在使用者的舊任務遷移完成之後,使用者新任務的開發也有很大收益。因此 Kyuubi 選擇保留使用者的使用習慣。

3.3 案例痛點3:

1) 案例背景和矛盾:遷移週期和遷移效果的矛盾。

遷移週期與經營效果案例

2) 整個案例的痛點:整個遷移資料的SQL任務數會很多,比如:2000多的任務,每個任務也非常複雜;想要達到的效果目標很高,比如:每個任務平均效能提升40%,也就是之前100秒跑完的任務,現在想要40秒就能跑完,資源節省30%。這樣資源和效能是兩個矛盾點。

當資源充足的情況下,效能自然就能提升;但資源和效能都要提升,這在一定條件下是非常困難的。

3.4 案例痛點的解決方案:

根據前面Kyuubi的特性,Kyuubi針對以上三個痛點提出瞭解決方案:

案例痛點的解決方案

1) 完全相容Hive JDBC介面。使用者只需要改beeline的JDBC連線串就可以非常輕量、無縫的、平滑的切換到Kyuubi。在切換到Kyuubi之後,不管背後是Spark on Yarn或者Spark on Kubernetes,使用者都無需關心整個執行叢集或運營配置。只要跑在Kyuubi上,剩下工作的交給Kyuubi就可以。整個遷移的流程非常平滑,對使用者也非常簡單。

2) Kyuubi提供了AQE的線下增強外掛。在Spark社群分支的基礎上,Kyuubi提供了增強版AQE。同時Kyuubi專案組也向Spark社群提交了大約20多個AQE的補丁,對Spark進行了優化。

增強外掛的核心需求有兩個:

• 小檔案合併。把每一個SQL任務,標準化成帶小檔案合併的SQL任務,這樣就讓使用者的每個SQL任務、產出的檔案數保持一定規模。比如:每個任務產出平均檔案的大小都是200或500多兆,可以對齊HDFS 的 Block 大小,或者對齊更大的檔案需求。

• 基於Stage的配置隔離。Stage是Spark的一個概念,Spark對於每個shuffle切割Stage,Stage粒度的配置隔離,意味著可以對shuffle進行優化,向用戶提供更多優化的可能性,同時提高了任務的優化上限。

3) 支援混部叢集。Kyuubi本身支援Spark on Yarn 和Spark on K8s兩種Spark排程模式。使用者遷移到了Kyuubi之後,無需再二次遷移。使用者可以自由選擇Spark任務執行的叢集環境,比如任務a跑到Yarn叢集,任務b跑到Kubernetes叢集。整個切換非常絲滑,只需要修改一些配置。

這些都是對於案例痛點提出的解決方案。

3.5 案例發展史

下圖是Kyuubi專案的整個發展時間線或者進度條。

Kyuubi專案發展史

從上圖可以看到整個案例的發展史,按照時間進度可以分為三個階段:

1) 第一階段:遷移原本跑在 Hive 上的 beeline 指令碼到kyuubi。接下來只需在Kyuubi層面完成工作,整個過程雖然非常複雜,但是不會影響到使用者腳本里的程式碼,從而減少遷移人員的工作量,要知道改歷史程式碼是每個公司最不想面對的事情。

2) 第二階段:Spark on Yarn階段。遷移的首要目標是考慮穩定性,Kyuubi具有很高的SLA保證率。由於Spark on K8s技術對於Spark並不是特別成熟,而Oon Yarn已經存在了5~6年或者更長的時間,整個構架和體系都是經過考驗,使用者會把關鍵性任務遷移到Spark on Yarn環境。在此基礎上才會考慮進一步壓縮成本。比如:把一些非關鍵性或者有周期性的任務跑在K8s上。

3) 第三階段:接入Kyuubi之後一鍵上雲。比如:使用者在第二次遷移到K8s的時候,就不需要再走一遍之前的過程,只需加一個配置去選擇需要的K8s環境,整個過程是非常簡單。

在支援K8s之前,Kyuubi已基於minikube做整合測試,之後會繼續增加測試的覆蓋率,包括增加TPCDS在K8s環境的測試。Kyuubi on K8s可以進一步展示Kyuubi服務端所佔用資源的情況,可以幫助使用者更加靈活、更加彈性的部署Kyuubi。

3.6 案例成果分析

下面講一個遷移專案帶來收益的案例。

專案遷移到Kyuubi收益案例

這個專案大概持續了3個多月,時間不算長。目前大部分任務都已經遷移到了K8s環境上,整個任務規模數量在2000任務,整體大概有70%的效能提升,就是之前用100秒跑的任務,現在任務只要跑30秒,個別任務可能更誇張。因為這個效能提升70%是平均的效能提升。

最後一點是資源節省,也是使用者非常關心的特點。在效能提升70%的同時,通過控制CPU和記憶體的資源成本線,整個資源可以節省50%,可幫助使用者獲得更多的成果。

本次分享到此結束。

答疑

問題1:大家熟悉的Spark計算框架在執行Spark任務時,對小檔案控制的不好。Kyuubi自帶小檔案問題解決方案,在執行任務的過程中,會對小檔案進行合併。請具體講一下Kyuubi採取瞭如何實現小檔案的合併?

答:小檔案合併是Spark的老大難的問題。從Spark流行開始一直有小檔案問題,而且Spark可以非常輕易的產生小檔案。比如:在動態分析插入的場景中,小檔案的產生量用指數級的爆炸來描述也不過分。

1) Kyuubi對於動態場景做了一個小檔案自動合併的方案,這個方案解決兩個問題:一個問題是靜態分割槽插入,另一個是動態分割槽插入。對於靜態分割槽插入,整個過程比較簡單,直接在最後的stage後面,追加一個額外的Shuffle stage。

2) 上面也提到過Kyuubi的外掛、還有另外的一些功能,比如:stage粒度的配置隔離。在配置隔離的基礎上,新增的Shuffle就可以靈活地控制每個分割槽的處理能力(處理的資料量)。比如:每個分割槽可以處理200或者500多兆的資料量,這個資料量和最終產生的檔案大小是相關的。如果增加配置或增加了某個分割槽的資料處理量,也就增加了產生的最終檔案的大小。

3) 另一個解決方案是動態分割槽插入,稍微複雜一點。它的分割槽是在計算完成之後,才會感知到想生成哪些分割槽、在哪些分割槽上產生了哪些檔案。Kyuubi對於這樣的場景,額外增加一個對於分割槽欄位的Shuffle,也就是先對分析欄位做Hash,然後把相同分割槽值分佈到同一部分之內,從而保證不會過多。

4) 在這個基礎上,Kyuubi提供了一些額外的配置,比如:動態分割槽會產生資料傾斜的隱患。Kyuubi提供一些配置緩解這樣的問題。比如:每一個分割槽可以指定產生的檔案數,來解決資料資訊的問題。另外 Kyuubi 社群的一些技術同學也積極給Spark社群提新的特性-rebalance。所以在Spark3.2.0之後會有新的解決方法,帶給我們更優秀的小檔案合併能力。

問題2:在Kyuubi使用過程中,涉及到指令碼外部傳參, Kyuubi後續規劃裡面有沒有針對指令碼傳參的規劃。

答:指令碼傳參的場景,第一個是引數, Spark的引數有靜態和動態。靜態的引數是非SQL類引數,比如:資源配置,記憶體、CPU之類的配置是靜態的,不允許在使用過程中動態修改。動態的引數是可以動態修改。比如:SQL的配置、Shuffle的分割槽數。對於靜態的配置,在Kyuubi端也是無法修改,因為Kyuubi和Spark是一樣流程。

對於這部分內容,Kyuubi之後可能會提供更細粒度的引擎實現,做到動態的、資源修改的解決方案,可以對比當前的引擎例項和期望的引擎例項的資源配置;如果不滿足可以做一些其他判斷。比如:建立一個額外的引擎、或替換當前的引擎都有可能。不過目前來說這些都還只是設想,沒有實際的方案。如果你有一些其他想法或思路,也可以來社群提出更明細的問題,可能跟開發聊這些事情會更方便,然後可以討論出更好的解決方案。

問題3:HUE能跟Kyuubi整合嗎?

答:可以。Kyuubi的官方文件就提供了HUE的quick start,這些文件可以教你如何一步一步的把HUE接入到Kyuubi。

問題4:高併發下Kyuubi的Server端壓力大不大?

答:確實會有壓力,但這個壓力和整個的排程模式有關,比如:用Spark On Client模式去排程, Server端的壓力就會自然增長,原因是Spark Driver程序會一直跑在Server端。如果用其他的排程模式Server端的壓力會降低。

問題5:負載均衡池如何做到負載均衡?

答:負載均衡池是依賴於Hive Client,基於ZooKeeper可以獲取Kyuubi的所有例項,然後進行隨機選取,然後做到負載均衡。

之後會推進Kyuubi自己的Client,在這個基礎上,就可以更加靈活的控制、如何選擇更合適的Kyuubi Server。

目前還是依賴於Hive Client端的負載均衡方式。

問題6:請簡單總結一下Kyuubi在效能優化的方式。

答:效能優化很寬泛,需要通過一系列的手段影響產生效能優化的結果。比較大的影響因素包括:Kyuubi提供了一個會話快取或者說引擎快速啟動特性,幫助使用者最大可能減少在引擎啟動的排程耗時;資源釋放或者資源申請的時間;提供外掛,比如:提供了Spark外掛,帶來SQL層面上的優化。

問題7:Kyuubi從架構上跟Hive Server2的架構基本完全一致。從語法層面Hive SQL的語法能與Spark SQL的語法完全能相容嗎?有沒有細節方面之類的差異?

答:肯定會有,因為Hive SQL有很多自己的方言;Spark SQL對應的也有自己的方言。在大部分場景或者99%的case基本上都是相容的。

Kyuubi在遷移的過程中,也遇到過不相容的場景。Hive SQL的一些語法,在Spark SQL得不到承認。這些是一些比較細微的、或者跟效能沒有關係的一些語法。只要能把整個Query語法解釋一遍,或者說分析一遍就可以了。這個過程是非常快的。

問題8:關於Kyuubi生產部署環境的案例。

答:Kyuubi在整個網易內部的很多Spark查詢已經很廣泛,整個Kyuubi專案在網易有數對外的商業化版本里面。整個Kyuubi的生產環境有很多,商業化專案也有好幾百個,也都會預設帶上Kyuubi。

網易內部是一個很重要場景,每天有幾十萬的任務量,在內部、外部都有很好的落地的應用。可以關注Kyuubi公眾號和微信群進行更多的交流。

問題9:Kyuubi和Spark SQL有什麼區別?

答:Kyuubi使用了Spark SQL作為底層的執行引擎。橫向的對比物件是Spark Thrift Server。對比SQL引擎管理、整個資料鏈路、或者整個查詢生命週期的維護,Kyuubi會提供更多諸如:HA、快取、外掛機制,這些Spark SQL都是不支援的。Kyuubi是強依賴於Spark SQL的效能,Kyuubi的計算引擎還是Spark SQL。

這兩個內容不在同一層面上,難以進行對比。Kyuubi是在Spark SQL的上面做了很多諸如:隔離等工作,而SparkSQL本身是不涉及這些內容的。

 

分享嘉賓:尤夕多,網易資深大資料開發工程師,目前就職於網易數帆有數產品線,專注於開源大資料領域,Apache Kyuubi (Incubating) Committer & PPMC / Apache Spark Contributor。

編輯整理:曾新宇 對外經貿大學

來源:過往記憶大資料