??想了解更多關于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎軟件社區(qū)??

??https://ost.51cto.com??

本文主要介紹網(wǎng)易數(shù)帆NDH在Impala上實現(xiàn)的虛擬數(shù)倉特性，包括資源分組、水平擴展、混合分組和分時復用等功能，可以靈活配置集群資源、均衡節(jié)點負載、提高查詢并發(fā)，并充分利用節(jié)點資源。

對于高性能分析型數(shù)倉，除了需要有優(yōu)秀的執(zhí)行引擎能夠讓查詢盡快完成外，還需避免因為查詢間的相互干擾導致查詢性能下降的問題，比如對計算和IO資源的競爭等。上節(jié)提到Impala可以通過資源池來進行計算資源的管理。但在使用時發(fā)現(xiàn)光有資源池還不夠，仍然會出現(xiàn)不同的資源池競爭同一個計算節(jié)點上內(nèi)存資源等問題。

1、基本概念

“虛擬數(shù)倉”來源于Snowflake的“virtual warehouse”，簡稱VW。虛擬數(shù)倉能夠按需進行水平和垂直擴縮容，是一種高效的資源調(diào)度方法，是存算分離設計架構(gòu)下，計算資源彈性伸縮非常好的驗證案例。如下圖所示，該Snowflake集群有兩個虛擬數(shù)倉，分別服務于BI和ETL用戶。其中BI虛擬數(shù)倉為了應對報表查詢的高低峰，采用了單元化的水平擴縮容模式，ETL主要關注計算能力，采用了改變虛擬數(shù)倉規(guī)格的模式。

NDH的Impala組件也具備類似的能力，在開始之前，先結(jié)合Impala的實際來介紹兩個基本概念，首先是社區(qū)版Impala已有的executor group（執(zhí)行組）。然后是為支持虛擬數(shù)倉而引入的node group（節(jié)點組）概念。

Executor group

下圖是CDP文檔中關于Impala執(zhí)行組的示意圖，執(zhí)行組是Impala進行彈性伸縮的基本單位，用戶可以配置執(zhí)行組規(guī)格(XSMALL, SMALL, MEDIUM, or LARGE)。若啟用自動伸縮，則CDP每次會按指定的規(guī)格擴展或縮小Impala的executor節(jié)點個數(shù)。

執(zhí)行組為Impala集群提供了水平擴縮容的能力。但與Snowflake所述的虛擬數(shù)倉還是有不小的區(qū)別，從目前的介紹看，執(zhí)行組是對用戶透明的概念，用戶無法通過執(zhí)行組將Impala集群劃分為不同用途的計算單元，如前述的用于BI和ETL。因此，NDH Impala引入了node group（節(jié)點組）的概念。

Node group

NDH Impala集群的impalad節(jié)點可以被劃分成多個獨立分組，我們稱之為節(jié)點組。節(jié)點組可以僅有executor組成，也可以有coordinator節(jié)點。

上圖Impala集群包含3個節(jié)點組，每個節(jié)點組的impalad中必須至少有一個executor節(jié)點。此外還有2個coordinator節(jié)點獨立于節(jié)點組之外。獨立的coordinator節(jié)點可以將請求路由到任一節(jié)點組中的executor，節(jié)點組中的coordinator只能將請求分發(fā)給本分組內(nèi)的executor節(jié)點執(zhí)行。根據(jù)查詢路由規(guī)則的差異，有兩種虛擬數(shù)倉實現(xiàn)方式。

2、實現(xiàn)方式

NDH Impala支持兩個虛擬數(shù)倉實現(xiàn)，分別是基于zookeeper地址的靜態(tài)配置方案和基于會話（session）參數(shù)的動態(tài)配置方案，下面分別展開介紹。

（1）靜態(tài)配置

該方案將不同節(jié)點組的coordinator節(jié)點注冊到不同的zookeeper地址上，Hive JDBC客戶端連接不同的zookeeper地址即可獲取到不同業(yè)務組的coordinator，從而進行連接并下發(fā)SQL請求。此種方式中每個節(jié)點組都會擁有自己獨有的一到多個coordinator節(jié)點，負責將SQL生成的執(zhí)行計劃下發(fā)給組內(nèi)的executor節(jié)點執(zhí)行。

上圖所示集群有3個虛擬數(shù)倉：group 1，group 2和group 3。它們共用相同的statestored和catalogd，共用同一份數(shù)倉元數(shù)據(jù)。虛擬數(shù)倉間的impalad資源是物理隔離的，某個虛擬數(shù)倉的coordinator節(jié)點只會將查詢下發(fā)到組內(nèi)的executor節(jié)點。在生產(chǎn)環(huán)境中，可通過配置多個虛擬數(shù)倉來接收不同類型業(yè)務的查詢請求，以便不同業(yè)務的查詢在計算資源的使用上互相隔離，互不影響，圖中group 1用于進行ad-hoc查詢，group 2用于有數(shù)BI報表，group 3用于有數(shù)BI自助取數(shù)。相比多集群方式，多虛擬數(shù)倉的方式所需要資源更少，配置更靈活。

（2）動態(tài)路由

本方案在會話連接中增加一個query option參數(shù)request_group，通過set request_group=xxx語句，coordinator會自動將查詢路由到指定分組上執(zhí)行。request_group默認為default，對應group_name的默認值也為default。換言之，若不指定request_group，那么查詢會下發(fā)到默認的default分組執(zhí)行。

在本方案中coordinator節(jié)點是公共的，僅對executor節(jié)點進行分組，在實現(xiàn)上更類似Snowflake的虛擬數(shù)倉。如下圖所示，有2個公共的coordinator，3個分組，由于不存在default分組，可將默認分組配置為grp1?？梢酝ㄟ^參數(shù)動態(tài)配置，相比基于zookeeper的方案更加靈活，用戶能夠根據(jù)需要自由地將查詢在不同的虛擬數(shù)倉上切換。

