環境
虛擬機：VMware 10
Linux版本：CentOS-6.5-x86_64
客戶端：Xshell4
FTP：Xftp4
jdk8
CM5.4
一、Impala
Impala是基於Hive的大數據實時分析查詢引擎，直接使用Hive的元數據庫Metadata,意味着impala元數據都存儲在Hive的metastore中。並且impala兼容Hive的sql解析，實現了Hive的SQL語義的子集，功能還在不斷的完善中。
基於內存運算，內存要求大；
二、Impala與Hive區別
相同點：
數據存儲：使用相同的存儲數據池都支持把數據存儲於HDFS, HBase。
元數據：兩者使用相同的元數據。
SQL解釋處理：比較相似都是通過詞法分析生成執行計划。
不同點：
執行計划：
Hive: 依賴於MapReduce執行框架，執行計划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個Query會 被編譯成多輪MapReduce，則會有更多的寫中間結果。由於MapReduce執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。
Impala: 把執行計划表現為一棵完整的執行計划樹，可以更自然地分發執行計划到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的 map->reduce模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。
數據流：
Hive: 采用推的方式，每一個計算節點計算完成后將數據主動推給后續節點。
Impala: 采用拉的方式，后續節點通過getNext主動向前面節點要數據，以此方式數據可以流式的返回給客戶端，且只要有1條數據被處理完，就可以立即展現出來，而不用等到全部處理完成，更符合SQL交互式查詢使用。
內存使用：
Hive: 在執行過程中如果內存放不下所有數據，則會使用外存，以保證Query能順序執行完。每一輪MapReduce結束，中間結果也會寫入HDFS中，同樣由於MapReduce執行架構的特性，shuffle過程也會有寫本地磁盤的操作。
Impala: 在遇到內存放不下數據時，當前版本1.0.1是直接返回錯誤，而不會利用外存，以后版本應該會進行改進。這使用得Impala目前處理Query會受到一 定的限制，最好還是與Hive配合使用。Impala在多個階段之間利用網絡傳輸數據，在執行過程不會有寫磁盤的操作（insert除外）。
調度：
Hive: 任務調度依賴於Hadoop的調度策略。
Impala: 調度由自己完成，目前只有一種調度器simple-schedule，它會盡量滿足數據的局部性，掃描數據的進程盡量靠近數據本身所在的物理機器。調度器 目前還比較簡單，在SimpleScheduler::GetBackend中可以看到，現在還沒有考慮負載，網絡IO狀況等因素進行調度。但目前 Impala已經有對執行過程的性能統計分析，應該以后版本會利用這些統計信息進行調度吧。
容錯：
Hive: 依賴於Hadoop的容錯能力。
Impala: 在查詢過程中，沒有容錯邏輯，如果在執行過程中發生故障，則直接返回錯誤（這與Impala的設計有關，因為Impala定位於實時查詢，一次查詢失敗， 再查一次就好了，再查一次的成本很低）。但從整體來看，Impala是能很好的容錯，所有的Impalad是對等的結構，用戶可以向任何一個 Impalad提交查詢，如果一個Impalad失效，其上正在運行的所有Query都將失敗，但用戶可以重新提交查詢由其它Impalad代替執行，不 會影響服務。對於State Store目前只有一個，但當State Store失效，也不會影響服務，每個Impalad都緩存了State Store的信息，只是不能再更新集群狀態，有可能會把執行任務分配給已經失效的Impalad執行，導致本次Query失敗。
適用面：
Hive: 復雜的長時間批處理查詢任務，數據轉換任務。
Impala：實時交互式SQL查詢，因為不支持UDF，能處理的問題域有一定的限制。
Impala給數據分析人員提供了快速實驗、驗證想法的大數 據分析工具。可以先使用hive進行數據轉換處理，之后使用Impala在Hive處理后的結果數據集上進行快速的數據分析。
三、架構
1.Impala Daemon
Impala的核心組件是運行在各個節點上面的impalad這個守護進程（Impala daemon），它負責讀寫數據文件，接收從impala-shell、Hue、JDBC、ODBC等接口發送的查詢語句，並行化查詢語句和分發工作任務到Impala集群的各個節點上，同時負責將本地計算好的查詢結果發送給協調器節點（coordinator node）。
你可以向運行在任意節點的Impala daemon提交查詢，這個節點將會作為這個查詢的協調器（coordinator node），其他節點將會傳輸部分結果集給這個協調器節點。由這個協調器節點構建最終的結果集。在做實驗或者測試的時候為了方便，我們往往連接到同一個Impala daemon來執行查詢，但是在生產環境運行產品級的應用時，我們應該循環（按順序）的在不同節點上面提交查詢，這樣才能使得集群的負載達到均衡。
Impala daemon不間斷的跟statestore進行通信交流，從而確認哪個節點是健康的能接收新的工作任務。它同時接收catalogd daemon（從Impala 1.2之后支持）傳來的廣播消息來更新元數據信息，當集群中的任意節點create、alter、drop任意對象、或者執行INSERT、LOAD DATA的時候觸發廣播消息。
2.Impala Statestore
Impala Statestore檢查集群各個節點上Impala daemon的健康狀態，同時不間斷地將結果反饋給各個Impala daemon。這個服務的物理進程名稱是statestored，在整個集群中我們僅需要一個這樣的進程即可。如果某個Impala節點由於硬件錯誤、軟件錯誤或者其他原因導致離線，statestore就會通知其他的節點，避免其他節點再向這個離線的節點發送請求。
由於statestore是當集群節點有問題的時候起通知作用，所以它對Impala集群並不是有關鍵影響的。如果statestore沒有運行或者運行失敗，其他節點和分布式任務會照常運行，只是說當節點掉線的時候集群會變得沒那么健壯。當statestore恢復正常運行時，它就又開始與其他節點通信並進行監控。
3.Impala Catalog
Imppalla catalog服務將SQL語句做出的元數據變化通知給集群的各個節點，catalog服務的物理進程名稱是catalogd，在整個集群中僅需要一個這樣的進程。由於它的請求會跟statestore daemon交互，所以最好讓statestored和catalogd這兩個進程在同一節點上。
catalog服務減少了REFRESH和INVALIDATE METADATA語句的使用。在之前的版本中，當在某個節點上執行了CREATE DATABASE、DROP DATABASE、CREATE TABLE、ALTER TABLE、或者DROP TABLE語句之后，需要在其它的各個節點上執行命令INVALIDATE METADATA來確保元數據信息的更新。同樣的，當你在某個節點上執行了INSERT語句，在其它節點上執行查詢時就得先執行REFRESH table_name這個操作，這樣才能識別到新增的數據文件。
四、安裝
使用CM安裝
1、選擇服務
2、選擇依賴
3、角色分配
參考：