hivejob中map的优化

友情提示：更多有关大数据、人工智能方面技术文章请关注博主个人微信公众号：高级大数据架构师！

1、Hive优化案例——map数过多

集群运行的作业有不少map数超大的作业，占用slot过多，导致其他同池子的其他作业等待状态。由于小文件数过多会占用元数据过大，计算时也会消耗更多的资源。所以，建议文件的大小控制在不小于 100M。（文件也不是越大越好，gzip压缩文件最好控制500M以内）

分区表下会有3w多个分区

解决方法

首先要查出产生文件数太多的那步sql。先查当前作业的源表，如果源表不存在太多小文件的情况，直接优化当前sql；如果是源表小文件多，还要往前查一步，要从源头控制小文件的产生。

这个例子是发现该作业的源表一个天分区总大小才3.5G，但是有32889个文件，其中近2万个文件不到k级。

 查看前一步的sql，找到了原因。sql里面没有聚合，只是从源表里面过滤筛选出部分结果。只有map阶段，源表有多少个文件，就生成了多少个文件。

1. 增加聚合(group by)操作

2. 在sql中增加 distribute操作，使数据均匀分布。同时通过设置reduce数来控制结果文件数，结果文件数的个数建议是产生的总大小/100M得到。

 这里采用的是第二个解决方案，修改sql如下：

这样结果文件数从32889个减少到100个。