如何實現(xiàn)基于Impala平臺打造交互查詢系統(tǒng)

這篇文章主要介紹如何實現(xiàn)基于Impala平臺打造交互查詢系統(tǒng)，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

交互查詢特點第一個就是數(shù)據(jù)量龐大，第二個關(guān)系模式相對比較復(fù)雜，依據(jù)你的設(shè)計不同，關(guān)系模式有很多種類。還有一個就是響應(yīng)時間要求較高，對于對于絕大數(shù)要求查詢返回時間在10秒以下；依據(jù)數(shù)據(jù)量的不同選擇不同的存儲，對于百萬級數(shù)據(jù)采用MySQL,PostgreSQL，對于百萬-百億級別，傳統(tǒng)數(shù)據(jù)庫無法滿足，采用分析性數(shù)據(jù)倉庫實現(xiàn)Impala，Presto， Green Plum， Apache Drill；百億級別以上很難做大數(shù)據(jù)分析，采用離線數(shù)據(jù)倉庫，采用hive，spark。

對于BE系統(tǒng)很多實用寬表做，因為其維度很多，一個用戶經(jīng)過慢慢信息積累可能會有幾百個維度，假如對一個50個維度進(jìn)行過濾，利用寬表結(jié)合一些特殊數(shù)據(jù)結(jié)構(gòu)如倒排就會很容易實現(xiàn)。Elastic Search， Solr是搜索引擎，Click House是俄羅斯開發(fā)的一個性能比較好的系統(tǒng)，但是join支持有限， Druid在廣告平臺用的比較多。還有一種是組合模型，如Elastic Search， Solr用的比較多，典型的有Green Plum，Presto，Impala。

接下來講一下有哪些因素決定我們選擇一個平臺，首先是本身項目熟悉度，如果項目負(fù)責(zé)人對這個平臺熟悉就會選擇這個平臺。如果對項目不熟悉，就會選擇大廠背書，用大公司一樣的應(yīng)用。如果前兩者都沒有，那么就從性能和優(yōu)缺點上來評價是否適應(yīng)這個系統(tǒng)。

重點講解第三點，首先是數(shù)據(jù)量，依據(jù)系統(tǒng)數(shù)據(jù)量容量，平臺至少要達(dá)到我的最低性能指標(biāo)。還有一個就是架構(gòu)復(fù)雜度，一個系統(tǒng)最終要上線，要保證CLA，如果架構(gòu)復(fù)雜，出問題就多；因此選擇架構(gòu)相對簡單一點的。最后一個就是運(yùn)維和開銷，運(yùn)維的成本很高，因此不可能去經(jīng)常做改動；如果要改一個東西你需要熟悉一下這個平臺，那么就會影響你的選型了。

接下來講一下我們選型是如何做的，主要是考慮Impala、Presto、Greenplum。首先考慮的是數(shù)據(jù)源，我們的數(shù)據(jù)很多都是在HDFS上，所以Greenplum肯定是不適合，因為它整個是封閉的，是自己做的存儲架構(gòu)。社區(qū)環(huán)境、架構(gòu)這三者都差不多，從架構(gòu)上來說差異不大。性能方面Impala比Presto稍微好點。還有其他特性，如編程語言，C++運(yùn)行比Java要快一點，因此更趨于選擇C++寫的平臺。最后選擇了Impala。

這三個都是MPP架構(gòu)，Impala整個執(zhí)行節(jié)點都是無狀態(tài)的，因此down掉一個節(jié)點，再啟動沒有問題。Impala兼容hive存儲，還有一些點如Apache頂級項目、成熟社區(qū)、多種數(shù)據(jù)源格式兼容、高效的查詢性能都是我們考慮特有的選型因素。

接下來講一下Impala架構(gòu)，其兼容多種數(shù)據(jù)源就是metastore直接對接各種DB，利用catalogd提供元數(shù)據(jù)服務(wù)?？梢灾苯舆BDB也可以通過catalogd，一般是利用hive里的metastore獲取數(shù)據(jù)。Impala高效的原因是其將原始數(shù)據(jù)緩存下來，catalogd啟動會瀏覽緩存獲取數(shù)據(jù)。它有一個statestored服務(wù)，是一個發(fā)布訂閱服務(wù)，所有狀態(tài)以及輪轉(zhuǎn)都是在statestored服務(wù)中進(jìn)行。左邊是impala的執(zhí)行節(jié)點，所有查詢都是發(fā)完這些節(jié)點，節(jié)點執(zhí)行后會下發(fā)到所有相關(guān)節(jié)點上去，整個impala是無狀態(tài)的，所有的連接者都像是一個協(xié)調(diào)者。

