[Hive]從一個經典案例看優化mapred.map.tasks的重要性
阿新 • • 發佈：2019-02-16
我所在公司所使用的生產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左右。
CASE1：
現在我們假設有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的後腿。
CASE2：
如果我們把mapred.map.tasks設定成6，再來看一下有什麼變化：
goalsize = min(900MB/6,256MB) = 150MB
案例分析：
雖然mapred.map.tasks從2調整到了6，但是CASE 2並沒有比CASE 1多用map資源，同樣都是使用6個map。而CASE 2的執行時間約為CASE 1執行時間的59%。從這個案例可以看出，對mapred.map.tasks進行自動化的優化設定其實是可以很明顯地提高作業執行效率的。