文章作者：溫正湖?網(wǎng)易杭研

編輯整理：張博

出品平臺：DataFunTalk

導(dǎo)讀： 網(wǎng)易大數(shù)據(jù)平臺的底層數(shù)據(jù)查詢引擎，選用了Impala作為OLAP查詢引擎，不但支撐了網(wǎng)易大數(shù)據(jù)的交互式查詢與自助分析，還為外部客戶提供了商業(yè)化的產(chǎn)品與服務(wù)。今天將為大家分享下Impala在網(wǎng)易大數(shù)據(jù)的優(yōu)化和實(shí)踐。

01

Impala的定位及優(yōu)勢

Impala有哪些優(yōu)勢，讓我們選擇Impala作為網(wǎng)易內(nèi)部的OLAP查詢引擎？

1.?Impala在數(shù)據(jù)處理中的角色

先來看一下Impala在數(shù)據(jù)處理中的角色。

對于數(shù)據(jù)量較少的場景，例如百萬數(shù)據(jù)以下的情況，可以采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，如MySQL或者PostgreSQL等，或者一些文檔數(shù)據(jù)庫，比如MongoDB等。隨著數(shù)據(jù)量的增大，達(dá)到上億級別時(shí)，一般選擇分析型數(shù)倉來存儲，并使用OLAP引擎來查詢。此等規(guī)模的數(shù)據(jù)查詢，對響應(yīng)時(shí)間的要求雖然比關(guān)系型數(shù)據(jù)庫要低，但一般也要求在秒級返回查詢結(jié)果，不能有太大的延遲。Impala、Presto、Greenplum等都在此列。當(dāng)規(guī)模繼續(xù)擴(kuò)大到上百億以上時(shí)，則會選擇批處理引擎，如Hive、Spark來進(jìn)行數(shù)據(jù)處理。

今天分享的Impala就是針對分析型數(shù)倉的查詢引擎。分析型數(shù)倉有很多種建模方式。

以Druid和Click House為代表的寬表模型，還有以Impala等為代表的星型/雪花型的建模方式。我們將Impala作為通用的查詢引擎，比較典型的應(yīng)用場景有自助數(shù)據(jù)分析、BI報(bào)表等。在分享的第三部分，有關(guān)于Impala在網(wǎng)易大數(shù)據(jù)平臺“猛犸”中的介紹，以及在網(wǎng)易云音樂中的實(shí)際使用場景的說明。

2.?Impala的優(yōu)勢

網(wǎng)易為什么選擇Impala作為OLAP查詢引擎，Impala到底有哪些優(yōu)勢？Impala的優(yōu)勢，總結(jié)起來包括：

• MPP 架構(gòu)，去中心化

• 優(yōu)秀的查詢性能

• 友好的 WebUI 界面

• 完全兼容 Hive 元數(shù)據(jù)

• Apache 頂級項(xiàng)目，社區(qū)活躍度高

• 支持多種數(shù)據(jù)格式（ Parquet/ORC 等）

• 與 Kudu 結(jié)合使用，實(shí)時(shí)數(shù)倉

① 去中心化的MPP并行架構(gòu)

相比于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，MPP架構(gòu)可以充分發(fā)揮多服務(wù)器的特點(diǎn)，將數(shù)據(jù)量比較大的操作，分散在多臺服務(wù)器上并行處理。這些復(fù)雜的大數(shù)據(jù)量的操作，對于單臺服務(wù)器來說是無法完成的任務(wù)。

Impala還區(qū)別于其他MPP架構(gòu)的引擎的一點(diǎn)，是Impala有多個(gè)Coordinator和Executor，多個(gè)Coordinator可以同時(shí)對外提供服務(wù)。多Coordinator的架構(gòu)設(shè)計(jì)讓Impala可以有效防范單點(diǎn)故障的出現(xiàn)。

②?優(yōu)秀的查詢性能

Impala支持CBO（基于代價(jià)的執(zhí)行優(yōu)化），除此之外，Impala還對Catalog進(jìn)行了緩存。緩存的信息包括：庫和表的信息、HDFS數(shù)據(jù)庫、統(tǒng)計(jì)信息等。元數(shù)據(jù)都緩存在了Impala內(nèi)部，在做CBO時(shí)，能夠發(fā)揮更大的優(yōu)勢，做出更優(yōu)的選擇。除此之外，Impala同時(shí)具有典型的OLAP引擎應(yīng)有的特征：靜態(tài)代碼生成支持LLVM、JIT；支持HDFS本地讀區(qū)，減少訪問NameNode、DataNode和數(shù)據(jù)網(wǎng)絡(luò)傳輸?shù)拈_銷，對性能有比較大的提升；還有算子下推，runtime filter在Join時(shí)，對與join條件之外的列可以進(jìn)行動(dòng)態(tài)過濾。