上述兩種方案均已實現(xiàn)，由于NDH的生產(chǎn)環(huán)境一般通過Hive JDBC連接zookeeper來訪問Impala，前者的使用方法兼容性更好，目前線上主要使用以該方式部署虛擬數(shù)倉。本小節(jié)接下來介紹的虛擬數(shù)倉進階特性也主要圍繞前者展開。

3、主要特性

（1）水平擴展

若虛擬數(shù)倉的單個節(jié)點組資源和并發(fā)數(shù)已經(jīng)達到瓶頸，單純在組內(nèi)增加節(jié)點無法有效提升查詢并發(fā)數(shù)，此時可以新增一個規(guī)格相同或相近的節(jié)點組加入該虛擬數(shù)倉中，需將新節(jié)點組中coordinator的zookeeper地址配置成與原節(jié)點組相同。借助Hive JDBC在選擇zookeeper下coordinator地址時的隨機性特點，可將查詢負載均衡到新舊節(jié)點組上。這種方式可以接近線性地提升集群的查詢并發(fā)數(shù)。

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

（2）透明伸縮

NDH Impala可根據(jù)各虛擬數(shù)倉的負載情況，在線增加或減少虛擬數(shù)倉節(jié)點組中的impalad節(jié)點數(shù)，從而實現(xiàn)分組間的資源動態(tài)伸縮。通過Impala提供的graceful shutdown方式下線節(jié)點組中impalad進程時，會先禁止新的查詢請求發(fā)送到該impalad節(jié)點上，并等待其上正在執(zhí)行的查詢片段（fragment）完成后再關閉。因此不會導致其上正在執(zhí)行的查詢異常終止，做到對用戶無感。在生產(chǎn)環(huán)境中，配置了多個虛擬數(shù)倉的NDH Impala集群，可通過分析歷史查詢規(guī)律并結(jié)合分組中impalad節(jié)點的系統(tǒng)負載情況，在虛擬數(shù)倉間動態(tài)增減節(jié)點數(shù)，以求更充分得利用各節(jié)點資源。

舉網(wǎng)易云音樂為例，有數(shù)BI自助取數(shù)（easyfetch）的查詢一般發(fā)生在工作時間，有數(shù)BI報表需要在用戶上班前進行大量報表結(jié)果預加載操作（提前下發(fā)報表查詢SQL并緩存查詢結(jié)果從而提升報表查看體驗）。我們可將easyfetch和BI報表兩種場景配置為同一個NDH Impala集群的兩個虛擬數(shù)倉，在上班前，將easyfetch虛擬數(shù)倉的大部分impalad節(jié)點挪到BI報表虛擬數(shù)倉上，這樣可以大大提高報表的預加載效率。

當然，透明伸縮不僅僅適用在虛擬數(shù)倉之間。對于云上環(huán)境，通過k8s或類似調(diào)度機制，在負載高峰時可以便捷地申請容器或虛擬機資源，快速補充到線上。待高峰過后，再將所增加的資源釋放給云廠商。

4、進階功能

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

（1）混合分組

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

圖中，n1~n2為group1節(jié)點組coordinator節(jié)點，其會注冊到zookeeper路徑y(tǒng)oudata上，Hive JDBC客戶端從該路徑獲取任意coordinator節(jié)點向其提交查詢，coordinator將查詢進行解析，優(yōu)化并指定分布式執(zhí)行計劃，最終下發(fā)給n3_{n7執(zhí)行。n6}n7同時還是group4的executor節(jié)點，group4的coordinator為n8_{n9，其會接收從zookeeper路徑Ad-Hoc進入的查詢，指定分布式執(zhí)行計劃，并會發(fā)送到n6}n8上。

（2）分時復用

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

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

與混合分組相比，分時復用功能僅適合在規(guī)格相似的節(jié)點組之間使用，確保不同分組上的查詢性能沒有明顯的差距。

（3）基于負載的節(jié)點選擇

executor節(jié)點會出現(xiàn)多種原因?qū)е掠嬎阗Y源使用不均衡的問題，比如數(shù)據(jù)傾斜導致某些executor節(jié)點需要消耗更多計算資源掃描和處理數(shù)據(jù)，或引入混合分組特性導致某些節(jié)點組上節(jié)點負載過高等等。

針對該問題，NDH Impala進行了兩個優(yōu)化。第一個是支持基于executor節(jié)點負載的查詢分布式執(zhí)行，實現(xiàn)方法為在為查詢SQL確定分布式執(zhí)行計劃時，考慮executor節(jié)點當前可用的計算資源情況，剔除可用資源較少的executor節(jié)點；第二個是存在多隊列時，限制同個隊列上的查詢請求在一個executor上的資源使用總量，避免executor資源被某個隊列獨占。

5、小結(jié)

本小節(jié)主要介紹了虛擬數(shù)倉概念的來源和實現(xiàn)，重點分析了NDH Impala在虛擬數(shù)倉這塊的探索、思考和使用。目前虛擬數(shù)倉在網(wǎng)易互聯(lián)網(wǎng)業(yè)務以及網(wǎng)易數(shù)帆的商業(yè)化客戶集群上均有成功的應用案例。

筆者認為，虛擬數(shù)倉應該是新一代分析性數(shù)倉必備的一個能力，它能夠剝離復雜多樣的業(yè)務負載，充分發(fā)揮執(zhí)行引擎自身的能力。最后需要指出的是，虛擬數(shù)倉是一種云原生的特性，計算資源能夠靈活伸縮的環(huán)境能夠最大化其價值。

??想了解更多關于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎軟件社區(qū)??

??https://ost.51cto.com??。