最近讀的幾篇關(guān)于impala的文章，這篇良心不錯：https://www./impala.html（本文截取部分內(nèi)容）

        Impala是Cloudera公司主導(dǎo)開發(fā)的新型查詢系統(tǒng)，它提供SQL語義，能查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù)。已有的Hive系統(tǒng)雖然也提供了SQL語義，但由于Hive底層執(zhí)行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的交互性。相比之下，Impala的最大特點也是最大賣點就是它的快速。    

Impala相對于Hive所使用的優(yōu)化技術(shù)

• 沒有使用MapReduce進行并行計算，雖然MapReduce是非常好的并行計算框架，但它更多的面向批處理模式，而不是面向交互式的SQL執(zhí)行。與MapReduce相比：Impala把整個查詢分成一執(zhí)行計劃樹，而不是一連串的MapReduce任務(wù)，在分發(fā)執(zhí)行計劃后，Impala使用拉式獲取數(shù)據(jù)的方式獲取結(jié)果，把結(jié)果數(shù)據(jù)組成按執(zhí)行樹流式傳遞匯集，減少了把中間結(jié)果寫入磁盤的步驟，再從磁盤讀取數(shù)據(jù)的開銷。Impala使用服務(wù)的方式避免每次執(zhí)行查詢都需要啟動的開銷，即相比Hive沒了MapReduce啟動時間。
• 使用LLVM產(chǎn)生運行代碼，針對特定查詢生成特定代碼，同時使用Inline的方式減少函數(shù)調(diào)用的開銷，加快執(zhí)行效率。
• 充分利用可用的硬件指令（2）。
• 更好的IO調(diào)度，Impala知道數(shù)據(jù)塊所在的磁盤位置能夠更好的利用多磁盤的優(yōu)勢，同時Impala支持直接數(shù)據(jù)塊讀取和本地代碼計算checksum。
• 通過選擇合適的數(shù)據(jù)存儲格式可以得到最好的性能（Impala支持多種存儲格式）。
• 最大使用內(nèi)存，中間結(jié)果不寫磁盤，及時通過網(wǎng)絡(luò)以stream的方式傳遞。

Impala與Hive的異同

相同點：

• 數(shù)據(jù)存儲：使用相同的存儲數(shù)據(jù)池都支持把數(shù)據(jù)存儲于HDFS, HBase。
• 元數(shù)據(jù)：兩者使用相同的元數(shù)據(jù)。
• SQL解釋處理：比較相似都是通過詞法分析生成執(zhí)行計劃。

不同點：

執(zhí)行計劃：

• Hive: 依賴于MapReduce執(zhí)行框架，執(zhí)行計劃分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個Query會被編譯成多輪MapReduce，則會有更多的寫中間結(jié)果。由于MapReduce執(zhí)行框架本身的特點，過多的中間過程會增加整個Query的執(zhí)行時間。
• Impala: 把執(zhí)行計劃表現(xiàn)為一棵完整的執(zhí)行計劃樹，可以更自然地分發(fā)執(zhí)行計劃到各個Impalad執(zhí)行查詢，而不用像Hive那樣把它組合成管道型的map->reduce模式，以此保證Impala有更好的并發(fā)性和避免不必要的中間sort與shuffle。

數(shù)據(jù)流：

• Hive: 采用推的方式，每一個計算節(jié)點計算完成后將數(shù)據(jù)主動推給后續(xù)節(jié)點。
• Impala: 采用拉的方式，后續(xù)節(jié)點通過getNext主動向前面節(jié)點要數(shù)據(jù)，以此方式數(shù)據(jù)可以流式的返回給客戶端，且只要有1條數(shù)據(jù)被處理完，就可以立即展現(xiàn)出來，而不用等到全部處理完成，更符合SQL交互式查詢使用。

內(nèi)存使用：

• Hive: 在執(zhí)行過程中如果內(nèi)存放不下所有數(shù)據(jù)，則會使用外存，以保證Query能順序執(zhí)行完。每一輪MapReduce結(jié)束，中間結(jié)果也會寫入HDFS中，同樣由于MapReduce執(zhí)行架構(gòu)的特性，shuffle過程也會有寫本地磁盤的操作。
• Impala: 在遇到內(nèi)存放不下數(shù)據(jù)時，當前版本0.1是直接返回錯誤，而不會利用外存，以后版本應(yīng)該會進行改進。這使用得Impala目前處理Query會受到一定的限制，最好還是與Hive配合使用。Impala在多個階段之間利用網(wǎng)絡(luò)傳輸數(shù)據(jù)，在執(zhí)行過程不會有寫磁盤的操作（insert除外）。

