一、概述 

1.1簡介

Impala是由Cloudera公司開發的新型查詢系統，能夠對存儲在HDFS、HBase以及S3上的數據進行快速的交互式SQL查詢。另外，impala與Hive使用了統一的存儲系統、同樣的元數據庫、SQL語法(Hive SQL)、ODBC驅動和用戶交互接口(Hue)，Impala對實時的或者面向批處理的查詢提供了一個統一的平臺，Impala在性能上比Hive高出3~30倍。

Impala是用于查詢大數據的工具的補充，Impala不是取代構建在MapReduce之上的批處理框架，比如Hive。Hive和其他的基于MapReduce的框架適合處理長時間運行的批處理作業，比如涉及到批處理的ETL類型的作業。

1.2優勢

• 使用的是數據科學家和分析師熟悉的SQL接口
• 能查詢大數據集
• 是集群環境中的分布式查詢，便于擴展和使用廉價商用硬件
• 能夠在不同的分析引擎之前共享數據，比如可以通過pig寫數據，使用Hive轉換數據，再使用impala查詢數據。impala能夠讀寫hive中的表，使用impala對Hive生成的數據進行分析，實現簡單的數據交換
• 單一系統用于大數據處理和分析，因此可以避免成本高昂的建模和ETL.

1.3主要特點

• 支持Hive查詢語言（HiveQL）最常見的SQL-92功能，包括 SELECT, JOIN和聚合函數
• 支持HDFS, HBase和S3存儲, 包括:
• HDFS 文件格式: delimited text files, Parquet, Avro, SequenceFile,和 RCFile.
• 壓縮: Snappy, GZIP, Deflate, BZIP.
• 常見的數據訪問接口，包括JDBC driver、ODBC driver
• 支持impala-shell命令行接口
• Kerberos授權

二、Impala架構

為了避免延遲，impala繞過MapReduce，采用了與商用并行關系數據庫類似的分布式查詢引擎，可以直接與HDFS和HBase進行交互查詢，性能上比Hive要快。

Impala server 是一個分布式的大規模并行處理(MPP)的數據庫引擎， 它由運行在集群中特定主機上的不同守護進程組成。其架構圖如下圖所示：

 

2.1Impala Daemon

這個進程是運行在集群每個DataNode節點上的守護進程，是impala的核心組件。在每個節點上這個進程的名字稱為impalad。主要負責讀寫數據，接受 impala-shell，Hue, JDBC或者ODBC的查詢請求，與集群中的其他節點分布式并行工作，并將本節點的查詢結果返回給中心協調者節點(central coordinator)。

我們可以向運行在DataNode上的任何impalad進程提交一個查詢，提交查詢的這個節點將作為這個查詢的“協調者節點”(coordinator)為這個查詢提供服務。其他節點的運算結果會被傳輸到協調者節點，協調者節點將最終的運算結果返回。當使用 mpala-shell命令進行功能性測試的時候,為了方便起見，我們總是會連接到同一個節點上的impalad。但是對于生產環境中的impala集群而言，必須要考慮到各個節點的負載均衡，建議使用JDBC/ODBC接口以輪詢(round-robin)的方式提交到不同的impalad進程上。

為了了解其他節點的健康狀況和負載，Impalad進程會一直與 statestore保持通信，用以確保哪個節點是健康的并且可以接受任務的。

當impala集群中創建，修改或者刪除了對象，或者進行了INSERT/LOAD DATAT操作，catalogd進程會向所有的節點廣播消息，以保證每個impalad節點都能夠及時地了解整個集群中對象元數據的最新狀態。后臺進程間的通信最大限度的降低了對 REFRESH/INVALIDATE METADATA命令的依賴。(但是對于和impala1.2版本之前的節點通信，還是需要顯示指定)

對impala 2.9或者更高版本，可以控制哪一個節點為查詢協調器( query coordinators ),也可以控制哪一個節點為查詢協調器(query executors), 能夠提高大型集群上高并發工作負載的可擴展性。

2.2Impala Statestore

