Impala與Hive的比較.docx

1. Impala架構(gòu)Impala是Cloudera在受到Google的Dremel啟發(fā)下開發(fā)的實時交互SQL大數(shù)據(jù)查詢工具，Impala沒有再使用緩慢的 Hive+MapReduce批處理，而是通過使用與商用并行關(guān)系數(shù)據(jù)庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統(tǒng)計函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲。其架構(gòu)如圖 1所示，Impala主要由Impalad， State Store和CLI組成。圖 1Impalad: 與DataNode運行在同一節(jié)點上，由Impalad進程表示，它接收客戶端的查詢請求（接收查詢請求的Impalad為 Coordinator，Coordinator通過JNI調(diào)用java前端解釋SQL查詢語句，生成查詢計劃樹，再通過調(diào)度器把執(zhí)行計劃分發(fā)給具有相應(yīng) 數(shù)據(jù)的其它Impalad進行執(zhí)行），讀寫數(shù)據(jù)，并行執(zhí)行查詢，并把結(jié)果通過網(wǎng)絡(luò)流式的傳送回給Coordinator，由Coordinator返回給 客戶端。同時Impalad也與State Store保持連接，用于確定哪個Impalad是健康和可以接受新的工作。在Impalad中啟動三個ThriftServer: beeswax_server（連接客戶端），hs2_server（借用Hive元數(shù)據(jù)）， be_server（Impalad內(nèi)部使用）和一個ImpalaServer服務(wù)。 Impala State Store: 跟蹤集群中的Impalad的健康狀態(tài)及位置信息，由statestored進程表示，它通過創(chuàng)建多個線程來處理Impalad的注冊訂閱和與各 Impalad保持心跳連接，各Impalad都會緩存一份State Store中的信息，當State Store離線后（Impalad發(fā)現(xiàn)State Store處于離線時，會進入recovery模式，反復(fù)注冊，當State Store重新加入集群后，自動恢復(fù)正常，更新緩存數(shù)據(jù)）因為Impalad有State Store的緩存仍然可以工作，但會因為有些Impalad失效了，而已緩存數(shù)據(jù)無法更新，導致把執(zhí)行計劃分配給了失效的Impalad，導致查詢失敗。CLI: 提供給用戶查詢使用的命令行工具（Impala Shell使用python實現(xiàn)），同時Impala還提供了Hue，JDBC， ODBC使用接口。2. 與Hive的關(guān)系Impala 與Hive都是構(gòu)建在Hadoop之上的數(shù)據(jù)查詢工具各有不同的側(cè)重適應(yīng)面，但從客戶端使用來看Impala與Hive有很多的共同之處，如數(shù)據(jù)表元數(shù) 據(jù)、ODBC/JDBC驅(qū)動、SQL語法、靈活的文件格式、存儲資源池等。Impala與Hive在Hadoop中的關(guān)系如圖 2所示。Hive適合于長時間的批處理查詢分析，而Impala適合于實時交互式SQL查詢，Impala給數(shù)據(jù)分析人員提供了快速實驗、驗證想法的大數(shù) 據(jù)分析工具。可以先使用hive進行數(shù)據(jù)轉(zhuǎn)換處理，之后使用Impala在Hive處理后的結(jié)果數(shù)據(jù)集上進行快速的數(shù)據(jù)分析。圖 23. Impala的查詢處理過程Impalad分為Java前端與C+處理后端，接受客戶端連接的Impalad即作為這次查詢的 Coordinator，Coordinator通過 JNI調(diào)用Java前端對用戶的查詢SQL進行分析生成執(zhí)行計劃樹，不同的操作對應(yīng)不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。執(zhí)行計劃樹的每個原子操作由一個PlanFragment表示，通常一條查詢語句由多個Plan Fragment組成， Plan Fragment 0表示執(zhí)行樹的根，匯聚結(jié)果返回給用戶，執(zhí)行樹的葉子結(jié)點一般是Scan操作，分布式并行執(zhí)行。Java前端產(chǎn)生的執(zhí)行計劃樹以Thrift數(shù)據(jù)格式返回給Impala C+后端（Coordinator）（執(zhí)行計劃分為多個階段，每一個階段叫做一個PlanFragment，每一個PlanFragment在執(zhí)行時可 以由多個Impalad實例并行執(zhí)行(有些PlanFragment只能由一個Impalad實例執(zhí)行,如聚合操作)，整個執(zhí)行計劃為一執(zhí)行計劃樹），由 Coordinator根據(jù)執(zhí)行計劃，數(shù)據(jù)存儲信息（Impala通過libhdfs與HDFS進行交互。通過hdfsGetHosts方法獲得文件數(shù)據(jù) 塊所在節(jié)點的位置信息），通過調(diào)度器（現(xiàn)在只有simple-scheduler, 使用round-robin算法）Coordinator:Exec對生成的執(zhí)行計劃樹分配給相應(yīng)的后端執(zhí)行器Impalad執(zhí)行（查詢會使用LLVM 進行代碼生成，編譯，執(zhí)行。對于使用LLVM如何提高性能這里有說明），通過調(diào)用GetNext()方法獲取計算結(jié)果，如果是insert語句，則將計算結(jié)果通過libhdfs寫回HDFS當所有輸入數(shù)據(jù)被消耗光，執(zhí)行結(jié)束，之后注銷此次查詢服務(wù)。Impala的查詢處理流程大概如圖3所示：圖 3下面以一個SQL查詢語句為例分析Impala的查詢處理流程。如select sum(id), count(id), avg(id) from customer_small group by id； 以此語句生成的計劃為：1234567891011121314151617181920212223242526272829PLAN FRAGMENT 0PARTITION: UNPARTITIONED4:EXCHANGEtuple ids: 1PLAN FRAGMENT 1PARTITION: HASH_PARTITIONED: STREAM DATA SINKEXCHANGE ID: 4UNPARTITIONED3:AGGREGATE| output: SUM(), SUM()| group by: | tuple ids: 1|2:EXCHANGEtuple ids: 1PLAN FRAGMENT 2PARTITION: RANDOMSTREAM DATA SINKEXCHANGE ID: 2HASH_PARTITIONED: 1:AGGREGATE| output: SUM(id), COUNT(id)| group by: id| tuple ids: 1|0:SCAN HDFStable=default.customer_small #partitions=1 size=193Btuple ids: 0執(zhí)行行計劃樹如圖 4所示， 綠色的部分為可以分布式并行執(zhí)行：圖 44. Impala相對于Hive所使用的優(yōu)化技術(shù) 1、沒有使用 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啟動時間。 2、使用LLVM產(chǎn)生運行代碼，針對特定查詢生成特定代碼，同時使用Inline的方式減少函數(shù)調(diào)用的開銷，加快執(zhí)行效率。 3、充分利用可用的硬件指令（SSE4.2）。 4、更好的IO調(diào)度，Impala知道數(shù)據(jù)塊所在的磁盤位置能夠更好的利用多磁盤的優(yōu)勢，同時Impala支持直接數(shù)據(jù)塊讀取和本地代碼計算checksum。 5、通過選擇合適的數(shù)據(jù)存儲格式可以得到最好的性能（Impala支持多種存儲格式）。 6、最大使用內(nèi)存，中間結(jié)果不寫磁盤，及時通過網(wǎng)絡(luò)以stream的方式傳遞。5. 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ù)時，當前版本1.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í)行，導致本次Query失敗。適用面： Hive: 復(fù)雜的批處理查詢?nèi)蝿?wù)，數(shù)據(jù)轉(zhuǎn)換任務(wù)。 Impala：實時數(shù)據(jù)分析，因為不支持UDF，