2019獨角獸企業重金招聘Python工程師標準>>>

1. Impala架構

?????? Impala是Cloudera在受到Google的Dremel啟發下開發的實時交互SQL大數據查詢工具，Impala沒有再使用緩慢的Hive+MapReduce批處理，而是通過使用與商用并行關系數據庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。其架構如圖 1所示，Impala主要由Impalad， State Store和CLI組成。

圖 1

??????? 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使用接口。

2. 與Hive的關系

????????Impala與Hive都是構建在Hadoop之上的數據查詢工具各有不同的側重適應面，但從客戶端使用來看Impala與Hive有很多的共同之處，如數據表元數據、ODBC/JDBC驅動、SQL語法、靈活的文件格式、存儲資源池等。Impala與Hive在Hadoop中的關系如圖 2所示。Hive適合于長時間的批處理查詢分析，而Impala適合于實時交互式SQL查詢，Impala給數據分析人員提供了快速實驗、驗證想法的大數據分析工具。可以先使用hive進行數據轉換處理，之后使用Impala在Hive處理后的結果數據集上進行快速的數據分析。

圖 2

3. Impala的查詢處理過程

??????? Impalad分為Java前端與C++處理后端，接受客戶端連接的Impalad即作為這次查詢的Coordinator，Coordinator通過JNI調用Java前端對用戶的查詢SQL進行分析生成執行計劃樹，不同的操作對應不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。 ??????? 執行計劃樹的每個原子操作由一個PlanFragment表示，通常一條查詢語句由多個Plan Fragment組成， Plan Fragment 0表示執行樹的根，匯聚結果返回給用戶，執行樹的葉子結點一般是Scan操作，分布式并行執行。 ??????? Java前端產生的執行計劃樹以Thrift數據格式返回給Impala C++后端（Coordinator）（執行計劃分為多個階段，每一個階段叫做一個PlanFragment，每一個PlanFragment在執行時可以由多個Impalad實例并行執行(有些PlanFragment只能由一個Impalad實例執行,如聚合操作)，整個執行計劃為一執行計劃樹），由Coordinator根據執行計劃，數據存儲信息（Impala通過libhdfs與HDFS進行交互。通過hdfsGetHosts方法獲得文件數據塊所在節點的位置信息），通過調度器（現在只有simple-scheduler, 使用round-robin算法）Coordinator::Exec對生成的執行計劃樹分配給相應的后端執行器Impalad執行（查詢會使用LLVM進行代碼生成，編譯，執行。對于使用LLVM如何提高性能這里有說明），通過調用GetNext()方法獲取計算結果，如果是insert語句，則將計算結果通過libhdfs寫回HDFS當所有輸入數據被消耗光，執行結束，之后注銷此次查詢服務。
??????? Impala的查詢處理流程大概如圖3所示：

圖 3

????????下面以一個SQL查詢語句為例分析Impala的查詢處理流程。如select sum(id), count(id), avg(id) from customer_small? group by id； 以此語句生成的計劃為：

PLAN FRAGMENT 0
? PARTITION: UNPARTITIONED

? 4:EXCHANGE
???? tuple ids: 1

PLAN FRAGMENT 1
? PARTITION: HASH_PARTITIONED: <slot 1>

? STREAM DATA SINK
??? EXCHANGE ID: 4
??? UNPARTITIONED

? 3:AGGREGATE
? |? output: SUM(<slot 2>), SUM(<slot 3>)
? |? group by: <slot 1>
? |? tuple ids: 1
? | ?
? 2:EXCHANGE
???? tuple ids: 1

PLAN FRAGMENT 2
? PARTITION: RANDOM

? STREAM DATA SINK
??? EXCHANGE ID: 2
??? HASH_PARTITIONED: <slot 1>

? 1:AGGREGATE
? |? output: SUM(id), COUNT(id)
? |? group by: id
? |? tuple ids: 1
? | ?
? 0:SCAN HDFS
???? table=default.customer_small #partitions=1 size=193B
???? tuple ids: 0

????????執行行計劃樹如圖 4所示， 綠色的部分為可以分布式并行執行：

圖 4

4. Impala相對于Hive所使用的優化技術

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

5. 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: 在遇到內存放不下數據時，當前版本1.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的結果數據集進行實時分析。

6. Impala的優缺點

優點：

支持SQL查詢，快速查詢大數據。

可以對已有數據進行查詢，減少數據的加載，轉換。

多種存儲格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。

可以與Hive配合使用。

缺點：

不支持用戶定義函數UDF。

不支持text域的全文搜索。

不支持Transforms。

?不支持查詢期的容錯。

對內存要求高。

轉載于:https://my.oschina.net/zouqun/blog/405765

總結

以上是生活随笔為你收集整理的Impala与Hive的比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。