昨天下午有20多分钟Hadoop平台无法跑Hive，Jobtracker的页面也打不开，hadoop job –list也hang住没有响应，过了10分钟后恢复了，查看gc日志发现Jobtracker没有进行full gc，查看这段时间的Job日志发现一个可疑的Hive SQL: Insert into table t(dt) as select xxx,dt from txx，是一个用了动态分区的查询.这个查询和Jobtracker Hang住有什么关系呢？
熟悉Jobtracker的都知道，在进行Job初始化时EagerTaskInitializationListener会锁住JobInProgress然后进行InitTask,细节请各位查看代码，这里有一步就是需要向hdfs写入初始数据并flush，而Fairscheduler的Update Thread在更新资源池的资源时是在持有JobTracker和Fairscheduler的独占锁然后再去计算每个资源池的资源情况，而计算running_map/running_reduce的时候要去获取相应的JobInProgress锁，各位读者可能不明白，我为啥要讲这块呢，问题就出现在这里.
Hive在处理动态分区的时候，主要经历这么几个步骤tablescan->filesink->movetask
在进行filesink的时候是根据记录来处理的，会起N（part）个record writer然后开始处理动态分区字段，即这里的dt，如果dt是连续的那么打开一个block开始写，否则关闭当前block，打开新dir的block继续写，这里如果dt是不连续的出现并且记录数量巨大的情况下会产生大量的文件，导致hdfs的负载标高，和当时的hdfs的监控是匹配的：
当时的集群负载：
当时产生的文件数：
进而导致JobInProgress被锁住，从而JobTracker被锁住，导致JobTracker Hang住了！
那怎么解决呢？利用distributeby dt把相同的dt排列到一起再进行filesink就不会造成大量的小文件产生了.
update:虽然Hive0.13(https://issues.apache.org/jira/browse/HIVE-6455)提供了参数来解决这个问题，但是又引入了bug（https://issues.apache.org/jira/browse/HIVE-8151），因此0.13建议还是使用distribute by的方式来解决这个问题；
本文转自MIKE老毕 51CTO博客，原文链接：http://blog.51cto.com/boylook/1380981，如需转载请自行联系原作者
