MapReduce 中的容错

Question

我正在阅读有关 Hadoop 以及它的容错性的文章。我阅读了 HDFS 并阅读了如何处理主节点和从节点的故障。但是，我找不到任何提到 mapreduce 如何执行容错的文档。特别是，当包含 Job Tracker 的主节点宕机或任何从节点宕机时会发生什么？

如果有人可以向我指出一些详细解释这一点的链接和参考资料。

Answer 1

MapReduce 层的容错取决于 hadoop 版本。hadoop.0.21之前的版本没有做checkpoint，JobTracker失败会导致数据丢失。

但是，从 hadoop.0.21 开始的版本，在 JobTracker 将其进度记录在文件中的位置添加了检查点。当 JobTracker 启动时，它会查找此类数据，以便它可以从停止的地方重新开始工作。

Answer 2

Hadoop 中的容错

如果 JobTracker 在指定的时间段内（默认情况下设置为 10 分钟）没有收到来自 TaskTracker 的任何心跳，JobTracker 就会知道与该 TaskTracker 关联的 worker 失败了。当这种情况发生时，JobTracker 需要将所有挂起和正在进行的任务重新安排到另一个 TaskTracker，因为属于失败的 TaskTracker 的中间数据可能不再可用。

如果所有已完成的 map 任务属于未完成的作业，也需要重新调度，因为位于失败的 TaskTracker 文件系统中的中间结果可能无法被 reduce 任务访问。

TaskTracker 也可以被列入黑名单。在这种情况下，列入黑名单的 TaskTracker 仍然与 JobTracker 保持通信，但没有将任务分配给相应的工作人员。当属于 TaskTracker 管理的特定作业的给定数量的任务（默认情况下，此数量设置为 4）失败时，系统认为发生了故障。

TaskTracker 发送给 JobTracker 的心跳中的一些相关信息是：任务跟踪器状态

? 重新启动

? 如果是第一次心跳

? 如果节点需要执行更多任务

TaskTrackerStatus 包含有关 TaskTracker 管理的 worker 的信息，例如可用的虚拟和物理内存以及有关 CPU 的信息。JobTracker 将黑名单与有故障的 TaskTracker 以及从该 TaskTracker 收到的最后一次心跳保持在一起。因此，当接收到新的重新启动/第一次心跳时，JobTracker 可以通过此信息决定是重新启动 TaskTracker 还是将 TaskTracker 从黑名单中删除

之后，在 JobTracker 中更新 TaskTracker 的状态并创建 HeartbeatResponse。此 HeartbeatResponse 包含 TaskTracker 将采取的下一个操作。如果有任务要执行，TaskTracker需要新任务（这是Heartbeat的一个参数）并且不在黑名单中，则创建清理任务和设置任务（清理/设置机制尚未深入研究） . 如果没有要执行的清理或设置任务，JobTracker 会获取新任务。当任务可用时，每个任务中都封装了 LunchTaskAction，然后 JobTracker 还查找：

- 被杀死的任务

- 杀死/清理的工作

- 输出尚未保存的任务。

所有这些操作（如果适用）都将添加到要在 HeartbeatResponse 中发送的操作列表中。Hadoop 中实现的容错机制仅限于在给定执行失败时重新分配任务。在这种情况下，支持两种情况： 1. 如果分配给给定 TaskTracker 的任务失败，则使用 Heartbeat 通信来通知 JobTracker，如果可能，JobTracker 会将任务重新分配给另一个节点。2. 如果 TaskTracker 失败，JobTracker 会注意到故障情况，因为它不会收到来自该 TaskTracker 的 Heartbeats。然后，JobTracker 会将 TaskTracker 的任务分配给另一个 TaskTracker。JobTracker 中还有一个单点故障，因为如果它失败，整个执行就会失败。

在 Hadoop 中实现的容错标准方法的主要好处在于它的简单性，并且它似乎在本地集群中运行良好。但是，对于大型分布式基础设施，标准方法还不够，节点之间的距离可能太大，并且重新分配任务所损失的时间可能会减慢系统速度