Impala與hive相關知識點摘錄

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組成。java

圖 1python

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處理後的結果數據集上進行快速的數據分析。網絡

圖 23架構

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

 

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

一、沒有使用 MapReduce進行並行計算,雖然MapReduce是很是好的並行計算框架,但它更多的面向批處理模式,而不是面向交互式的SQL執行。與 MapReduce相比:Impala把整個查詢分紅一執行計劃樹,而不是一連串的MapReduce任務,在分發執行計劃後,Impala使用拉式獲取 數據的方式獲取結果,把結果數據組成按執行樹流式傳遞聚集,減小的了把中間結果寫入磁盤的步驟,再從磁盤讀取數據的開銷。Impala使用服務的方式避免 每次執行查詢都須要啓動的開銷,即相比Hive沒了MapReduce啓動時間。
二、使用LLVM產生運行代碼,針對特定查詢生成特定代碼,同時使用Inline的方式減小函數調用的開銷,加快執行效率。
三、充分利用可用的硬件指令(SSE4.2)。
四、更好的IO調度,Impala知道數據塊所在的磁盤位置可以更好的利用多磁盤的優點,同時Impala支持直接數據塊讀取和本地代碼計算checksum。
五、經過選擇合適的數據存儲格式能夠獲得最好的性能(Impala支持多種存儲格式)。
六、最大使用內存,中間結果不寫磁盤,及時經過網絡以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://www.imooc.com/article/12383

相關文章
相關標籤/搜索