基於Impala的高效能數倉建設實踐之虛擬數倉

語言: CN / TW / HK

導讀:

本文主要介紹網易數帆NDH在Impala上實現的虛擬數倉特性,包括資源分組、水平擴充套件、混合分組和分時複用等功能,可以靈活配置叢集資源、均衡節點負載、提高查詢併發,並充分利用節點資源。

對於高效能分析型數倉,除了需要有優秀的執行引擎能夠讓查詢儘快完成外,還需避免因為查詢間的相互干擾導致查詢效能下降的問題,比如對計算和IO資源的競爭等。上節提到Impala可以通過資源池來進行計算資源的管理。但在使用時發現光有資源池還不夠,仍然會出現不同的資源池競爭同一個計算節點上記憶體資源等問題。

1基本概念

“虛擬數倉”來源於Snowflake的“virtual warehouse”,簡稱VW。虛擬數倉能夠按需進行水平和垂直擴縮容,是一種高效的資源排程方法,是存算分離設計架構下,計算資源彈性伸縮非常好的驗證案例。如下圖所示,該Snowflake叢集有兩個虛擬數倉,分別服務於BI和ETL使用者。其中BI虛擬數倉為了應對報表查詢的高低峰,採用了單元化的水平擴縮容模式,ETL主要關注計算能力,採用了改變虛擬數倉規格的模式。

 

NDH的Impala元件也具備類似的能力,在開始之前,先結合Impala的實際來介紹兩個基本概念,首先是社群版Impala已有的executor group(執行組)。然後是為支援虛擬數倉而引入的node group(節點組)概念。

Executor group

下圖是CDP文件中關於Impala執行組的示意圖,執行組是Impala進行彈性伸縮的基本單位,使用者可以配置執行組規格(XSMALL, SMALL, MEDIUM, or LARGE)。若啟用自動伸縮,則CDP每次會按指定的規格擴充套件或縮小Impala的executor節點個數。

 

執行組為Impala叢集提供了水平擴縮容的能力。但與Snowflake所述的虛擬數倉還是有不小的區別,從目前的介紹看,執行組是對使用者透明的概念,使用者無法通過執行組將Impala叢集劃分為不同用途的計算單元,如前述的用於BI和ETL。因此,NDH Impala引入了node group(節點組)的概念。

Node group

NDH Impala叢集的impalad節點可以被劃分成多個獨立分組,我們稱之為節點組。節點組可以僅有executor組成,也可以有coordinator節點。

 

上圖Impala叢集包含3個節點組,每個節點組的impalad中必須至少有一個executor節點。此外還有2個coordinator節點獨立於節點組之外。獨立的coordinator節點可以將請求路由到任一節點組中的executor,節點組中的coordinator只能將請求分發給本分組內的executor節點執行。根據查詢路由規則的差異,有兩種虛擬數倉實現方式。

2實現方式

NDH Impala支援兩個虛擬數倉實現,分別是基於zookeeper地址的靜態配置方案和基於會話(session)引數的動態配置方案,下面分別展開介紹。

2.1 靜態配置

該方案將不同節點組的coordinator節點註冊到不同的zookeeper地址上,Hive JDBC客戶端連線不同的zookeeper地址即可獲取到不同業務組的coordinator,從而進行連線並下發SQL請求。此種方式中每個節點組都會擁有自己獨有的一到多個coordinator節點,負責將SQL生成的執行計劃下發給組內的executor節點執行。

 

上圖所示叢集有3個虛擬數倉:group 1,group 2和group 3。它們共用相同的statestored和catalogd,共用同一份數倉元資料。虛擬數倉間的impalad資源是物理隔離的,某個虛擬數倉的coordinator節點只會將查詢下發到組內的executor節點。在生產環境中,可通過配置多個虛擬數倉來接收不同型別業務的查詢請求,以便不同業務的查詢在計算資源的使用上互相隔離,互不影響,圖中group 1用於進行ad-hoc查詢,group 2用於有數BI報表,group 3用於有數BI自助取數。相比多叢集方式,多虛擬數倉的方式所需要資源更少,配置更靈活。

2.2 動態路由

本方案在會話連線中增加一個query option引數request_group,通過set request_group=xxx語句,coordinator會自動將查詢路由到指定分組上執行。request_group預設為default,對應group_name的預設值也為default。換言之,若不指定request_group,那麼查詢會下發到預設的default分組執行。

在本方案中coordinator節點是公共的,僅對executor節點進行分組,在實現上更類似Snowflake的虛擬數倉。如下圖所示,有2個公共的coordinator,3個分組,由於不存在default分組,可將預設分組配置為grp1。可以通過引數動態配置,相比基於zookeeper的方案更加靈活,使用者能夠根據需要自由地將查詢在不同的虛擬數倉上切換。

上述兩種方案均已實現,由於NDH的生產環境一般通過Hive JDBC連線zookeeper來訪問Impala,前者的使用方法相容性更好,目前線上主要使用以該方式部署虛擬數倉。本小節接下來介紹的虛擬數倉進階特性也主要圍繞前者展開。

3主要特性

3.1 水平擴充套件

若虛擬數倉的單個節點組資源和併發數已經達到瓶頸,單純在組內增加節點無法有效提升查詢併發數,此時可以新增一個規格相同或相近的節點組加入該虛擬數倉中,需將新節點組中coordinator的zookeeper地址配置成與原節點組相同。藉助Hive JDBC在選擇zookeeper下coordinator地址時的隨機性特點,可將查詢負載均衡到新舊節點組上。這種方式可以接近線性地提升叢集的查詢併發數。

 

