使用SequenceFile的Hadoop Streaming单Mapper运行缓慢问题求助

从你提供的日志和任务信息来看，第一个Mapper处理的记录数是其他Mapper的10倍以上，这确实是典型的数据倾斜问题，核心原因是输入数据在分片时分布极不均匀。咱们一步步来排查和解决：

一、先定位数据倾斜的根源 #

1. 检查输入文件的分片与Block分布 #

首先确认这个3.9G的SequenceFile在HDFS上的Block划分情况，执行以下命令：

hadoop fsck /path/to/inputfile -blocks -locations

如果第一个Block的大小和其他Block基本一致（比如都是128M/256M），那说明第一个分片里的记录平均大小远小于其他分片，导致能容纳更多记录；如果第一个Block明显更大，那可能是文件写入时的异常导致。

2. 抽样查看输入数据的键分布 #

因为你的输入文件是单Reducer任务生成的，Reducer输出的SequenceFile是按键全局有序的，很可能大量相同的键集中在文件开头。可以用以下命令抽样查看前1000条记录的键（适配Text类型的键）：

hadoop fs -text inputfile | awk '{print $1}' | head -1000 | sort | uniq -c

如果输出里有某个键出现了几千次，那就是这个高频键导致第一个Mapper处理量剧增。

3. 排查Mapper脚本的性能瓶颈 #

你的Mapper是通过sh map.sh调用的，如果脚本里有大量外部命令调用（比如频繁执行grep/sed）或者低效的字符串处理，处理11k条记录的耗时会是处理800条的数倍。可以在map.sh里添加简单的日志，记录每条记录的键和处理耗时，然后查看第一个Mapper的任务日志，确认是否有特定键的处理耗时异常。

二、针对性解决方法 #

1. 打散集中的高频键（最可能的解决方案） #

因为输入文件是单Reducer生成的有序文件，高频键会集中在一起。可以先运行一个Map-only预任务，给每个键添加随机前缀（比如0-31的随机数），打散数据分布：

• 预任务的Mapper逻辑（用Python实现更高效）：

  import sys
  import random
  
  for line in sys.stdin:
      key, value = line.strip().split('\t', 1)
      # 添加0-31的随机前缀
      rand_prefix = random.randint(0, 31)
      print(f"{rand_prefix}_{key}\t{value}")
  

• 预任务的输出会自动分成32个文件，每个文件里的键分布均匀，再用这个输出作为原任务的输入，就能让每个Mapper处理的记录数基本一致。

2. 调整分片大小，拆分过大的分片 #

如果是因为第一个分片里的小记录过多，可以通过调整Hadoop的分片参数，让大拆分成更多小分片：
在原任务的命令中添加以下参数：

-D mapred.max.split.size=67108864  # 设置分片大小为64M，可根据实际情况调整
-D mapred.min.split.size=1          # 允许最小分片大小为1字节

这样3.9G的文件会被拆分成更多分片，每个Mapper处理的记录数会更均匀。

3. 优化Mapper脚本性能 #

如果你的Mapper是通过shell脚本调用Python代码，建议直接用Python作为Mapper（去掉shell层的开销），修改任务命令中的Mapper参数：

-mapper "python mapper.py"

同时优化Python代码的逻辑，比如减少不必要的字符串操作、复用对象、避免频繁IO等，降低单条记录的处理耗时。

4. 开启推测执行（临时缓解） #

虽然你提到开启后仍慢，但可以尝试调整推测执行的参数，让Hadoop更快启动备份任务：

-D mapred.map.tasks.speculative.execution=true
-D mapred.speculative.map.max.threads=2  # 允许同时运行2个备份Mapper

这不能解决根本问题，但能在一定程度上缩短任务总耗时。

内容的提问来源于stack exchange，提问作者HeyLight