從我們實(shí)際使用效果來說，Impala性能優(yōu)勢非常明顯。前段時(shí)間我們對Impala、presto和spark3.0進(jìn)行了對比測試。測試用例選擇tpcds，并行節(jié)點(diǎn)8個(gè)。

總的來說，Impala相比Presto有明顯的優(yōu)勢，相比Spark 3.0也有一定的優(yōu)勢。Spark 3.0對性能做了很多優(yōu)化和改進(jìn)，相比之下Impala性能有一些優(yōu)勢，不過Impala因?yàn)橹С值腟QL類型少一些，有一些tpcds的測試用例并不能完成。

③ 友好的WebUI界面

一般來說，大數(shù)據(jù)查詢引擎的查詢計(jì)劃，比關(guān)系型數(shù)據(jù)庫的查詢計(jì)劃復(fù)雜的多。Impala提供了一個(gè)比較友好的WebUI，在這個(gè)界面上，能看到完整的執(zhí)行計(jì)劃、內(nèi)存使用情況、異常查詢分析，也可以通過界面終止查詢語句。

此外，Impala的優(yōu)勢還體現(xiàn)在：完全兼容Hive元數(shù)據(jù)、Apache頂級項(xiàng)目有較高的社區(qū)活躍度、支持多種數(shù)據(jù)格式（Parquet、ORC等）、可以與Kudu結(jié)合使用等。

02

對Impala的一些增強(qiáng)和優(yōu)化

在我們生產(chǎn)實(shí)踐中，也發(fā)現(xiàn)了Impala的一些不足，因此網(wǎng)易大數(shù)據(jù)團(tuán)隊(duì)對Impala進(jìn)行了一些優(yōu)化和增強(qiáng)。包括以下幾個(gè)方面：

• Impala 管理服務(wù)器

• 元數(shù)據(jù)同步增強(qiáng)

• 基于zookeeper的服務(wù)高可用

• 支持更多存儲后端

• 其他增強(qiáng)和優(yōu)化

1.?Impala管理服務(wù)器

Impala已經(jīng)提供了WebUI的情況下，為什么需要一個(gè)管理服務(wù)器？

其中一個(gè)原因，是社區(qū)版的WebUI是非持久化的，一旦Impalad異常退出，這些信息都會丟失。

我們通過MySQL存儲WebUI上的信息，將統(tǒng)計(jì)信息、執(zhí)行信息等重要信息保存到MySQL數(shù)據(jù)庫中，實(shí)現(xiàn)持久化保存。在此基礎(chǔ)上，管理平臺給我們帶來許多增值收益。相比于原生的WebUI，增強(qiáng)版的WebUI可以匯總各個(gè)coordinator執(zhí)行的SQL語句，直觀展示當(dāng)前執(zhí)行的SQL。

還可以作為集群持續(xù)優(yōu)化的平臺。因?yàn)橛涗浟藲v史執(zhí)行的SQL，可以為后續(xù)SQL優(yōu)化提供依據(jù)，比如集群SQL的性能指標(biāo)、隨時(shí)間變化的性能表現(xiàn)，以及大部分SQL的執(zhí)行時(shí)間。通過統(tǒng)計(jì)SQL執(zhí)行失敗的次數(shù)，出錯(cuò)SQL，為定位和回溯問題提供幫助。

2.?元數(shù)據(jù)同步增強(qiáng)

Impala對元數(shù)據(jù)的緩存，一方面大幅提升了查詢性能，但另一方面，元數(shù)據(jù)更新也帶來了新的問題。因?yàn)閿?shù)據(jù)可以不通過Impala客戶端，而通過其他組件比如Hive進(jìn)行更新，這就讓Impala無法感知到元數(shù)據(jù)的更新。而老舊的元數(shù)據(jù)會導(dǎo)致查詢失敗或者性能下降。因此，需要一個(gè)機(jī)制能夠讓Impala及時(shí)感知元數(shù)據(jù)的更新。社區(qū)版提供了INVALIDATE METADATA這一命令，可以手動(dòng)刷新元數(shù)據(jù)。不過如果一些用戶不熟悉這個(gè)操作，沒有更新Impala緩存的元數(shù)據(jù)，就會導(dǎo)致查詢的問題。怎么解決這樣的問題？

