Impala在網易大數據的優化和實踐

文章做者：溫正湖網易杭研數據庫

編輯整理：張博後端

出品平臺：DataFunTalk
緩存

導讀：網易大數據平臺的底層數據查詢引擎，選用了Impala做爲OLAP查詢引擎，不但支撐了網易大數據的交互式查詢與自助分析，還爲外部客戶提供了商業化的產品與服務。今天將爲你們分享下Impala在網易大數據的優化和實踐。性能優化

01服務器

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測試的效果就能夠近實時的看到了。