Impala在網易大資料的優化和實踐

導讀：網易大資料平台的底層資料查詢引擎，選用了Impala作為OLAP查詢引擎，不但支撐了網易大資料的互動式查詢與自助分析，還為外部客戶提供了商業化的産品與服務。今天将為大家分享下Impala在網易大資料的優化和實踐。

Impala的定位及優勢

Impala有哪些優勢，讓我們選擇Impala作為網易内部的OLAP查詢引擎？

1. Impala在資料進行中的角色

先來看一下Impala在資料進行中的角色。

對于資料量較少的場景，例如百萬資料以下的情況，可以采用傳統的關系型資料庫，如MySQL或者PostgreSQL等，或者一些文檔資料庫，比如MongoDB等。随着資料量的增大，達到上億級别時，一般選擇分析型數倉來存儲，并使用OLAP引擎來查詢。此等規模的資料查詢，對響應時間的要求雖然比關系型資料庫要低，但一般也要求在秒級傳回查詢結果，不能有太大的延遲。Impala、Presto、Greenplum等都在此列。當規模繼續擴大到上百億以上時，則會選擇批處理引擎，如Hive、Spark來進行資料處理。

今天分享的Impala就是針對分析型數倉的查詢引擎。分析型數倉有很多種模組化方式。

以Druid和Click House為代表的寬表模型，還有以Impala等為代表的星型/雪花型的模組化方式。我們将Impala作為通用的查詢引擎，比較典型的應用場景有自助資料分析、BI報表等。在分享的第三部分，有關于Impala在網易大資料平台“猛犸”中的介紹，以及在網易雲音樂中的實際使用場景的說明。

2. Impala的優勢

網易為什麼選擇Impala作為OLAP查詢引擎，Impala到底有哪些優勢？Impala的優勢，總結起來包括：

MPP 架構，去中心化
優秀的查詢性能
友好的 WebUI 界面
完全相容 Hive 中繼資料
Apache 頂級項目，社群活躍度高
支援多種資料格式（ Parquet/ORC 等）
與 Kudu 結合使用，實時數倉

① 去中心化的MPP并行架構

相比于傳統的關系型資料庫，MPP架構可以充分發揮多伺服器的特點，将資料量比較大的操作，分散在多台伺服器上并行處理。這些複雜的大資料量的操作，對于單台伺服器來說是無法完成的任務。

Impala還差別于其他MPP架構的引擎的一點，是Impala有多個Coordinator和Executor，多個Coordinator可以同時對外提供服務。多Coordinator的架構設計讓Impala可以有效防範單點故障的出現。

② 優秀的查詢性能

Impala支援CBO（基于代價的執行優化），除此之外，Impala還對Catalog進行了緩存。緩存的資訊包括：庫和表的資訊、HDFS資料庫、統計資訊等。中繼資料都緩存在了Impala内部，在做CBO時，能夠發揮更大的優勢，做出更優的選擇。除此之外，Impala同時具有典型的OLAP引擎應有的特征：靜态代碼生成支援LLVM、JIT；支援HDFS本地讀區，減少通路NameNode、DataNode和資料網絡傳輸的開銷，對性能有比較大的提升；還有算子下推，runtime filter在Join時，對與join條件之外的列可以進行動态過濾。

從我們實際使用效果來說，Impala性能優勢非常明顯。前段時間我們對Impala、presto和spark3.0進行了對比測試。測試用例選擇tpcds，并行節點8個。

總的來說，Impala相比Presto有明顯的優勢，相比Spark 3.0也有一定的優勢。Spark 3.0對性能做了很多優化和改進，相比之下Impala性能有一些優勢，不過Impala因為支援的SQL類型少一些，有一些tpcds的測試用例并不能完成。

③ 友好的WebUI界面

一般來說，大資料查詢引擎的查詢計劃，比關系型資料庫的查詢計劃複雜的多。Impala提供了一個比較友好的WebUI，在這個界面上，能看到完整的執行計劃、記憶體使用情況、異常查詢分析，也可以通過界面終止查詢語句。

此外，Impala的優勢還展現在：完全相容Hive中繼資料、Apache頂級項目有較高的社群活躍度、支援多種資料格式（Parquet、ORC等）、可以與Kudu結合使用等。

對Impala的一些增強和優化

在我們生産實踐中，也發現了Impala的一些不足，是以網易大資料團隊對Impala進行了一些優化和增強。包括以下幾個方面：

Impala 管理伺服器
中繼資料同步增強
基于zookeeper的服務高可用
支援更多存儲後端
其他增強和優化

1. Impala管理伺服器

Impala已經提供了WebUI的情況下，為什麼需要一個管理伺服器？

其中一個原因，是社群版的WebUI是非持久化的，一旦Impalad異常退出，這些資訊都會丢失。

我們通過MySQL存儲WebUI上的資訊，将統計資訊、執行資訊等重要資訊儲存到MySQL資料庫中，實作持久化儲存。在此基礎上，管理平台給我們帶來許多增值收益。相比于原生的WebUI，增強版的WebUI可以彙總各個coordinator執行的SQL語句，直覺展示目前執行的SQL。

還可以作為叢集持續優化的平台。因為記錄了曆史執行的SQL，可以為後續SQL優化提供依據，比如叢集SQL的性能名額、随時間變化的性能表現，以及大部分SQL的執行時間。通過統計SQL執行失敗的次數，出錯SQL，為定位和回溯問題提供幫助。

2. 中繼資料同步增強