網(wǎng)易對此進(jìn)行優(yōu)化，引入了元數(shù)據(jù)自動(dòng)同步機(jī)制：在Hive進(jìn)行DDL相關(guān)操作時(shí)，記錄操作日志，Impala通過消費(fèi)操作日志，進(jìn)行必要的Invalidate Metadata的操作，無須人工操作，大大提高了元數(shù)據(jù)緩存的可用性和實(shí)時(shí)性。對于提升Impala的查詢性能，降低查詢錯(cuò)誤都有很大的幫助。

另外一個(gè)是元數(shù)據(jù)的黑白名單機(jī)制，配合Impala不同的元數(shù)據(jù)加載方式。對于啟動(dòng)時(shí)加載元數(shù)據(jù)的，配置黑名單，屏蔽不需要通過Impala查詢的表；對于延遲加載元數(shù)據(jù)的，配置白名單，即刻加載元數(shù)據(jù)，避免首次查詢時(shí)延遲過大。

另外需要提醒的是，Impala 3.x版本在元數(shù)據(jù)緩存管理上有了極大的改進(jìn)，網(wǎng)易大數(shù)據(jù)團(tuán)隊(duì)也在調(diào)研中，準(zhǔn)備從2.12升級到3.4版本。

3.?基于ZK的服務(wù)高可用

雖然每一個(gè)Impalad都可以作為Coordinator，對外提供訪問服務(wù)，接受客戶端請求，但是缺乏一個(gè)路由機(jī)制。當(dāng)一個(gè)client連接的特定coordinator失效之后，就無法在進(jìn)行查詢了。

網(wǎng)易大數(shù)據(jù)團(tuán)隊(duì)參考Hive的實(shí)現(xiàn)，引入zookeeper作為訪問代理，客戶端首先通過zookeeper找到可用的coordinator節(jié)點(diǎn)，然后再提交SQL查詢請求。通過這種方式，提供了更健壯的查詢服務(wù)模式。

4.?支持更多存儲后端

對于后端存儲的支持，網(wǎng)易團(tuán)隊(duì)增加了對iceberg表的創(chuàng)建和查詢的支持。已經(jīng)在云音樂業(yè)務(wù)上使用，并且貢獻(xiàn)給了Impala社區(qū)。

其他后端還包括對Alluxio的支持，使用Alluxio作為Impala和HDFS之間的二級緩存。這方面的詳細(xì)信息，可以搜索《網(wǎng)易嚴(yán)選：基于 Alluxio+Impala 深度融合架構(gòu)的 BI 系統(tǒng)性能優(yōu)化實(shí)踐》。

此外對接Elastic Search查詢，充分發(fā)揮了ES倒排索引的優(yōu)勢。

5.?其他增強(qiáng)和優(yōu)化

其他的增強(qiáng)還有：權(quán)限的優(yōu)化、Hive多版本適配、支持JSON，以及社區(qū)版的一些Bug修正。

03

Impala在網(wǎng)易的使用案例分析

1.?Impala的部署和使用

Impala兩種部署方式：混合部署與獨(dú)立部署?；旌喜渴鹗侵窱mpala和其他大數(shù)據(jù)組件共用HDFS。而獨(dú)立部署則是為Impala配置獨(dú)立的HDFS。獨(dú)立部署的優(yōu)勢在于IO和網(wǎng)絡(luò)通信都有保障，對性能和穩(wěn)定性的提升有幫助。但是代價(jià)也十分明顯：成本上升。

Impala與Kudu結(jié)合，可以用來構(gòu)建實(shí)時(shí)數(shù)倉。Kudu增量寫入，定期保存到HDFS。Kudu的使用一方面提供了更新數(shù)據(jù)和刪除數(shù)據(jù)的能力，另一方面也解決了HDFS上小文件的問題。而Impala可以同時(shí)查詢Kudu和HDFS上的數(shù)據(jù)。

網(wǎng)易內(nèi)部對集群的監(jiān)控，對接了網(wǎng)易內(nèi)部的哨兵服務(wù)?？梢蕴峁?zhǔn)實(shí)時(shí)的告警能力。運(yùn)維人員通過設(shè)置閾值，訂閱告警信息，從而了解集群的監(jiān)控程度。