statestore檢查集群中impalad進程節點的健康狀況，并不斷地將健康狀況結果轉發給所有的impalad進程節點。statestore進程的名稱為statestored。一個impala集群只需要一個statestored進程，如果impala節點由于硬件故障、網絡錯誤、軟件問題或者其他的原因導致節點不可用，statestore將確保這條信息及時地傳達到所有的impalad進程節點上，當有新的查詢請求時 ,impalad進程節點將不會把查詢請求放松到不可用的節點上。

由于statestore的目的是在集群故障時對impalad進程節點同步信息，所以對于一個正常運行的impala集群來說，它并不是一個關鍵進程。如果statestore不可用，impalad進程節點之間仍然可以相互協調正常對外提供分布式查詢。在statestore不可用的情況下，impalad進程節點失敗，只是會讓集群不再那么強健。當statestore恢復正常時，它重新與impalad進程節點建立通信，恢復對集群的監控功能。

對于負載平衡和高可用性都適用于impalad守護進程。statestore和catalog進程對高可用性沒有特殊要求，因為即便這些守護進程存在問題，也不會導致數據丟失。如果這些守護進程因中斷而變得不可用，則可以停止impala服務，刪除impala StateStore和impala Catalog角色，將角色添加到不同的主機上，并重新啟動impala服務。

2.3Impala Catalog Service

當impala集群中執行的SQL語句會引起元數據變化時，catalog服務會將這些變化推送到其他的impalad進程節點上。catalog服務對應的進程名稱為catalogd，一個impala集群只需要一個catalogd進程 。由于所有的請求都是通過statestore進程發送過來的，所以建議讓statestore和catalog運行在同一個節點上。

catalog服務大大地減少了對 REFRESH / INVALIDATE METADATA 語句的元數據同步的需求。在創建和刪除表的過程中，catalogd進程負責連接元數據庫并進行元數據更新操作，從而確保不必執行REFRESH / INVALIDATE METADATA這樣的元數據同步語句。但是，如果通過Hive執行了創建表 、加載數據等操作，則在impala中執行查詢之前需要先執行 REFRESH或者INVALIDATE METADATA 命令。

三、Impala查詢的執行過程 

3.1Impala查詢過程圖

 

3.2Impala執行查詢的具體過程

第0步，當用戶提交查詢前，Impala先創建一個負責協調客戶端提交的查詢的Impalad進程，該進程會向Impala State Store提交注冊訂閱信息，State Store會創建一個statestored進程，statestored進程通過創建多個線程來處理Impalad的注冊訂閱信息。

第1步，用戶通過CLI客戶端提交一個查詢到impalad進程，Impalad的Query Planner對SQL語句進行解析，生成解析樹；然后，Planner把這個查詢的解析樹變成若干PlanFragment，發送到Query Coordinator

第2步，Coordinator通過從MySQL元數據庫中獲取元數據，從HDFS的名稱節點中獲取數據地址，以得到存儲這個查詢相關數據的所有數據節點。

第3步，Coordinator初始化相應impalad上的任務執行，即把查詢任務分配給所有存儲這個查詢相關數據的數據節點。

第4步，Query Executor通過流式交換中間輸出，并由Query Coordinator匯聚來自各個impalad的結果。

第5步，Coordinator把匯總后的結果返回給CLI客戶端。

四、Impala與Hive的比較 

4.1Impala與Hive對比圖

 

4.2Hive與Impala的相同點

• Hive與Impala使用相同的存儲數據池，都支持把數據存儲于HDFS和HBase中

• Hive與Impala使用相同的元數據

• Hive與Impala中對SQL的解釋處理比較相似，都是通過詞法分析生成執行計劃

4.3Hive與Impala的不同點

• Hive適合于長時間的批處理查詢分析，而Impala適合于實時交互式SQL查詢

• Hive依賴于MapReduce計算框架，Impala把執行計劃表現為一棵完整的執行計劃樹，直接分發執行計劃到各個Impalad執行查詢

• Hive在執行過程中，如果內存放不下所有數據，則會使用外存，以保證查詢能順序執行完成，而Impala在遇到內存放不下數據時，不會利用外存，所以Impala目前處理查詢時會受到一定的限制