impala與hive的比較以及impala的優缺點

 最近讀的幾篇關于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将可能作為一個相容并包的大平台存在，在其上提供各種各樣的資料處理技術，有應對秒量級查詢的，有應對大資料批處理的，各種功能應有盡有，滿足使用者各方面的需求。

 最近讀的幾篇關于impala的文章，這篇良心不錯：https://www.biaodianfu.com/impala.html（本文截取部分内容）