定位:

HIVE：長時間的批處理查詢分析

impala:實時互動式SQL查詢

impala優缺點
優點：
1. 生成執行計劃樹，不用多次啟動job造成多餘開銷，並且減少中間結果資料寫入磁碟，執行速度快
2. 不佔用yarn的資源
3.
缺點：
1. 不支援Date型別
2. 與HIVE資料不同步，需要手工重新整理
3. 排序異常
4. 不支援多個count(distinct)
5. 不支援使用者定義函式UDF
6. 不支援查詢期的容錯

Impala與Hive的異同
相同點：
資料儲存：使用相同的儲存資料池都支援把資料儲存於HDFS, HBase。
元資料：兩者使用HIVE的元資料。
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: 在遇到記憶體放不下資料時，當前版本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：實時資料分析，因為不支援UDF，能處理的問題域有一定的限制，與Hive配合使用,對Hive的結果資料集進行實時分析。