本文來自網易雲社區

原創： 蔣鴻翔 DataFunTalk

本文根據網易大數據蔣鴻翔老師DataFun Talk——“大數據從底層處理到數據驅動業務”中分享的《基於Impala平臺打造交互查詢系統》編輯整理而成，在未改變原意的基礎上稍做整理。

以上是今天的內容大綱，第一個講一下交互式查詢的特點，在大數據平臺有很多查詢平臺可以選擇，第二個講一下依據項目如何選擇平臺，選型因素是什麽。第三個講一下Impala基本介紹，以及在Impala上的改進。接下來是impala的應用場景，最後介紹下Impala底層數據流，應用場景解析以及存在的一些問題。

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

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

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

重點講解第三點，首先是數據量，依據系統數據量容量，平臺至少要達到我的最低性能指標。還有一個就是架構復雜度，一個系統最終要上線，要保證CLA，如果架構復雜，出問題就多；因此選擇架構相對簡單一點的。最後一個就是運維和開銷，運維的成本很高，因此不可能去經常做改動；如果要改一個東西你需要熟悉一下這個平臺，那麽就會影響你的選型了。

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

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

接下來講一下Impala架構，其兼容多種數據源就是metastore直接對接各種DB，利用catalogd提供元數據服務。可以直接連DB也可以通過catalogd，一般是利用hive裏的metastore獲取數據。Impala高效的原因是其將原始數據緩存下來，catalogd啟動會瀏覽緩存獲取數據。它有一個statestored服務，是一個發布訂閱服務，所有狀態以及輪轉都是在statestored服務中進行。左邊是impala的執行節點，所有查詢都是發完這些節點，節點執行後會下發到所有相關節點上去，整個impala是無狀態的，所有的連接者都像是一個協調者。

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

上圖是一個查詢進來，各個節點是一個怎麽樣的協調方式。如一個查詢進入這個節點，這個節點就是Query Planner，負責生成執行計劃，將計劃向周邊節點傳輸，最後將結果返回Query Planner，如果有聚合，先聚合然後返回總的Query Planner上，然後進行相關聚合將結果返回。

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

broadcast join在大表關聯時，將小表緩存到所有節點上，然後返回數據做聚合。partition join應對兩張表都是大數據表，如一個事件表積累上百億數據，而用戶有五億，那麽就不能通過broadcast join綁定到所有節點上，因此在每個節點做一些分區join操作然後在到上面去。還有一個CBO，目前來說還不是很準，有時會偏差很大。有並行計算就有並行聚合，數據生成前提前聚合，依據group by 的column 進行聚合的合並操作。

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

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

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

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

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

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

Impala應用場景介紹，上圖是一個部門大數據平臺架構，從kafka數據到HDFS，結構化到半結構化這是數據的接入。經過數據清洗，再接入到上層，上層應用了ES存儲，最上面就直接用impala來進行查詢，這基本就是分析系統的框架。

上面是我們的一個BI產品，叫“網易有數”。底層也對接了impala平臺，這是一個數據分析報表平臺，將圖表與地圖上的數據進行對接。將結構化數據或非結構化數據直接寫入hive，然後通過impala去感知，實現元數據同步，用戶直接通過impala去查詢。需要考慮問題有元數據同步問題，ETL寫入數據impala無感知，依賴元數據同步；數據實時性問題，避免大量小文件導致NN不穩定，每次寫文件的batch不能太小。還有一個方案是利用kudu解決小文件問題，將實時數據往kudu裏寫，將kudu和hdfs實現聯查，在impala上既能看到kudu的表也能看到hdfs的表（如欲了解更多可搜索“網易大數據”）。

網易有數：企業級大數據可視化分析平臺，具有全面的安全保障、強大的大數據計算性能、先進的智能分析、便捷的協作分享等特性，點擊可免費使用。

作者介紹

蔣鴻翔，2011年加入網易，網易資深數據庫內核 & 網易猛獁大數據平臺技術專家，《MySQL內核：InnoDB存儲引擎 卷1》作者之一，網易數據庫內核和數據倉庫平臺負責人，長期從事數據庫內核技術和大數據平臺底層技術開發，主導網易數據庫內核整體技術方案和大數據平臺先進技術調研和實現，先後主導了內部MySQL分支InnoSQL、HBase、自研時序數據庫、自研實時數據倉庫等各種不同的平臺，具有豐富的數據庫內核和大數據平臺相關經驗。

相關文章：
【推薦】 使用QUIC
【推薦】 大數據應用除了在體育項目中，還有這些切身感受得到的應用案例

基於Impala平臺打造交互查詢系統