记Hadoop2.5.0线上mapreduce任务执行map任务划分的一次问题解决

线上遇到一个5GB lzo压缩的mapreduce作业执行时间过长,只分配到1个map任务。分析发现,原因是输入过大导致map任务处理缓慢。通过调整`dfs.blockSize`、`mapreduce.input.fileinputformat.split.minsize`和`mapreduce.input.fileinputformat.split.maxsize`参数,可以控制FileInputFormat的map任务划分,从而提高效率。
摘要由CSDN通过智能技术生成

前言

近日在线上发现有些mapreduce作业的执行时间很长,我们需要解决这个问题。输入文件的大小是5G,采用了lzo压缩,整个集群的默认block大小是128M。本文将详细描述这次线上问题的排查过程。

现象

线上有一个脚本,为了便于展示,我将这个脚本重新copy了一份并重命名为zzz。这个脚本实际是使用Hadoop streaming运行一个mapreduce任务,在线上执行它的部分输出内容如下:


可以看到map任务划分为1个。这个执行过程十分漫长,我将中间的一些信息省略,map与reduce任务的执行进度如下:

16/05/16 10:22:16 INFO mapreduce.Job:  map 0% reduce 0%
16/05/16 10:22:32 INFO mapreduce.Job:  map 1% reduce 0%
。。。
16/05/16 10:44:14 INFO mapreduce.Job:  map 99% reduce 0%
16/05/16 10:44:20 INFO mapreduce.Job:  map 100% reduce 0%
16/05/16 10:44:33 INFO mapreduce.Job:  map 100% reduce 2%
16/05/16 10:44:34 INFO mapreduce.Job:  map 100% reduce 19%
。。。
16/05/16 10:44:57 INFO mapreduce.Job:  map 100% reduce 99%
16/05/16 10:44:58 INFO mapreduce.Job:  map 100% reduce 100%
从以上内容可以看到map任务执行一共耗时22分钟左右,而reduce任务只耗用了30多秒。

分析

根据以上现象分析,我们知道耗时主要发生在map任务执行的阶段。我们首先查看下这个map任务的输入内容,看到它的大小为5GB且使用lzo压缩:


如此大的输入仅仅在一个map任务中处理显然是进度缓慢的主要原因,我们需要对mapreduce的任务划分进行干预。我们查看下mapreduce任务的InputFormat,以便确定干预的手段,打开我们的脚本其中有以下代码片段:

     hadoop jar $streaming_jar \
          -D mapred.reduce.tasks=30 \
          -D mapreduce.job.maps=100 \
          -D mapreduce.input.fileinputformat.split.minsize=100000000 \
          -inputformat TextInputFormat \
          -file mr.py \
          -input $member_input \
          -output $output \
          -mapper "python mr.py map" \
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值