調(diào)度：

• Hive: 任務(wù)調(diào)度依賴于Hadoop的調(diào)度策略。
• Impala: 調(diào)度由自己完成，目前只有一種調(diào)度器simple-schedule，它會盡量滿足數(shù)據(jù)的局部性，掃描數(shù)據(jù)的進程盡量靠近數(shù)據(jù)本身所在的物理機器。調(diào)度器目前還比較簡單，在SimpleScheduler::GetBackend中可以看到，現(xiàn)在還沒有考慮負載，網(wǎng)絡(luò)IO狀況等因素進行調(diào)度。但目前Impala已經(jīng)有對執(zhí)行過程的性能統(tǒng)計分析，應(yīng)該以后版本會利用這些統(tǒng)計信息進行調(diào)度吧。

容錯：

• Hive: 依賴于Hadoop的容錯能力。
• Impala: 在查詢過程中，沒有容錯邏輯，如果在執(zhí)行過程中發(fā)生故障，則直接返回錯誤（這與Impala的設(shè)計有關(guān)，因為Impala定位于實時查詢，一次查詢失敗，再查一次就好了，再查一次的成本很低）。但從整體來看，Impala是能很好的容錯，所有的Impalad是對等的結(jié)構(gòu)，用戶可以向任何一個Impalad提交查詢，如果一個Impalad失效，其上正在運行的所有Query都將失敗，但用戶可以重新提交查詢由其它Impalad代替執(zhí)行，不會影響服務(wù)。對于State Store目前只有一個，但當State Store失效，也不會影響服務(wù)，每個Impalad都緩存了State Store的信息，只是不能再更新集群狀態(tài)，有可能會把執(zhí)行任務(wù)分配給已經(jīng)失效的Impalad執(zhí)行，導(dǎo)致本次Query失敗。

適用面：

• Hive: 復(fù)雜的批處理查詢?nèi)蝿?wù)，數(shù)據(jù)轉(zhuǎn)換任務(wù)。
• Impala：實時數(shù)據(jù)分析，因為不支持UDF，能處理的問題域有一定的限制，與Hive配合使用,對Hive的結(jié)果數(shù)據(jù)集進行實時分析。

Impala的優(yōu)缺點

優(yōu)點：

• 支持SQL查詢，快速查詢大數(shù)據(jù)。
• 可以對已有數(shù)據(jù)進行查詢，減少數(shù)據(jù)的加載，轉(zhuǎn)換。
• 多種存儲格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。
• 可以與Hive配合使用。

缺點：

• 不支持用戶定義函數(shù)UDF。
• 不支持text域的全文搜索。
• 不支持Transforms。
• 不支持查詢期的容錯。
• 對內(nèi)存要求高。

在Cloudera的測試中，Impala的查詢效率比Hive有數(shù)量級的提升。從技術(shù)角度上來看，Impala之所以能有好的性能，主要有以下幾方面的原因。

• Impala不需要把中間結(jié)果寫入磁盤，省掉了大量的I/O開銷。
• 省掉了MapReduce作業(yè)啟動的開銷。MapReduce啟動task的速度很慢（默認每個心跳間隔是3秒鐘），Impala直接通過相應(yīng)的服務(wù)進程來進行作業(yè)調(diào)度，速度快了很多。
• Impala完全拋棄了MapReduce這個不太適合做SQL查詢的范式，而是像Dremel一樣借鑒了MPP并行數(shù)據(jù)庫的思想另起爐灶，因此可做更多的查詢優(yōu)化，從而省掉不必要的shuffle、sort等開銷。
• 通過使用LLVM來統(tǒng)一編譯運行時代碼，避免了為支持通用編譯而帶來的不必要開銷。
• 用C++實現(xiàn)，做了很多有針對性的硬件優(yōu)化，例如使用SSE指令。
• 使用了支持Data locality的I/O調(diào)度機制，盡可能地將數(shù)據(jù)和計算分配在同一臺機器上進行，減少了網(wǎng)絡(luò)開銷。

雖然Impala是參照Dremel來實現(xiàn)的，但它也有一些自己的特色，例如Impala不僅支持Parquet格式，同時也可以直接處理文本、SequenceFile等Hadoop中常用的文件格式。另外一個更關(guān)鍵的地方在于，Impala是開源的，再加上Cloudera在Hadoop領(lǐng)域的領(lǐng)導(dǎo)地位，其生態(tài)圈有很大可能會在將來快速成長。