上圖所示Impala叢集有2個虛擬數倉,對應的節點組分別為group1和group3,承接的業務分別是業務的有數BI報表和ABTest場景。假設group1為原分組,有3個impalad節點(1個coordinator,2個executor)。新增分組group2,也是3個impalad節點,使用與group1相同的配置,即可起到水平擴充套件的效果。

3.2 透明伸縮

NDH Impala可根據各虛擬數倉的負載情況,線上增加或減少虛擬數倉節點組中的impalad節點數,從而實現分組間的資源動態伸縮。通過Impala提供的graceful shutdown方式下線節點組中impalad程序時,會先禁止新的查詢請求傳送到該impalad節點上,並等待其上正在執行的查詢片段(fragment)完成後再關閉。因此不會導致其上正在執行的查詢異常終止,做到對使用者無感。在生產環境中,配置了多個虛擬數倉的NDH Impala叢集,可通過分析歷史查詢規律並結合分組中impalad節點的系統負載情況,在虛擬數倉間動態增減節點數,以求更充分得利用各節點資源。

 

舉網易雲音樂為例,有數BI自助取數(easyfetch)的查詢一般發生在工作時間,有數BI報表需要在使用者上班前進行大量報表結果預載入操作(提前下發報表查詢SQL並快取查詢結果從而提升報表檢視體驗)。我們可將easyfetch和BI報表兩種場景配置為同一個NDH Impala叢集的兩個虛擬數倉,在上班前,將easyfetch虛擬數倉的大部分impalad節點挪到BI報表虛擬數倉上,這樣可以大大提高報表的預載入效率。

當然,透明伸縮不僅僅適用在虛擬數倉之間。對於雲上環境,通過k8s或類似排程機制,在負載高峰時可以便捷地申請容器或虛擬機器資源,快速補充到線上。待高峰過後,再將所增加的資源釋放給雲廠商。

4進階功能

相比Impala資源佇列,虛擬數倉的節點組中coordinator節點絕對不會使用到其他組的計算資源(executor),資源隔離更加徹底,使得不同業務模組的查詢效能不會相互影響。但不同虛擬數倉所屬的業務會存在負載差異,可能導致資源利用不充分。為了提高空閒節點組的資源利用率,對虛擬數倉特性做了進一步增強,引入混合分組、分時複用等功能。

4.1 混合分組

混合分組就是讓一個executor節點同時在2個或以上的節點組中,如下圖所示。左子圖為普通模式,假設NDH Impala叢集分為有數BI報表和Ad-Hoc查詢2個虛擬數倉,Ad-Hoc查詢有明顯的時間性,查詢集中在工作時間,且查詢的併發度較低。通過混合分組,可將虛擬數倉部署方式改造為右子圖的模式。

 

圖中,n1~n2為group1節點組coordinator節點,其會註冊到zookeeper路徑youdata上,Hive JDBC客戶端從該路徑獲取任意coordinator節點向其提交查詢,coordinator將查詢進行解析,優化並指定分散式執行計劃,最終下發給n3~n7執行。n6~n7同時還是group4的executor節點,group4的coordinator為n8~n9,其會接收從zookeeper路徑Ad-Hoc進入的查詢,指定分散式執行計劃,並會發送到n6~n8上。

4.2 分時複用

分時複用是另一個能夠提高資源利用率的進階功能。通過在特定的時間段自動配置叢集的分組資源,緩解某些高負載分組的查詢壓力,提升使用者體驗。

 

在實現上,支援將同一個coordinator註冊到多個zookeeper地址下,且可以配置註冊到每個地址的有效時間,如上圖所示,可以每天晚上八點到早上八點將Ad-Hoc虛擬數倉的n8和n9兩個coordinator(或其中一個)註冊到BI報表虛擬數倉相同的zookeeper地址下,分攤BI報表的查詢負載。

與混合分組相比,分時複用功能僅適合在規格相似的節點組之間使用,確保不同分組上的查詢效能沒有明顯的差距。

4.3 基於負載的節點選擇

executor節點會出現多種原因導致計算資源使用不均衡的問題,比如資料傾斜導致某些executor節點需要消耗更多計算資源掃描和處理資料,或引入混合分組特性導致某些節點組上節點負載過高等等。

針對該問題,NDH Impala進行了兩個優化。第一個是支援基於executor節點負載的查詢分散式執行,實現方法為在為查詢SQL確定分散式執行計劃時,考慮executor節點當前可用的計算資源情況,剔除可用資源較少的executor節點;第二個是存在多佇列時,限制同個佇列上的查詢請求在一個executor上的資源使用總量,避免executor資源被某個佇列獨佔。

5小結

本小節主要介紹了虛擬數倉概念的來源和實現,重點分析了NDH Impala在虛擬數倉這塊的探索、思考和使用。目前虛擬數倉在網易網際網路業務以及網易數帆的商業化客戶叢集上均有成功的應用案例。

筆者認為,虛擬數倉應該是新一代分析性數倉必備的一個能力,它能夠剝離複雜多樣的業務負載,充分發揮執行引擎自身的能力。最後需要指出的是,虛擬數倉是一種雲原生的特性,計算資源能夠靈活伸縮的環境能夠最大化其價值。

 

作者簡介

榮廷,網易數帆資料庫技術專家,10年+資料庫相關工作經驗,目前主要負責高效能數倉和雲原生資料庫研發工作。