mapreduce任务优化

mapreduce优化

数据倾斜导致的Reduce时间长

当SQL中包含Join/GroupBy/PartitionBy/DistributedBy等操作时，通过对上述操作所用到的列进行统计，通常就能够找到造成数据倾斜的热点key

常见优化思路

1.过滤掉不符合预期的热点key，例如由于日志信息丢失导致某个字段产生大量空值
2.加入随机因素，打散热点key
3.使用map join解决小表关联大表造成的数据倾斜问题
map join是指将做连接的小表全量数据分发到作业的map端进行join，从而避免reduce task产生数据倾斜；
hive.auto.convert.join=true 这个配置跟hive.optimize.skewjoin有冲突，请保证二者只开一个即可；
map join需要在内存中加载全部小表数据，容易导致map端OOM，hive.mapjoin.smalltable.filesize这个参数用于设置小表的大小，默认25000000（25M），当小表数据量超过这个大小时，不会走map join优化逻辑，不建议用户把这个参数设置过大
hive.optimize.skewjoin可以处理热点key join 倾斜的问题，但是只支持inner join场景，不支持outer join场景

Map Task时间长

常见优化思路

1.查看上一轮作业是否存在reduce，如果有reduce task，则小文件是reduce生成的，如果单个reduce task执行时间不是特别大，可以适当控制reduce最大并发(hive.exec.reducers.max，默认5120，建议设置为2560/1280/640等)；如果上一轮stage没有reduce，则小文件是map 生成的，需要加大split size减少map task（mapreduce.input.fileinputformat.split.maxsize，默认256000000，建议可以设置到1024000000）;
2.在优化手段1的基础上，还可以使用数据架构组定制开发的根据文件数分片的功能（hadoop默认是按照文件大小分片），限制单个task处理的文件数大小（set mapreduce.split.by.block.num.enable = true; set mapreduce.split.block.number.threshold = 500;）

Map/Reduce gc严重

常见优化思路

1.加大内存：mapTask gc告警设置mapreduce.map.memory.mb（默认3072），reduceTask gc告警可以设置mapreduce.reduce.memory.mb（默认4096），建议按照512的幅度增加，合理使用避免浪费；
2.如果sql中有join和group by操作，可以调整参数缩小内存buffer检查间隔：
set hive.mapjoin.check.memory.rows=10000;
set hive.groupby.mapaggr.checkinterval=5000;
set hive.map.aggr.hash.percentmemory=0.3;
set hive.mapjoin.followby.map.aggr.hash.percentmemory=0.1;
set hive.map.aggr.hash.force.flush.memory.threshold=0.7;
set hive.map.aggr.hash.min.reduction=0.3;
3.可以选择关闭GBY的map端优化来争取节约内存hive.map.aggr=false;

MapTask过多，调度开销大

常见优化思路

1.加大单个map处理的数据量（mapreduce.input.fileinputformat.split.maxsize，默认256000000，建议可以设置到1024000000），减少map task个数；
2.合理设置sql查询的分区范围，尽量避免全表扫描，考虑生成一些增量的中间表来替代

map/reduce平均运行时间过长

常见优化思路

1.map运行时间过长：加大map并发需要减小split size（mapreduce.input.fileinputformat.split.maxsize，默认256000000，建议可以设置到32000000）；
2.reduce运行时间过长：加大reduce并发需要减小reduce 的split size（hive.exec.reducers.bytes.per.reducer，默认1024000000，建议可以设置到128000000）;