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

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

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

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

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

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

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

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