本文來自網易雲社群
原創： 蔣鴻翔 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
【推薦】 大資料應用除了在體育項目中，還有這些切身感受得到的應用案例