Impala在網(wǎng)易大數(shù)據(jù)的優(yōu)化和實踐
文章作者：溫正湖?網(wǎng)易杭研
編輯整理：張博
出品平臺：DataFunTalk
Impala有哪些優(yōu)勢，讓我們選擇Impala作為網(wǎng)易內(nèi)部的OLAP查詢引擎？
1.?Impala在數(shù)據(jù)處理中的角色
先來看一下Impala在數(shù)據(jù)處理中的角色。
對于數(shù)據(jù)量較少的場景，例如百萬數(shù)據(jù)以下的情況，可以采用傳統(tǒng)的關系型數(shù)據(jù)庫，如MySQL或者PostgreSQL等，或者一些文檔數(shù)據(jù)庫，比如MongoDB等。隨著數(shù)據(jù)量的增大，達到上億級別時，一般選擇分析型數(shù)倉來存儲，并使用OLAP引擎來查詢。此等規(guī)模的數(shù)據(jù)查詢，對響應時間的要求雖然比關系型數(shù)據(jù)庫要低，但一般也要求在秒級返回查詢結果，不能有太大的延遲。Impala、Presto、Greenplum等都在此列。當規(guī)模繼續(xù)擴大到上百億以上時，則會選擇批處理引擎，如Hive、Spark來進行數(shù)據(jù)處理。
今天分享的Impala就是針對分析型數(shù)倉的查詢引擎。分析型數(shù)倉有很多種建模方式。
以Druid和Click House為代表的寬表模型，還有以Impala等為代表的星型/雪花型的建模方式。我們將Impala作為通用的查詢引擎，比較典型的應用場景有自助數(shù)據(jù)分析、BI報表等。在分享的第三部分，有關于Impala在網(wǎng)易大數(shù)據(jù)平臺“猛犸”中的介紹，以及在網(wǎng)易云音樂中的實際使用場景的說明。
2.?Impala的優(yōu)勢
網(wǎng)易為什么選擇Impala作為OLAP查詢引擎，Impala到底有哪些優(yōu)勢？Impala的優(yōu)勢，總結起來包括：
MPP 架構，去中心化
優(yōu)秀的查詢性能
友好的 WebUI 界面
完全兼容 Hive 元數(shù)據(jù)
Apache 頂級項目，社區(qū)活躍度高
支持多種數(shù)據(jù)格式（ Parquet/ORC 等）
與 Kudu 結合使用，實時數(shù)倉
① 去中心化的MPP并行架構
相比于傳統(tǒng)的關系型數(shù)據(jù)庫，MPP架構可以充分發(fā)揮多服務器的特點，將數(shù)據(jù)量比較大的操作，分散在多臺服務器上并行處理。這些復雜的大數(shù)據(jù)量的操作，對于單臺服務器來說是無法完成的任務。
Impala還區(qū)別于其他MPP架構的引擎的一點，是Impala有多個Coordinator和Executor，多個Coordinator可以同時對外提供服務。多Coordinator的架構設計讓Impala可以有效防范單點故障的出現(xiàn)。
②?優(yōu)秀的查詢性能
Impala支持CBO（基于代價的執(zhí)行優(yōu)化），除此之外，Impala還對Catalog進行了緩存。緩存的信息包括：庫和表的信息、HDFS數(shù)據(jù)庫、統(tǒng)計信息等。元數(shù)據(jù)都緩存在了Impala內(nèi)部，在做CBO時，能夠發(fā)揮更大的優(yōu)勢，做出更優(yōu)的選擇。除此之外，Impala同時具有典型的OLAP引擎應有的特征：靜態(tài)代碼生成支持LLVM、JIT；支持HDFS本地讀區(qū)，減少訪問NameNode、DataNode和數(shù)據(jù)網(wǎng)絡傳輸?shù)拈_銷，對性能有比較大的提升；還有算子下推，runtime filter在Join時，對與join條件之外的列可以進行動態(tài)過濾。
從我們實際使用效果來說，Impala性能優(yōu)勢非常明顯。前段時間我們對Impala、presto和spark3.0進行了對比測試。測試用例選擇tpcds，并行節(jié)點8個。
總的來說，Impala相比Presto有明顯的優(yōu)勢，相比Spark 3.0也有一定的優(yōu)勢。Spark 3.0對性能做了很多優(yōu)化和改進，相比之下Impala性能有一些優(yōu)勢，不過Impala因為支持的SQL類型少一些，有一些tpcds的測試用例并不能完成。
③ 友好的WebUI界面
一般來說，大數(shù)據(jù)查詢引擎的查詢計劃，比關系型數(shù)據(jù)庫的查詢計劃復雜的多。Impala提供了一個比較友好的WebUI，在這個界面上，能看到完整的執(zhí)行計劃、內(nèi)存使用情況、異常查詢分析，也可以通過界面終止查詢語句。
此外，Impala的優(yōu)勢還體現(xiàn)在：完全兼容Hive元數(shù)據(jù)、Apache頂級項目有較高的社區(qū)活躍度、支持多種數(shù)據(jù)格式（Parquet、ORC等）、可以與Kudu結合使用等。
在我們生產(chǎn)實踐中，也發(fā)現(xiàn)了Impala的一些不足，因此網(wǎng)易大數(shù)據(jù)團隊對Impala進行了一些優(yōu)化和增強。包括以下幾個方面：
Impala 管理服務器
元數(shù)據(jù)同步增強
基于zookeeper的服務高可用
支持更多存儲后端
其他增強和優(yōu)化
1.?Impala管理服務器
Impala已經(jīng)提供了WebUI的情況下，為什么需要一個管理服務器？
其中一個原因，是社區(qū)版的WebUI是非持久化的，一旦Impalad異常退出，這些信息都會丟失。
我們通過MySQL存儲WebUI上的信息，將統(tǒng)計信息、執(zhí)行信息等重要信息保存到MySQL數(shù)據(jù)庫中，實現(xiàn)持久化保存。在此基礎上，管理平臺給我們帶來許多增值收益。相比于原生的WebUI，增強版的WebUI可以匯總各個coordinator執(zhí)行的SQL語句，直觀展示當前執(zhí)行的SQL。
還可以作為集群持續(xù)優(yōu)化的平臺。因為記錄了歷史執(zhí)行的SQL，可以為后續(xù)SQL優(yōu)化提供依據(jù)，比如集群SQL的性能指標、隨時間變化的性能表現(xiàn)，以及大部分SQL的執(zhí)行時間。通過統(tǒng)計SQL執(zhí)行失敗的次數(shù)，出錯SQL，為定位和回溯問題提供幫助。
2.?元數(shù)據(jù)同步增強
Impala對元數(shù)據(jù)的緩存，一方面大幅提升了查詢性能，但另一方面，元數(shù)據(jù)更新也帶來了新的問題。因為數(shù)據(jù)可以不通過Impala客戶端，而通過其他組件比如Hive進行更新，這就讓Impala無法感知到元數(shù)據(jù)的更新。而老舊的元數(shù)據(jù)會導致查詢失敗或者性能下降。因此，需要一個機制能夠讓Impala及時感知元數(shù)據(jù)的更新。社區(qū)版提供了INVALIDATE METADATA這一命令，可以手動刷新元數(shù)據(jù)。不過如果一些用戶不熟悉這個操作，沒有更新Impala緩存的元數(shù)據(jù)，就會導致查詢的問題。怎么解決這樣的問題？
網(wǎng)易對此進行優(yōu)化，引入了元數(shù)據(jù)自動同步機制：在Hive進行DDL相關操作時，記錄操作日志，Impala通過消費操作日志，進行必要的Invalidate Metadata的操作，無須人工操作，大大提高了元數(shù)據(jù)緩存的可用性和實時性。對于提升Impala的查詢性能，降低查詢錯誤都有很大的幫助。
另外一個是元數(shù)據(jù)的黑白名單機制，配合Impala不同的元數(shù)據(jù)加載方式。對于啟動時加載元數(shù)據(jù)的，配置黑名單，屏蔽不需要通過Impala查詢的表；對于延遲加載元數(shù)據(jù)的，配置白名單，即刻加載元數(shù)據(jù)，避免首次查詢時延遲過大。
另外需要提醒的是，Impala 3.x版本在元數(shù)據(jù)緩存管理上有了極大的改進，網(wǎng)易大數(shù)據(jù)團隊也在調(diào)研中，準備從2.12升級到3.4版本。
3.?基于ZK的服務高可用
雖然每一個Impalad都可以作為Coordinator，對外提供訪問服務，接受客戶端請求，但是缺乏一個路由機制。當一個client連接的特定coordinator失效之后，就無法在進行查詢了。
網(wǎng)易大數(shù)據(jù)團隊參考Hive的實現(xiàn)，引入zookeeper作為訪問代理，客戶端首先通過zookeeper找到可用的coordinator節(jié)點，然后再提交SQL查詢請求。通過這種方式，提供了更健壯的查詢服務模式。
4.?支持更多存儲后端
對于后端存儲的支持，網(wǎng)易團隊增加了對iceberg表的創(chuàng)建和查詢的支持。已經(jīng)在云音樂業(yè)務上使用，并且貢獻給了Impala社區(qū)。
其他后端還包括對Alluxio的支持，使用Alluxio作為Impala和HDFS之間的二級緩存。這方面的詳細信息，可以搜索《網(wǎng)易嚴選：基于 Alluxio+Impala 深度融合架構的 BI 系統(tǒng)性能優(yōu)化實踐》。
此外對接Elastic Search查詢，充分發(fā)揮了ES倒排索引的優(yōu)勢。
5.?其他增強和優(yōu)化
其他的增強還有：權限的優(yōu)化、Hive多版本適配、支持JSON，以及社區(qū)版的一些Bug修正。
1.?Impala的部署和使用
Impala兩種部署方式：混合部署與獨立部署?；旌喜渴鹗侵窱mpala和其他大數(shù)據(jù)組件共用HDFS。而獨立部署則是為Impala配置獨立的HDFS。獨立部署的優(yōu)勢在于IO和網(wǎng)絡通信都有保障，對性能和穩(wěn)定性的提升有幫助。但是代價也十分明顯：成本上升。
Impala與Kudu結合，可以用來構建實時數(shù)倉。Kudu增量寫入，定期保存到HDFS。Kudu的使用一方面提供了更新數(shù)據(jù)和刪除數(shù)據(jù)的能力，另一方面也解決了HDFS上小文件的問題。而Impala可以同時查詢Kudu和HDFS上的數(shù)據(jù)。
網(wǎng)易內(nèi)部對集群的監(jiān)控，對接了網(wǎng)易內(nèi)部的哨兵服務。可以提供準實時的告警能力。運維人員通過設置閾值，訂閱告警信息，從而了解集群的監(jiān)控程度。
此外，對于Impala集群的部署和使用，還有幾點需要注意：
按照大業(yè)務劃分不同的集群
按照不同的子業(yè)務或者 SQL 類型劃分隊列
coordinator 節(jié)點與 executor 節(jié)點分開部署
對于機器數(shù)比較少的集群，機器上可部署多個節(jié)點，增加并發(fā)
業(yè)務方重試機制，以免 impalad 節(jié)點掛掉導致 SQL 失敗
通過 impala hint 改變表的 join 方式
結合實際情況參考是否設置 mem_limit ，設置多大 mem_limit
2.?網(wǎng)易大數(shù)據(jù)中的Impala
在網(wǎng)易大數(shù)據(jù)平臺“猛犸”中，Impala位于數(shù)據(jù)計算層，提供交互式查詢的能力，對應的應用場景是自助分析。
在網(wǎng)易對外提供的產(chǎn)品和服務中，復雜報表和自助取數(shù)，都用到了Impala。其中自助分析服務適用于有一定SQL基礎的用戶，通過自己寫SQL語句，查詢數(shù)據(jù)。靈活性比較大，同時門檻也比較高。
網(wǎng)易有數(shù)的自助取數(shù)服務（easyFetch）可以通過拖拽維度和度量，方便的獲取數(shù)據(jù)，并生成圖表報告。后端對接的是網(wǎng)易有數(shù)的API。非常適合非專業(yè)人員使用數(shù)據(jù)，發(fā)揮出數(shù)據(jù)的生產(chǎn)力。
網(wǎng)易現(xiàn)在內(nèi)部有8個Impala集群，超過200個節(jié)點，最大集群規(guī)模超過60個節(jié)點。除了內(nèi)部服務外，對外的商業(yè)化服務，已經(jīng)有超過20個Impala集群。
3.?Impala在云音樂的使用實踐
網(wǎng)易云音樂，有2個Impala集群，超過60個節(jié)點的規(guī)模。主要的應用場景包括：有數(shù)報表、自助分析、音樂版權、A/B測試，easyFetch等等。絕大部分應用場景下，Impala的查詢時間不超過2秒。
云音樂A/B測試早期使用Spark按照小時粒度，完成從ODS到DWD層的數(shù)據(jù)清洗工作，之后生成用戶分流表和指標統(tǒng)計表，再使用Spark關聯(lián)這兩張表的結果寫入到Kudu中，最后使用Impala對接數(shù)據(jù)，供用戶查詢。這樣數(shù)據(jù)延遲至少1～2小時，有些結果甚至在第二天才能看到。但是對于A/B測試，能夠?qū)崟r看到結果才是最好的。
對此云音樂團隊基于Flink做了實時性改造。將DWS變成流表，這樣Impala可以同時查詢T+1的結果表和流表中的實時數(shù)據(jù)。A/B測試的效果就可以近實時的看到了。
今天的分享就到這里，謝謝大家。
在文末分享、點贊、在看，給個三連擊唄~~
嘉賓介紹：
溫正湖
網(wǎng)易杭研 |?高級數(shù)據(jù)庫技術專家
特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責聲明：本文內(nèi)容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
