基于Impala的高性能數倉建設實踐之虛擬數倉
本文主要介紹網易數帆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）參數的動態配置方案，下面分別展開介紹。
（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）動態路由
本方案在會話連接中增加一個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、主要特性
（1）水平擴展
若虛擬數倉的單個節點組資源和并發數已經達到瓶頸，單純在組內增加節點無法有效提升查詢并發數，此時可以新增一個規格相同或相近的節點組加入該虛擬數倉中，需將新節點組中coordinator的zookeeper地址配置成與原節點組相同。借助Hive JDBC在選擇zookeeper下coordinator地址時的隨機性特點，可將查詢負載均衡到新舊節點組上。這種方式可以接近線性地提升集群的查詢并發數。
上圖所示Impala集群有2個虛擬數倉，對應的節點組分別為group1和group3，承接的業務分別是業務的有數BI報表和ABTest場景。假設group1為原分組，有3個impalad節點（1個coordinator，2個executor）。新增分組group2，也是3個impalad節點，使用與group1相同的配置，即可起到水平擴展的效果。
（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），資源隔離更加徹底，使得不同業務模塊的查詢性能不會相互影響。但不同虛擬數倉所屬的業務會存在負載差異，可能導致資源利用不充分。為了提高空閑節點組的資源利用率，對虛擬數倉特性做了進一步增強，引入混合分組、分時復用等功能。
（1）混合分組
混合分組就是讓一個executor節點同時在2個或以上的節點組中，如下圖所示。左子圖為普通模式，假設NDH Impala集群分為有數BI報表和Ad-Hoc查詢2個虛擬數倉，Ad-Hoc查詢有明顯的時間性，查詢集中在工作時間，且查詢的并發度較低。通過混合分組，可將虛擬數倉部署方式改造為右子圖的模式。
圖中，n1~n2為group1節點組coordinator節點，其會注冊到zookeeper路徑youdata上，Hive JDBC客戶端從該路徑獲取任意coordinator節點向其提交查詢，coordinator將查詢進行解析，優化并指定分布式執行計劃，最終下發給n3n7執行。n6n7同時還是group4的executor節點，group4的coordinator為n8n9，其會接收從zookeeper路徑Ad-Hoc進入的查詢，指定分布式執行計劃，并會發送到n6n8上。
（2）分時復用
分時復用是另一個能夠提高資源利用率的進階功能。通過在特定的時間段自動配置集群的分組資源，緩解某些高負載分組的查詢壓力，提升用戶體驗。
在實現上，支持將同一個coordinator注冊到多個zookeeper地址下，且可以配置注冊到每個地址的有效時間，如上圖所示，可以每天晚上八點到早上八點將Ad-Hoc虛擬數倉的n8和n9兩個coordinator（或其中一個）注冊到BI報表虛擬數倉相同的zookeeper地址下，分攤BI報表的查詢負載。
與混合分組相比，分時復用功能僅適合在規格相似的節點組之間使用，確保不同分組上的查詢性能沒有明顯的差距。
（3）基于負載的節點選擇
executor節點會出現多種原因導致計算資源使用不均衡的問題，比如數據傾斜導致某些executor節點需要消耗更多計算資源掃描和處理數據，或引入混合分組特性導致某些節點組上節點負載過高等等。
針對該問題，NDH Impala進行了兩個優化。第一個是支持基于executor節點負載的查詢分布式執行，實現方法為在為查詢SQL確定分布式執行計劃時，考慮executor節點當前可用的計算資源情況，剔除可用資源較少的executor節點；第二個是存在多隊列時，限制同個隊列上的查詢請求在一個executor上的資源使用總量，避免executor資源被某個隊列獨占。
5、小結
本小節主要介紹了虛擬數倉概念的來源和實現，重點分析了NDH Impala在虛擬數倉這塊的探索、思考和使用。目前虛擬數倉在網易互聯網業務以及網易數帆的商業化客戶集群上均有成功的應用案例。
筆者認為，虛擬數倉應該是新一代分析性數倉必備的一個能力，它能夠剝離復雜多樣的業務負載，充分發揮執行引擎自身的能力。最后需要指出的是，虛擬數倉是一種云原生的特性，計算資源能夠靈活伸縮的環境能夠最大化其價值。