此外，對于Impala集群的部署和使用，還有幾點(diǎn)需要注意：

• 按照大業(yè)務(wù)劃分不同的集群

• 按照不同的子業(yè)務(wù)或者 SQL 類型劃分隊(duì)列

• coordinator 節(jié)點(diǎn)與 executor 節(jié)點(diǎn)分開部署

• 對于機(jī)器數(shù)比較少的集群，機(jī)器上可部署多個(gè)節(jié)點(diǎn)，增加并發(fā)

• 業(yè)務(wù)方重試機(jī)制，以免 impalad 節(jié)點(diǎn)掛掉導(dǎo)致 SQL 失敗

• 通過 impala hint 改變表的 join 方式

• 結(jié)合實(shí)際情況參考是否設(shè)置 mem_limit ，設(shè)置多大 mem_limit

2.?網(wǎng)易大數(shù)據(jù)中的Impala

在網(wǎng)易大數(shù)據(jù)平臺“猛犸”中，Impala位于數(shù)據(jù)計(jì)算層，提供交互式查詢的能力，對應(yīng)的應(yīng)用場景是自助分析。

在網(wǎng)易對外提供的產(chǎn)品和服務(wù)中，復(fù)雜報(bào)表和自助取數(shù)，都用到了Impala。其中自助分析服務(wù)適用于有一定SQL基礎(chǔ)的用戶，通過自己寫SQL語句，查詢數(shù)據(jù)。靈活性比較大，同時(shí)門檻也比較高。

網(wǎng)易有數(shù)的自助取數(shù)服務(wù)（easyFetch）可以通過拖拽維度和度量，方便的獲取數(shù)據(jù)，并生成圖表報(bào)告。后端對接的是網(wǎng)易有數(shù)的API。非常適合非專業(yè)人員使用數(shù)據(jù)，發(fā)揮出數(shù)據(jù)的生產(chǎn)力。

網(wǎng)易現(xiàn)在內(nèi)部有8個(gè)Impala集群，超過200個(gè)節(jié)點(diǎn)，最大集群規(guī)模超過60個(gè)節(jié)點(diǎn)。除了內(nèi)部服務(wù)外，對外的商業(yè)化服務(wù)，已經(jīng)有超過20個(gè)Impala集群。

3.?Impala在云音樂的使用實(shí)踐

網(wǎng)易云音樂，有2個(gè)Impala集群，超過60個(gè)節(jié)點(diǎn)的規(guī)模。主要的應(yīng)用場景包括：有數(shù)報(bào)表、自助分析、音樂版權(quán)、A/B測試，easyFetch等等。絕大部分應(yīng)用場景下，Impala的查詢時(shí)間不超過2秒。

云音樂A/B測試早期使用Spark按照小時(shí)粒度，完成從ODS到DWD層的數(shù)據(jù)清洗工作，之后生成用戶分流表和指標(biāo)統(tǒng)計(jì)表，再使用Spark關(guān)聯(lián)這兩張表的結(jié)果寫入到Kudu中，最后使用Impala對接數(shù)據(jù)，供用戶查詢。這樣數(shù)據(jù)延遲至少1～2小時(shí)，有些結(jié)果甚至在第二天才能看到。但是對于A/B測試，能夠?qū)崟r(shí)看到結(jié)果才是最好的。

對此云音樂團(tuán)隊(duì)基于Flink做了實(shí)時(shí)性改造。將DWS變成流表，這樣Impala可以同時(shí)查詢T+1的結(jié)果表和流表中的實(shí)時(shí)數(shù)據(jù)。A/B測試的效果就可以近實(shí)時(shí)的看到了。

今天的分享就到這里，謝謝大家。

---

在文末分享、點(diǎn)贊、在看，給個(gè)三連擊唄~~

---

嘉賓介紹：

溫正湖

網(wǎng)易杭研 |?高級數(shù)據(jù)庫技術(shù)專家

杭研大數(shù)據(jù)產(chǎn)品中心OLTP&OLAP內(nèi)核團(tuán)隊(duì)負(fù)責(zé)人。10年數(shù)據(jù)庫和存儲開發(fā)經(jīng)驗(yàn)，專注于數(shù)據(jù)庫、數(shù)倉技術(shù)和分布式系統(tǒng)架構(gòu)；累計(jì)申請10+技術(shù)發(fā)明專利 ( 已授權(quán)8個(gè) )，《MySQL 內(nèi)核：InnoDB 存儲引擎 卷1》作者之一。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