熟悉Jobtracker的都知道，在進(jìn)行Job初始化時EagerTaskInitializationListener會鎖住JobInProgress然后進(jìn)行InitTask,細(xì)節(jié)請各位查看代碼，這里有一步就是需要向hdfs寫入初始數(shù)據(jù)并flush，而Fairscheduler的Update Thread在更新資源池的資源時是在持有JobTracker和Fairscheduler的獨(dú)占鎖然后再去計算每個資源池的資源情況，而計算running_map/running_reduce的時候要去獲取相應(yīng)的JobInProgress鎖，各位讀者可能不明白，我為啥要講這塊呢，問題就出現(xiàn)在這里.

Hive在處理動態(tài)分區(qū)的時候，主要經(jīng)歷這么幾個步驟tablescan->filesink->movetask

在進(jìn)行filesink的時候是根據(jù)記錄來處理的，會起N（part）個record writer然后開始處理動態(tài)分區(qū)字段，即這里的dt，如果dt是連續(xù)的那么打開一個block開始寫，否則關(guān)閉當(dāng)前block，打開新dir的block繼續(xù)寫，這里如果dt是不連續(xù)的出現(xiàn)并且記錄數(shù)量巨大的情況下會產(chǎn)生大量的文件，導(dǎo)致hdfs的負(fù)載標(biāo)高，和當(dāng)時的hdfs的監(jiān)控是匹配的：

當(dāng)時的集群負(fù)載：

當(dāng)時產(chǎn)生的文件數(shù)：

進(jìn)而導(dǎo)致JobInProgress被鎖住，從而JobTracker被鎖住，導(dǎo)致JobTracker Hang住了！

那怎么解決呢？利用distributeby dt把相同的dt排列到一起再進(jìn)行filesink就不會造成大量的小文件產(chǎn)生了。

原文鏈接：http://boylook.blog.51cto.com/7934327/1380981