Impala與Shark，Drill等的比較

開源組織Apache也發(fā)起了名為Drill的項目來實現(xiàn)Hadoop上的Dremel，目前該項目正在開發(fā)當中，相關(guān)的文檔和代碼還不多，可以說暫時還未對Impala構(gòu)成足夠的威脅。從Quora上的問答來看，Cloudera有7-8名工程師全職在Impala項目上，而相比之下Drill目前的動作稍顯遲鈍。具體來說，截止到2012年10月底，Drill的代碼庫里實現(xiàn)了query parser, plan parser，及能對JSON格式的數(shù)據(jù)進行掃描的plan evaluator；而Impala同期已經(jīng)有了一個比較完畢的分布式query execution引擎，并對HDFS和HBase上的數(shù)據(jù)讀入，錯誤檢測，INSERT的數(shù)據(jù)修改，LLVM動態(tài)翻譯等都提供了支持。當然，Drill作為Apache的項目，從一開始就避免了某個vendor的一家獨大，而且對所有Hadoop流行的發(fā)行版都會做相應(yīng)的支持，不像Impala只支持Cloudera自己的發(fā)行版CDH。從長遠來看，誰會占據(jù)上風(fēng)還真不一定。

除此之外，加州伯克利大學(xué)AMPLab也開發(fā)了名為Shark的大數(shù)據(jù)分析系統(tǒng)。從長遠目標來看，Shark想成為一個既支持大數(shù)據(jù)SQL查詢，又能支持高級數(shù)據(jù)分析任務(wù)的一體化數(shù)據(jù)處理系統(tǒng)。從技術(shù)實現(xiàn)的角度上來看，Shark基于Scala語言的算子推導(dǎo)實現(xiàn)了良好的容錯機制，因此對失敗了的長任務(wù)和短任務(wù)都能從上一個“快照點”進行快速恢復(fù)。相比之下，Impala由于缺失足夠強大的容錯機制，其上運行的任務(wù)一旦失敗就必須“從頭來過”，這樣的設(shè)計必然會在性能上有所缺失。而且Shark是把內(nèi)存當作第一類的存儲介質(zhì)來做的系統(tǒng)設(shè)計，所以在處理速度上也會有一些優(yōu)勢。實際上，AMPLab最近對Hive，Impala，Shark及Amazon采用的商業(yè)MPP數(shù)據(jù)庫Redshift進行了一次對比試驗，在Scan Query，Aggregation Query和Join Query三種類型的任務(wù)中對它們進行了比較。圖2就是AMPLab報告中Aggregation Query的性能對比。在圖中我們可以看到，商業(yè)版本的Redshift的性能是最好的， Impala和Shark則各有勝負，且兩者都比Hive的性能高出了一大截。

其實對大數(shù)據(jù)分析的項目來說，技術(shù)往往不是最關(guān)鍵的。例如Hadoop中的MapReduce和HDFS都是源于Google，原創(chuàng)性較少。事實上，開源項目的生態(tài)圈，社區(qū)，發(fā)展速度等，往往在很大程度上會影響Impala和Shark等開源大數(shù)據(jù)分析系統(tǒng)的發(fā)展。就像Cloudera一開始就決定會把Impala開源，以期望利用開源社區(qū)的力量來推廣這個產(chǎn)品；Shark也是一開始就開源了出來，更不用說Apache的Drill更是如此。說到底還是誰的生態(tài)系統(tǒng)更強的問題。技術(shù)上一時的領(lǐng)先并不足以保證項目的最終成功。雖然最后那一款產(chǎn)品會成為事實上的標準還很難說，但是，我們唯一可以確定并堅信的一點是，大數(shù)據(jù)分析將隨著新技術(shù)的不斷推陳出新而不斷普及開來，這對用戶永遠都是一件幸事。舉個例子，如果讀者注意過下一代Hadoop（YARN）的發(fā)展的話就會發(fā)現(xiàn)，其實YARN已經(jīng)支持MapReduce之外的計算范式（例如Shark，Impala等），因此將來Hadoop將可能作為一個兼容并包的大平臺存在，在其上提供各種各樣的數(shù)據(jù)處理技術(shù)，有應(yīng)對秒量級查詢的，有應(yīng)對大數(shù)據(jù)批處理的，各種功能應(yīng)有盡有，滿足用戶各方面的需求。