1. Impala架構
圖 1
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的關係
圖 2
3. Impala的查詢處理過程
Impala的查詢處理流程大概如圖3所示:
圖 3
PLAN FRAGMENT 0
PARTITION: UNPARTITIONED4:EXCHANGE
tuple ids: 1PLAN FRAGMENT 1
PARTITION: HASH_PARTITIONED: <slot 1>STREAM DATA SINK
EXCHANGE ID: 4
UNPARTITIONED3:AGGREGATE
| output: SUM(<slot 2>), SUM(<slot 3>)
| group by: <slot 1>
| tuple ids: 1
|
2:EXCHANGE
tuple ids: 1PLAN FRAGMENT 2
PARTITION: RANDOMSTREAM 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. Impala相對於Hive所使用的優化技術
5. Impala與Hive的異同
元數據:兩者使用相同的元數據。
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。
- 不支持查詢期的容錯。
- 對內存要求高。