Catalogd是元數(shù)據(jù)服務(wù)，其主要的問題是你做select時，impala也會緩存一部分?jǐn)?shù)據(jù)，它不會進(jìn)入catalogd服務(wù)，但是做DDL操作會應(yīng)用catalogd服務(wù)。Statestored(sub/pub  )有很多topic，所有的impala節(jié)點去訂閱這些topic上的相關(guān)消息，Statestored實際是在很多topic上做了一個消息訂閱。Impala節(jié)點有SQL解析、執(zhí)行計劃生成，還有是數(shù)據(jù)查詢、聚合、結(jié)果返回。

上圖是一個查詢進(jìn)來，各個節(jié)點是一個怎么樣的協(xié)調(diào)方式。如一個查詢進(jìn)入這個節(jié)點，這個節(jié)點就是Query Planner，負(fù)責(zé)生成執(zhí)行計劃，將計劃向周邊節(jié)點傳輸，最后將結(jié)果返回Query Planner，如果有聚合，先聚合然后返回總的Query Planner上，然后進(jìn)行相關(guān)聚合將結(jié)果返回。

Impala性能優(yōu)勢有元數(shù)據(jù)緩存，而且impala會緩存HDFS上相應(yīng)表數(shù)據(jù)在blog里的信息，因此查詢時會有一個本地讀，判斷元數(shù)據(jù)是否在本地，通過本地轉(zhuǎn)讀方式，log才能連接數(shù)據(jù)。第二點并行計算，Query Planner生成執(zhí)行計劃將其發(fā)往周邊節(jié)點，然后匯聚。第三個利用codegen技術(shù)，有些依據(jù)執(zhí)行環(huán)境生成執(zhí)行代碼，會對性能提升很大。再一個就是很多算子下推，如果追求高性能不許實現(xiàn)算子下推，將存儲層與計算層交互變得更小，在底層過濾而不是在計算層，這樣對平臺整體性能提升較大。

broadcast join在大表關(guān)聯(lián)時，將小表緩存到所有節(jié)點上，然后返回數(shù)據(jù)做聚合。partition join應(yīng)對兩張表都是大數(shù)據(jù)表，如一個事件表積累上百億數(shù)據(jù)，而用戶有五億，那么就不能通過broadcast join綁定到所有節(jié)點上，因此在每個節(jié)點做一些分區(qū)join操作然后在到上面去。還有一個CBO，目前來說還不是很準(zhǔn)，有時會偏差很大。有并行計算就有并行聚合，數(shù)據(jù)生成前提前聚合，依據(jù)group by 的column 進(jìn)行聚合的合并操作。

接下來介紹下impala支持哪些存儲引擎，常用的有hdfs，還有kudu，為了解決HDFS和HBASE進(jìn)行交互而產(chǎn)生的一個產(chǎn)品。Hbase主要是一個kb查詢，但是如果有大量掃描時性能很差，而大批量掃描是HDFS的強(qiáng)項，但是做不了kb查詢。Alluxio是一個文件記錄換緩存，底層也可以對接HDFS，支持多級緩存。我們做Alluxio主要是應(yīng)對熱力數(shù)據(jù)，以前使用緩存解決這個問題。

如果要使用impala平臺如何實現(xiàn)對接呢，首先它有整個授權(quán)和認(rèn)證機(jī)制。認(rèn)證可以對接kerberos、LDAP、Audit log，只有身份認(rèn)證了才能訪問系統(tǒng)。授權(quán)通過Apache Sentry，粒度有：database、table、column，權(quán)限：select、insert、all配置開啟(authorization_policy_provider_class=org.apache.sentry.provider.file.Local G roup R esource A uthorization P rovider)。這些是你如果要上線必須要做的一些事情。

對于一個平臺有很多用戶在上面做一些任務(wù)，需要進(jìn)行資源管理。目前采用Admission Control機(jī)制，他能保證每一個impala節(jié)點上都有直接用戶配置，每一個隊列可以設(shè)置資源總量，也可以設(shè)置每一個SQL的資源大小。這個配置是針對impala節(jié)點，如給一個用戶設(shè)置300G，有100個節(jié)點，那么每個節(jié)點只分配2-3G，超過這個限額也是要被禁止的。資源隔離既要考慮總的也要考慮單獨的，Impala節(jié)點是通過statestored的impalad-statistics topic項同步信息，由于statestored通過心跳與impalad 保持通信，這個資源信息實際上有些延遲;目前配置中，只有內(nèi)存項有實際效果，vcore沒有實現(xiàn)隔離，隊列名配置如果與認(rèn)證用戶名相同，該用戶提交的SQL自動分配到該隊列。

