这种Map完成后突然回退、Reduce反复重置的循环现象，在Hadoop集群里不算少见——本质是Map任务被重新触发执行，而Reduce阶段完全依赖Map的输出结果，所以只能跟着从头开始。下面是我实际排查过的几种常见原因和对应的解决办法：

1. TaskTracker节点不稳定（最常见诱因） #

集群里的某个TaskTracker节点大概率出了状况：比如内存不足触发OOM、磁盘IO打满、网络断断续续，导致JobTracker判定这个节点上的Map任务已失败，随即重新调度该Map任务到其他节点执行。这时候已经完成的Map进度就会回退，Reduce自然得重置从头来。

• 排查动作：去对应节点的$HADOOP_HOME/logs/tasktracker*.log日志里找关键词，比如OutOfMemoryError、No space left on device；同时用top、df -h实时监控节点的CPU、内存、磁盘使用率。
• 修复方案：给TaskTracker的JVM扩容（调整mapred.child.java.opts参数，比如设为-Xmx1024m）；清理节点冗余磁盘空间；如果是硬件故障，直接替换该节点。

2. Map输出数据损坏或丢失 #

Reduce阶段需要拉取Map任务的输出到本地处理，如果HDFS里的Map输出块损坏、丢失，Reduce就会触发Map任务重新生成输出数据，进而导致进度回退。

• 排查动作：用hdfs fsck /命令检查HDFS文件系统健康状态，看是否存在损坏的块；查看Map任务的日志，确认写入HDFS时有没有异常中断。
• 修复方案：确保HDFS副本数配置合理（默认3副本，可通过dfs.replication调整），保证数据冗余；如果是Map任务输出逻辑有问题（比如未正确处理异常导致写入失败），得针对性修改代码。

3. 任务重试机制配置过于激进 #

Hadoop默认会重试失败的任务，但如果重试次数设得过高，或者TaskTracker的超时阈值太严苛，可能导致JobTracker频繁误判任务失败，反复触发Map任务重试。

• 修复方案：调整mapred.map.max.attempts（Map任务最大重试次数）和mapred.reduce.max.attempts（Reduce任务最大重试次数），不要设置过高（默认4次，可根据集群稳定性调整）；同时检查mapred.jobtracker.tasktracker.expiry.interval，避免把临时卡顿的节点误判为死亡。

4. 集群资源被高优先级任务抢占 #

如果集群内有高优先级任务在运行，资源调度器可能会抢占当前任务的Map节点资源，导致正在运行的Map任务被强制终止，之后重新调度执行。

• 修复方案：检查资源调度器（比如YARN的CapacityScheduler）配置，确保当前任务所在队列有足够的资源配额；或者临时调高该任务的优先级，等集群资源空闲时再运行。

快速排查步骤 #

1. 先打开JobTracker的Web UI（默认端口50030），找到对应任务，查看失败的Map任务详情，明确具体失败原因；
2. 前往对应的TaskTracker节点查看日志，定位问题根源；
3. 根据排查结果调整配置、修复节点或修改代码。

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