今天将临时表里面的数据按照天分区插入到线上的表中去,出现了Hive创建的文件数大于100000个的情况,我的SQL如下:
hive> insert overwrite table test partition(dt) > select * from iteblog_tmp; |
iteblog_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参数的设置。但是这有个问题,这会导致在iteblog中产生大量的小文件,因为iteblog_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 iteblog_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个文件。
|