最近讀的幾篇關於impala的文章，這篇良心不錯：https://www.biaodianfu.com/impala.html（本文截取部分內容）
Impala是Cloudera公司主導開發的新型查詢系統，它提供SQL語義，能查詢存儲在Hadoop的HDFS和HBase中的PB級大數據。已有的Hive系統雖然也提供了SQL語義，但由於Hive底層執行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的交互性。相比之下，Impala的最大特點也是最大賣點就是它的快速。
Impala相對於Hive所使用的優化技術
- 沒有使用MapReduce進行並行計算，雖然MapReduce是非常好的並行計算框架，但它更多的面向批處理模式，而不是面向交互式的SQL執行。與MapReduce相比：Impala把整個查詢分成一執行計劃樹，而不是一連串的MapReduce任務，在分發執行計劃後，Impala使用拉式獲取數據的方式獲取結果，把結果數據組成按執行樹流式傳遞彙集，減少了把中間結果寫入磁盤的步驟，再從磁盤讀取數據的開銷。Impala使用服務的方式避免每次執行查詢都需要啓動的開銷，即相比Hive沒了MapReduce啓動時間。
- 使用LLVM產生運行代碼，針對特定查詢生成特定代碼，同時使用Inline的方式減少函數調用的開銷，加快執行效率。
- 充分利用可用的硬件指令（2）。
- 更好的IO調度，Impala知道數據塊所在的磁盤位置能夠更好的利用多磁盤的優勢，同時Impala支持直接數據塊讀取和本地代碼計算checksum。
- 通過選擇合適的數據存儲格式可以得到最好的性能（Impala支持多種存儲格式）。
- 最大使用內存，中間結果不寫磁盤，及時通過網絡以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: 在遇到內存放不下數據時，當前版本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的結果數據集進行實時分析。
Impala的優缺點
優點：
- 支持SQL查詢，快速查詢大數據。
- 可以對已有數據進行查詢，減少數據的加載，轉換。
- 多種存儲格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。
- 可以與Hive配合使用。
缺點：
- 不支持用戶定義函數UDF。
- 不支持text域的全文搜索。
- 不支持Transforms。
- 不支持查詢期的容錯。
- 對內存要求高。
在Cloudera的測試中，Impala的查詢效率比Hive有數量級的提升。從技術角度上來看，Impala之所以能有好的性能，主要有以下幾方面的原因。
- Impala不需要把中間結果寫入磁盤，省掉了大量的I/O開銷。
- 省掉了MapReduce作業啓動的開銷。MapReduce啓動task的速度很慢（默認每個心跳間隔是3秒鐘），Impala直接通過相應的服務進程來進行作業調度，速度快了很多。
- Impala完全拋棄了MapReduce這個不太適合做SQL查詢的範式，而是像Dremel一樣借鑑了MPP並行數據庫的思想另起爐竈，因此可做更多的查詢優化，從而省掉不必要的shuffle、sort等開銷。
- 通過使用LLVM來統一編譯運行時代碼，避免了爲支持通用編譯而帶來的不必要開銷。
- 用C++實現，做了很多有針對性的硬件優化，例如使用SSE指令。
- 使用了支持Data locality的I/O調度機制，儘可能地將數據和計算分配在同一臺機器上進行，減少了網絡開銷。
雖然Impala是參照Dremel來實現的，但它也有一些自己的特色，例如Impala不僅支持Parquet格式，同時也可以直接處理文本、SequenceFile等Hadoop中常用的文件格式。另外一個更關鍵的地方在於，Impala是開源的，再加上Cloudera在Hadoop領域的領導地位，其生態圈有很大可能會在將來快速成長。
Impala與Shark，Drill等的比較
開源組織Apache也發起了名爲Drill的項目來實現Hadoop上的Dremel，目前該項目正在開發當中，相關的文檔和代碼還不多，可以說暫時還未對Impala構成足夠的威脅。從Quora上的問答來看，Cloudera有7-8名工程師全職在Impala項目上，而相比之下Drill目前的動作稍顯遲鈍。具體來說，截止到2012年10月底，Drill的代碼庫裏實現了query parser, plan parser，及能對JSON格式的數據進行掃描的plan evaluator；而Impala同期已經有了一個比較完畢的分佈式query execution引擎，並對HDFS和HBase上的數據讀入，錯誤檢測，INSERT的數據修改，LLVM動態翻譯等都提供了支持。當然，Drill作爲Apache的項目，從一開始就避免了某個vendor的一家獨大，而且對所有Hadoop流行的發行版都會做相應的支持，不像Impala只支持Cloudera自己的發行版CDH。從長遠來看，誰會佔據上風還真不一定。
除此之外，加州伯克利大學AMPLab也開發了名爲Shark的大數據分析系統。從長遠目標來看，Shark想成爲一個既支持大數據SQL查詢，又能支持高級數據分析任務的一體化數據處理系統。從技術實現的角度上來看，Shark基於Scala語言的算子推導實現了良好的容錯機制，因此對失敗了的長任務和短任務都能從上一個“快照點”進行快速恢復。相比之下，Impala由於缺失足夠強大的容錯機制，其上運行的任務一旦失敗就必須“從頭來過”，這樣的設計必然會在性能上有所缺失。而且Shark是把內存當作第一類的存儲介質來做的系統設計，所以在處理速度上也會有一些優勢。實際上，AMPLab最近對Hive，Impala，Shark及Amazon採用的商業MPP數據庫Redshift進行了一次對比試驗，在Scan Query，Aggregation Query和Join Query三種類型的任務中對它們進行了比較。圖2就是AMPLab報告中Aggregation Query的性能對比。在圖中我們可以看到，商業版本的Redshift的性能是最好的， Impala和Shark則各有勝負，且兩者都比Hive的性能高出了一大截。
其實對大數據分析的項目來說，技術往往不是最關鍵的。例如Hadoop中的MapReduce和HDFS都是源於Google，原創性較少。事實上，開源項目的生態圈，社區，發展速度等，往往在很大程度上會影響Impala和Shark等開源大數據分析系統的發展。就像Cloudera一開始就決定會把Impala開源，以期望利用開源社區的力量來推廣這個產品；Shark也是一開始就開源了出來，更不用說Apache的Drill更是如此。說到底還是誰的生態系統更強的問題。技術上一時的領先並不足以保證項目的最終成功。雖然最後那一款產品會成爲事實上的標準還很難說，但是，我們唯一可以確定並堅信的一點是，大數據分析將隨着新技術的不斷推陳出新而不斷普及開來，這對用戶永遠都是一件幸事。舉個例子，如果讀者注意過下一代Hadoop（YARN）的發展的話就會發現，其實YARN已經支持MapReduce之外的計算範式（例如Shark，Impala等），因此將來Hadoop將可能作爲一個兼容幷包的大平臺存在，在其上提供各種各樣的數據處理技術，有應對秒量級查詢的，有應對大數據批處理的，各種功能應有盡有，滿足用戶各方面的需求。