Impala的定位是一種新型的MPP查詢引擎，但是它又不是典型的MPP類型的SQL引擎，提到MPP數據庫首先想到的可能是GreenPlum，它的每一個節點完全獨立，節點直接不共享數據，節點之間的信息傳遞全都通過網絡實現。而Impala可以說是一個MPP計算引擎，它需要處理的數據存儲在HDFS、Hbase或者Kudu之上，這些存儲引擎都是獨立於Impala的，可以稱之為第三方存儲引擎，Impala使用MPP的思想實現了計算。
對於每一個Impala執行的SQL，可能同時在多個工作節點上運行計算，每一個節點執行查詢任務的一部分，然后通過網絡通信傳遞給下一個子任務，中間數據盡可能的不落地（寫磁盤，無論是本地還是第三方存儲引擎）。之所以Impala能夠提供較高性能的查詢服務，最根本的原因就在於這兩點：中間數據不落地；任務盡可能並行化。當然，還有一些實現細節也是非常重要的，本文就從一個SQL的執行過程來詳細介紹Impala是如何處理查詢的。
名詞解釋
- Impala：一個SQL查詢引擎
- HDFS：分布式數據存儲引擎
- catalogd：impala系統中的元數據服務節點
- statestored：impala系統中的消息同步節點
- impalad：impala系統中的任務執行節點
- coordinator：impalad節點中的協調者模塊，對外提供查詢接口，包括beeswax和HiveServer2接口
- backend：impalad節點中任務執行模塊，提供執行任務的接口
- BE：impalad代碼上划分的frontend部分，使用JAVA實現
- FE：impalad代碼上划分的backend部分，使用C++實現
- beeswax接口：impalad提供的一種SQL查詢接口。
- HiveServer2接口：impalad提供的一種兼容HiveServer2的接口。
- Analyser：Impala FE中實現的SQL解析器。
- Planner：Impala FE中實現的SQL執行計划生成器。
- PlanNode：SQL解析得到的邏輯執行計划中的節點基類，具體類型包括ScanNode、AggregationNode、HashJoinNode等。
- Fragment：SQL生成的分布式執行計划中的一個子任務，它包括執行計划的一個子樹。
- ExchangeNode：比較特殊的一種PlanNode，處理前一個Fragment傳遞過來的數據。
- DataStreamSink：它不是PlanNode，用於傳輸當前Fragment輸出數據到不同的節點。
系統架構
在真正介紹Impala查詢執行流程之前，需要先貼上一張Impala的架構圖鎮樓，下圖中描述了一個SQL查詢的執行流程。
從上圖中看出，可以首先大體上描述下一個SQL從提交到獲取查詢結果是經歷了哪些步驟（下面的步驟和上圖中步驟不一一對應）：
- 1、客戶端提交任務：客戶端通過beeswax或者HiveServer2接口發送一個SQL查詢請求到impalad節點，查詢包括一條SQL和相關的configuration信息（只對本次查詢生效），查詢接口提供同步和異步的方式執行，兩種接口都會返回一個queryId用於之后的客戶端操作。
- **2、查詢解析和分析：**SQL提交到impalad節點之后交由FE模塊處理，由Analyser依次執行SQL的詞法分析、語法分析、語義分析、查詢重寫等操作，生成該SQL的Statement信息。
- 3、單機執行計划生成：根據上一步生成的Statement信息，由Planner生成單機的執行計划，該執行計划是有PlanNode組成的一棵樹，這個過程中也會執行一些SQL優化，例如Join順序改變、謂詞下推等。
- 4、分布式執行計划生成：由Planner將單機執行計划轉換成分布式並行物理執行計划，物理執行計划由一個個的Fragment組成，Fragment之間有數據依賴關系，處理過程中需要在原有的執行計划之上加入一些ExchangeNode和DataStreamSink信息等。
- 5、任務調度和分發：由BE處理生成的分布式物理執行計划，將Fragment根據數據分區信息發配到不同的Impalad節點上執行。Impalad節點接收到執行Fragment請求交由Backend模塊處理Fragment的執行。
- 6、子任務執行：每一個Fragment的執行輸出通過DataStreamSink發送到下一個Fragment，由下一個Fragment的ExchangeNode接收，Fragment運行過程中不斷向coordinator節點匯報當前運行狀態。
- 7、結果匯總：查詢的SQL通常情況下需要有一個單獨的Fragment用於結果的匯總，它只在coordinator節點運行，將多個backend的最終執行結果匯總，轉換成ResultSet信息。
- 8、客戶端查詢結果：客戶端調用獲取ResultSet的接口，讀取查詢結果。
- 9、關閉查詢：客戶端調用CloseOperation關閉本次查詢，標志着本次查詢的結束。
查詢實例
本文下面的查詢流程解析將使用如下介紹的一個關於在線購物系統的數據作為實例，本查詢實例中包含了三個表，查詢SQL如下：
select t1.goods_id, t1.title, count(1) as ba from
items t1
join
item_orders t2
on t1.goods_id = t2.goods_id
where
t2.day >= '2017-04-29'
and
t2.day <= '2017-05-01'
and
t1.cat1_id in ('438', '437', '440', '381')
and
t2.order_id in (select order_id from orders where order_status in ('1','2'))
group by
t1.goods_id, t1.title
having
count(distinct t2.buy_account) > 1000
order by ba desc
limit 30
使用的三個表如下：
- items：商品詳細信息表，即商品維度表，記錄數100W左右。
- item_orders：每日增加的訂單記錄，事實表，每日新增記錄大約為100W。
- orders：訂單維度表，包含每一個訂單實時的信息，記錄數為1億。
該查詢實現這樣的需求：查詢2017年五一三天假期中滿足一定條件購買次數TOP 30的商品，條件為：商品的類目屬於指定四類，商品的訂單狀態是1、2兩種並且這三天購買的人數大於1000。
這個查詢是一個典型的OLAP分析查詢，從SQL結構上看，包括了多個join，子查詢，過濾信息和聚合操作。
總結
本文主要根據Impala系統架構從宏觀角度上分析了一個OLAP查詢在Impala執行的流程，並且附上了再具體業務查詢中遇到的一個典型的OLAP查詢實例，后面我們將根據這個例子詳細解析Impala處理該查詢的幾個關聯步驟，未完待續。