[Hive]從一個經典案例看優化mapred.map.tasks的重要性

我所在公司所使用的生產Hive環境的幾個引數配置如下：
dfs.block.size=268435456
hive.merge.mapredfiles=true
hive.merge.mapfiles=true
hive.merge.size.per.task=256000000
mapred.map.tasks=2 

因為合併小檔案預設為true，而dfs.block.size與hive.merge.size.per.task的搭配使得合併後的絕大部分檔案都在300MB左右。

CASE 1：

現在我們假設有3個300MB大小的檔案，那麼goalsize = min(900MB/2,256MB) = 256MB 
所以整個JOB會有6個map，其中3個map分別處理256MB的資料，還有3個map分別處理44MB的資料。
這時候木桶效應就來了，整個JOB的map階段的執行時間不是看最短的1個map的執行時間，而是看最長的1個map的執行時間。所以，雖然有3個map分別只處理44MB的資料，可以很快跑完，但它們還是要等待另外3個處理256MB的map。顯然，處理256MB的3個map拖了整個JOB的後腿。

CASE 2：

如果我們把mapred.map.tasks設定成6，再來看一下有什麼變化：
goalsize = min(900MB/6,256MB) = 150MB
整個JOB同樣會分配6個map來處理，每個map處理150MB的資料，非常均勻，誰都不會拖後腿，最合理地分配了資源，執行時間大約為CASE 1的59%(150/256) 

案例分析：

雖然mapred.map.tasks從2調整到了6，但是CASE 2並沒有比CASE 1多用map資源，同樣都是使用6個map。而CASE 2的執行時間約為CASE 1執行時間的59%。
從這個案例可以看出，對mapred.map.tasks進行自動化的優化設定其實是可以很明顯地提高作業執行效率的。