Impala有個web端，雖然簡單但很有用，整個問題解決、定位經(jīng)常用到。每一個組件都會提供一個web端，分配相應(yīng)的端口，基本信息有集群節(jié)點、Catalog信息、內(nèi)存信息、Query信息。Web端能使此案節(jié)點內(nèi)存消耗查看（每個對壘內(nèi)存消耗、每個查詢在該點內(nèi)存消耗），該節(jié)點查詢分析（查詢分析、SQL診斷、異常查詢終止），還有就是Metrics信息查看。上圖是我們配的一些隊列，每一個隊列消耗資源情況等。用impala做join分析，將每個SQL中執(zhí)行計劃都具體化了，界面上的標(biāo)簽如query、summary、memory等都可以做SQL分析。

講了impala的優(yōu)點、特點、如何用，但是基于開源平臺，也是有很多缺陷。第一個Catalogd&statestored服務(wù)單點，但是好在對查詢不受影響，如果Catalogd掛掉，元數(shù)據(jù)更新就不會同步到整個impala節(jié)點。Statestored掛掉，對于更新也不會同步，只會保掛掉之前的信息。第二個就是web信息不持久，顯示的信息都是存在歷史信息中，如果impala重啟后信息就會沒有了。資源隔離不精準(zhǔn)，還有就是底層存儲不能區(qū)分用戶，還有就是負(fù)載均衡，每一個impala都可以對接SQL，但是有100個impala如何接入不好解決，因此對impala實現(xiàn)haproxy。還有與hive元數(shù)據(jù)同步需要手動操作，impala是緩存元數(shù)據(jù)，通過HDFS操作是不會感知這種操作的。

有缺陷就有改進(jìn)，首先基于ZK的load balance，因為impala是和hive綁在一起，hive的server是基于ZK，將你需要訪問的impala的uri寫入一個維度中去，hive原生就是基于ZK的多維節(jié)點訪問。第二個就是管理服務(wù)器，因為impala頁面的信息不會保存，利用管理服務(wù)器保存這些東西，排查時在管理服務(wù)器上查，不會因為你impala節(jié)點多而信息不保存。細(xì)粒度權(quán)限&代理，通過impala訪問HDFS實現(xiàn)底層權(quán)限控制。Json格式，這個就是偏應(yīng)用需求。兼容ranger權(quán)限管理，因為我們整個項目權(quán)限管理是基于ranger的。批量元數(shù)據(jù)刷新，也是實際應(yīng)用中出現(xiàn)的問題，有時會一次改好幾十個表，如果每次都刷新會很麻煩。元數(shù)據(jù)同步，改造hive和impala，每次hive改變，將改變寫入中間層，impala去獲取中間層實現(xiàn)同步。元數(shù)據(jù)過濾，數(shù)據(jù)量很龐大時，其實交互式查詢很大一部分表是用不到的，而impala只對某一部分有需求，因此通過正則表達(dá)式過濾掉不必要的數(shù)據(jù)。對接ElasticSearch查詢，將ES涉及的算子下推過去，如多維過濾查詢，根據(jù)倒排屬性比hash將數(shù)據(jù)聚合要快。

Impala應(yīng)用場景介紹，上圖是一個部門大數(shù)據(jù)平臺架構(gòu)，從kafka數(shù)據(jù)到HDFS，結(jié)構(gòu)化到半結(jié)構(gòu)化這是數(shù)據(jù)的接入。經(jīng)過數(shù)據(jù)清洗，再接入到上層，上層應(yīng)用了ES存儲，最上面就直接用impala來進(jìn)行查詢，這基本就是分析系統(tǒng)的框架。

上面是我們的一個BI產(chǎn)品，叫有數(shù)。底層也對接了impala平臺，這是一個數(shù)據(jù)分析報表平臺，將圖表與地圖上的數(shù)據(jù)進(jìn)行對接。將結(jié)構(gòu)化數(shù)據(jù)或非結(jié)構(gòu)化數(shù)據(jù)直接寫入hive，然后通過impala去感知，實現(xiàn)元數(shù)據(jù)同步，用戶直接通過impala去查詢。需要考慮問題有元數(shù)據(jù)同步問題，ETL寫入數(shù)據(jù)impala無感知，依賴元數(shù)據(jù)同步；數(shù)據(jù)實時性問題，避免大量小文件導(dǎo)致NN不穩(wěn)定，每次寫文件的batch不能太小。還有一個方案是利用kudu解決小文件問題，將實時數(shù)據(jù)往kudu里寫，將kudu和hdfs實現(xiàn)聯(lián)查，在impala上既能看到kudu的表也能看到hdfs的表。

以上是“如何實現(xiàn)基于Impala平臺打造交互查詢系統(tǒng)”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！