Hive與Impala的異同

hive和impala官網：

http://hive.apache.org/

http://impala.apache.org

Hive 體系結構

 

 

Hive

    hive是基於Hadoop的一個資料倉儲工具，可以將結構化的資料檔案對映為一張資料庫表，並提供完整的sql查詢功能，可以將sql語句轉換為MapReduce任務進行執行。Hive支援HSQL，是一種類SQL。

也由於這種機制導致Hive最大的缺點是慢。Map/reduce排程本身只適合批量，長週期任務，類似查詢這種要求短平快的業務，代價太高。

 

Impala 架構

 

Impala是Cloudera在受到Google的Dremel啟發下開發的實時互動SQL大資料查詢工具，Impala沒有再使用緩慢的Hive+MapReduce批處理，而是通過使用與商用並行關聯式資料庫中類似的分散式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函式查詢資料，從而大大降低了延遲。

 

Impalad: 與DataNode執行在同一節點上，由Impalad程式表示，它接收客戶端的查詢請求（接收查詢請求的Impalad為Coordinator，Coordinator通過JNI呼叫java前端解釋SQL查詢語句，生成查詢計劃樹，再通過排程器把執行計劃分發給具有相應資料的其它Impalad進行執行），讀寫資料，並行執行查詢，並把結果通過網路流式的傳送回給Coordinator，由Coordinator返回給客戶端。同時Impalad也與State Store保持連線，用於確定哪個Impalad是健康和可以接受新的工作。在Impalad中啟動三個ThriftServer: beeswax_server（連線客戶端），hs2_server（借用Hive後設資料）， be_server（Impalad內部使用）和一個ImpalaServer服務。

Impala State Store: 跟蹤叢集中的Impalad的健康狀態及位置資訊，由statestored程式表示，它通過建立多個執行緒來處理Impalad的註冊訂閱和與各Impalad保持心跳連線，各Impalad都會快取一份State Store中的資訊，當State Store離線後（Impalad發現State Store處於離線時，會進入recovery模式，反覆註冊，當State Store重新加入叢集后，自動恢復正常，更新快取資料）因為Impalad有State Store的快取仍然可以工作，但會因為有些Impalad失效了，而已快取資料無法更新，導致把執行計劃分配給了失效的Impalad，導致查詢失敗。

CLI: 提供給使用者查詢使用的命令列工具（Impala Shell使用python實現），同時Impala還提供了Hue，JDBC， ODBC使用介面。

Impala架構類似分散式資料庫Greenplum資料庫，一個大的查詢通過分析為一一個子查詢，分佈到底層的執行，最後再合併結果，說白了就是通過多執行緒併發來暴力SCAN來實現高速。

架構是完美的，現實是骨感的，實際使用過程中，Impala效能和穩定性還差得遠。尤其是Impala雖然號稱支援HDFS和HBASE，但實際使用中發現，執行在HDFS上，效能還差強人意，執行在HBASE上效能很差，另外還經常有記憶體溢位之類的問題尚待解決。

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領域的領導地位，其生態圈有很大可能會在將來快速成長。