Impala是基於Hive的大數據實時分析查詢引擎，直接使用Hive的元數據庫Metadata,意味着impala元數據都存儲在Hive的metastore中。並且impala兼容Hive的sql解析，實現了Hive的SQL語義的子集，功能還在不斷的完善中。
與Hive的關係
Impala 與Hive都是構建在Hadoop之上的數據查詢工具各有不同的側重適應面，但從客戶端使用來看Impala與Hive有很多的共同之處，如數據表元數 據、ODBC/JDBC驅動、SQL語法、靈活的文件格式、存儲資源池等。Impala與Hive在Hadoop中的關係如下圖所示。Hive適合於長時間的批處理查詢分析，而Impala適合於實時交互式SQL查詢，Impala給數據分析人員提供了快速實驗、驗證想法的大數 據分析工具。可以先使用hive進行數據轉換處理，之後使用Impala在Hive處理後的結果數據集上進行快速的數據分析。
Impala相對於Hive所使用的優化技術
- 1、沒有使用 MapReduce進行並行計算，雖然MapReduce是非常好的並行計算框架，但它更多的面向批處理模式，而不是面向交互式的SQL執行。與 MapReduce相比：Impala把整個查詢分成一執行計劃樹，而不是一連串的MapReduce任務，在分發執行計劃後，Impala使用拉式獲取 數據的方式獲取結果，把結果數據組成按執行樹流式傳遞彙集，減少的了把中間結果寫入磁盤的步驟，再從磁盤讀取數據的開銷。Impala使用服務的方式避免 每次執行查詢都需要啓動的開銷，即相比Hive沒了MapReduce啓動時間。
- 2、使用LLVM產生運行代碼，針對特定查詢生成特定代碼，同時使用Inline的方式減少函數調用的開銷，加快執行效率。
- 3、充分利用可用的硬件指令（SSE4.2）。
- 4、更好的IO調度，Impala知道數據塊所在的磁盤位置能夠更好的利用多磁盤的優勢，同時Impala支持直接數據塊讀取和本地代碼計算checksum。
- 5、通過選擇合適的數據存儲格式可以得到最好的性能（Impala支持多種存儲格式）。
- 6、最大使用內存，中間結果不寫磁盤，及時通過網絡以stream的方式傳遞。
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：實時數據分析，因爲不支持UDF，能處理的問題域有一定的限制，與Hive配合使用,對Hive的結果數據集進行實時分析。
