在绝大多数现代 Hadoop 集群（Hadoop 2.2 及更高版本）的默认配置下，如果 ApplicationMaster (AM) 发生宕机，已经运行完成的 Map 任务是不需要重新跑的。

ResourceManager 会启动一个新的 ApplicationMaster 来接管工作，并恢复之前的作业状态。

以下是具体的原理解释和不同情况的分析：

1. 为什么不需要重新跑？（核心机制：AM 状态恢复）

Hadoop MapReduce 具有作业恢复机制（Job Recovery）。

• 状态持久化： 在作业运行期间，原来的 ApplicationMaster 会将任务的运行状态（包括哪些 Map 任务已经成功完成）持久化到 HDFS 上的作业提交目录中。
• Map 输出的存储： 已经完成的 Map 任务，其产生的中间结果数据是保存在运行该任务的 NodeManager 的本地磁盘上的，而不是随着 AM 的崩溃而消失。
• AM 重启接管： 当旧的 AM 宕机后，YARN 的 ResourceManager 会检测到，并在另一个节点上启动一个新的 AM。这个新的 AM 启动后，会去 HDFS 读取之前保存的作业状态。
• 继续执行： 新的 AM 发现某些 Map 任务已经标记为“完成（SUCCEEDED）”，它就会直接继承这个状态，并通知 Reduce 任务去对应的 NodeManager 节点拉取数据，从而避免了重复计算。

2. 需要满足的前提条件（默认已开启）

这个特性依赖于一个配置参数：yarn.app.mapreduce.am.job.recovery.enable。
在标准的 Hadoop 环境中，这个参数默认是 true。如果管理员硬性将其设置为 false，那么 AM 宕机后，整个作业就会从头开始，所有任务（包括已完成的 Map）都会重新跑（但这种情况在生产环境中极其罕见）。

3. 特殊情况（什么时候需要重新跑？）

虽然 AM 宕机本身不会导致已完成的 Map 任务重跑，但如果发生以下并发故障，已完成的 Map 任务就需要重跑：

• NodeManager 同时也宕机了： 如果不仅 AM 挂了，而且运行那个已完成 Map 任务的物理机器（NodeManager）也宕机了。因为 Map 的输出数据在那个节点的本地磁盘上，数据丢失了，新的 AM 在调度 Reduce 任务去拉取数据时会失败，此时 AM 会将该 Map 任务的状态重置，并安排重新运行。
• 重试次数耗尽： ApplicationMaster 本身也有最大重试次数限制（参数 yarn.resourcemanager.am.max-attempts，通常默认是 2 次）。如果 AM 连续宕机超过这个次数，整个 Job 就会被宣告失败（FAILED）。如果用户手动重新提交整个作业，那么当然所有的任务都要重新跑。

补充：正在运行中的（未完成）任务怎么办？

• 未完成的 Task： 如果 AM 宕机时，某些 Map 或 Reduce 任务正在运行，通常情况下，新的 AM 无法接管这些孤立的 Container，它们会被杀掉，然后新的 AM 会重新调度并运行这些未完成的任务。（注：YARN 后期版本引入了 Work-Preserving AM Restart 功能，部分情况下可以保留正在运行的 Container，但已完成的 Map 任务不重跑是始终保证的）。

总结： 只要集群配置正常，且保存 Map 输出数据的 NodeManager 没挂，ApplicationMaster 单点宕机重启后，已完成的 Map 任务绝对不需要重跑。