Impala對中繼資料的緩存，一方面大幅提升了查詢性能，但另一方面，中繼資料更新也帶來了新的問題。因為資料可以不通過Impala用戶端，而通過其他元件比如Hive進行更新，這就讓Impala無法感覺到中繼資料的更新。而老舊的中繼資料會導緻查詢失敗或者性能下降。是以，需要一個機制能夠讓Impala及時感覺中繼資料的更新。社群版提供了INVALIDATE METADATA這一指令，可以手動重新整理中繼資料。不過如果一些使用者不熟悉這個操作，沒有更新Impala緩存的中繼資料，就會導緻查詢的問題。怎麼解決這樣的問題？

網易對此進行優化，引入了中繼資料自動同步機制：在Hive進行DDL相關操作時，記錄記錄檔，Impala通過消費記錄檔，進行必要的Invalidate Metadata的操作，無須人工操作，大大提高了中繼資料緩存的可用性和實時性。對于提升Impala的查詢性能，降低查詢錯誤都有很大的幫助。

另外一個是中繼資料的黑白名單機制，配合Impala不同的中繼資料加載方式。對于啟動時加載中繼資料的，配置黑名單，屏蔽不需要通過Impala查詢的表；對于延遲加載中繼資料的，配置白名單，即刻加載中繼資料，避免首次查詢時延遲過大。

另外需要提醒的是，Impala 3.x版本在中繼資料緩存管理上有了極大的改進，網易大資料團隊也在調研中，準備從2.12更新到3.4版本。

3. 基于ZK的服務高可用

雖然每一個Impalad都可以作為Coordinator，對外提供通路服務，接受用戶端請求，但是缺乏一個路由機制。當一個client連接配接的特定coordinator失效之後，就無法在進行查詢了。

網易大資料團隊參考Hive的實作，引入zookeeper作為通路代理，用戶端首先通過zookeeper找到可用的coordinator節點，然後再送出SQL查詢請求。通過這種方式，提供了更健壯的查詢服務模式。

4. 支援更多存儲後端

對于後端存儲的支援，網易團隊增加了對iceberg表的建立和查詢的支援。已經在雲音樂業務上使用，并且貢獻給了Impala社群。

其他後端還包括對Alluxio的支援，使用Alluxio作為Impala和HDFS之間的二級緩存。這方面的詳細資訊，可以搜尋《網易嚴選：基于 Alluxio+Impala 深度融合架構的 BI 系統性能優化實踐》。

此外對接Elastic Search查詢，充分發揮了ES反向索引的優勢。

5. 其他增強和優化

其他的增強還有：權限的優化、Hive多版本适配、支援JSON，以及社群版的一些Bug修正。

Impala在網易的使用案例分析

1. Impala的部署和使用

Impala兩種部署方式：混合部署與獨立部署。混合部署是指Impala和其他大資料元件共用HDFS。而獨立部署則是為Impala配置獨立的HDFS。獨立部署的優勢在于IO和網絡通信都有保障，對性能和穩定性的提升有幫助。但是代價也十分明顯：成本上升。

Impala與Kudu結合，可以用來建構實時數倉。Kudu增量寫入，定期儲存到HDFS。Kudu的使用一方面提供了更新資料和删除資料的能力，另一方面也解決了HDFS上小檔案的問題。而Impala可以同時查詢Kudu和HDFS上的資料。

網易内部對叢集的監控，對接了網易内部的哨兵服務。可以提供準實時的告警能力。運維人員通過設定門檻值，訂閱告警資訊，進而了解叢集的監控程度。

此外，對于Impala叢集的部署和使用，還有幾點需要注意：

按照大業務劃分不同的叢集
按照不同的子業務或者 SQL 類型劃分隊列
coordinator 節點與 executor 節點分開部署
對于機器數比較少的叢集，機器上可部署多個節點，增加并發
業務方重試機制，以免 impalad 節點挂掉導緻 SQL 失敗
通過 impala hint 改變表的 join 方式
結合實際情況參考是否設定 mem_limit ，設定多大 mem_limit

2. 網易大資料中的Impala

在網易大資料平台“猛犸”中，Impala位于資料計算層，提供互動式查詢的能力，對應的應用場景是自助分析。

在網易對外提供的産品和服務中，複雜報表和自助取數，都用到了Impala。其中自助分析服務适用于有一定SQL基礎的使用者，通過自己寫SQL語句，查詢資料。靈活性比較大，同時門檻也比較高。

網易有數的自助取數服務（easyFetch）可以通過拖拽次元和度量，友善的擷取資料，并生成圖表報告。後端對接的是網易有數的API。非常适合非專業人員使用資料，發揮出資料的生産力。

網易現在内部有8個Impala叢集，超過200個節點，最大叢集規模超過60個節點。除了内部服務外，對外的商業化服務，已經有超過20個Impala叢集。

3. Impala在雲音樂的使用實踐

網易雲音樂，有2個Impala叢集，超過60個節點的規模。主要的應用場景包括：有數報表、自助分析、音樂版權、A/B測試，easyFetch等等。絕大部分應用場景下，Impala的查詢時間不超過2秒。

雲音樂A/B測試早期使用Spark按照小時粒度，完成從ODS到DWD層的資料清洗工作，之後生成使用者分流表和名額統計表，再使用Spark關聯這兩張表的結果寫入到Kudu中，最後使用Impala對接資料，供使用者查詢。這樣資料延遲至少1～2小時，有些結果甚至在第二天才能看到。但是對于A/B測試，能夠實時看到結果才是最好的。

對此雲音樂團隊基于Flink做了實時性改造。将DWS變成流表，這樣Impala可以同時查詢T+1的結果表和流表中的實時資料。A/B測試的效果就可以近實時的看到了。