今天将临时表里面的数据按照天分区插入到线上的表中去，出现了Hive创建的文件数大于100000个的情况，我的SQL如下：
hive> insert overwrite table test partition(dt)
> select * from table_tmp;
table_tmp表里面一共有570多G的数据，一共可以分成76个分区，SQL运行的时候创建了2163个Mapper，0个Reducers。程序运行到一般左右的时候出现了以下的异常：
[Fatal Error] total number of created files now is 100385, which exceeds 100000. Killing the job.
并最终导致了SQL的运行失败。这个错误的原因是因为Hive对创建文件的总数有限制（hive.exec.max.created.files），默认是100000个，而这个SQL在运行的时候每个Map都会创建76个文件，对应了每个分区，所以这个SQL总共会创建2163 * 76 = 164388个文件，运行中肯定会出现上述的异常。为了能够成功地运行上述的SQL，最简单的方法就是加大hive.exec.max.created.files参数的设置。但是这有个问题，这会导致在hadoop中产生大量的小文件，因为table_tmp表的数据就570多G，那么平均每个文件的大小=570多G / 164388 = 3.550624133148405MB，可想而知，十万多个这么小的小文件对Hadoop来说是多么不好。那么有没有好的办法呢？有！
我们可以将dt相同的数据放到同一个Reduce处理，这样最多也就产生76个文件，将dt相同的数据放到同一个Reduce可以使用DISTRIBUTE BY dt实现，所以修改之后的SQL如下：
hive> insert overwrite table test partition(dt)
> select * from table_tmp
> DISTRIBUTE BY dt;
修改完之后的SQL运行良好，并没有出现上面的异常信息，但是这里也有个问题，因为这76个分区的数据分布很不均匀，有些Reduce的数据有30多G，而有些Reduce只有几K，直接导致了这个SQL运行的速度很慢！
能不能将570G的数据均匀的分配给Reduce呢？可以！我们可以使用DISTRIBUTE BY rand()将数据随机分配给Reduce，这样可以使得每个Reduce处理的数据大体一致。我设定每个Reduce处理5G的数据，对于570G的数据总共会起110左右的Reduces，修改的SQL如下：
hive> set hive.exec.reducers.bytes.per.reducer=5120000000;
hive> insert overwrite table test partition(dt)
> select * from iteblog_tmp
> DISTRIBUTE BY rand();
这个SQL运行的时间很不错，而且生产的文件数量为Reduce的个数*分区的个数，不到1W个文件。