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結合使用等。
02
對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修正。
03
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測試的效果就可以近實時的看到了。
推薦閱讀：
