一次因为数据问题引起的reduce被卡住streaming作业问题排查

        广告产品技术部有一个作业总是卡在某个reduce上，运行了好几个小时也运行不完，经过他们初步排查找不着问题原因，发邮件让我帮看看，我看了一下这个streaming作业是用python实现的，而且听他们描述，3月17之前该作业是没问题的，以下是可能存在问题的地方：

1、集群节点有问题

2、作业的配置参数不对，导致reduce运行有问题

3、数据问题

那就一一来排查这些问题吧。

第一点，我看了一下被卡住reduce运行的节点，NodeManager日志正常，dmesg日志正常，负载和内存使用都很正常，排查了集群问题的可能性。

第二点，我找到了被卡住reduce正在运行的java进程，通过jstat -gcutil $pid 和top -p $pid查看内存和cpu使用情况都很正常，堆内存是够用的，很长时间才出现一次FGC，不是内存的问题，看cpu使用情况，才0.3%的使用，严重正常，看来根本不是cpu的问题。

第三点，我看了一下reduce的日志，reduce任务已经完成了copy和merge，是在进行数据处理的时候出现被卡住的，那就是在执行python脚本的时候被卡住的，因为之前运行成功过，所以脚本应该是没问题的，那应该是数据问题了，由于问题总是被卡住在后缀是“r_000119”的reduce任务上，我找了一下mapreduce的环境变量，让他在执行reduce任务的python脚本里面加了一个逻辑，如果环境变量mapreduce_task_id(任务id)包含字符串“r_000119”，就把数据打印到标准错误输出以好排查问题，因为问题只会出现在“r_000119”的任务上，所以其他的reduce就不要打了，免得占用大量的集群空间，最后发现果然是数据问题，按逻辑来说一个key的数据不会超过1000，但是通过打印发现某些key的value只已经超过10000了，而python代码逻辑里面最多就任务数据不会超过1000，没做好容错方面的考虑，导致该任务长时间卡住。

总结：

问题排查时用到了mapreduce的环境变量mapreduce_task_id，其实还存在其他常用的环境变量，我这里列一下，以后好备用：

Name	Type	Description
mapreduce.job.id	String	The job id
mapreduce.job.jar	String	job.jar location in job directory
mapreduce.job.local.dir	String	The job specific shared scratch space
mapreduce.task.id	String	The task id
mapreduce.task.attempt.id	String	The task attempt id
mapreduce.task.ismap	boolean	Is this a map task
mapreduce.task.partition	int	The id of the task within the job
mapreduce.map.input.file	String	The filename that the map is reading from
mapreduce.map.input.start	long	The offset of the start of the map input split
mapreduce.map.input.length	long	The number of bytes in the map input split
mapreduce.task.output.dir	String	The task's temporary output directory

相关参数在streaming中“."用”_"代替即可。