本文根據網易大數據蔣鴻翔老師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的表。
——END——