整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

6.2. 失败 6.2.1. 经典MapReduce中的失败

hadoop 小红牛 8℃ 0评论

实际情况是,用户代码错误不断,进程崩溃,机器故障,如此种种。使用 Hadoop最主要的好处之一是它能处理此类故障并让你能够完成作业。

MapReduce 1运行时,主要考虑三种失败的模式:运行任务失败、tasktracker失败以及jobtracker失败。下面将逐一分析。

 

2.1.1. 任务运行失败

首先考虑子任务失败的情况。最常见的情况是map任务或reduce任务中的用户代码抛出运行异常。如果发生这种情况,子任务JVM进程会在退出之前印其父tasktracker发送错误报告。错误报告最后被记入用户日志。

tasktracker将此次任务任务尝试标记为failed(失败),释放任务槽运行另外一个任务。

对于Streaming任务,如果Streaming进程以非零退出代码退出,则被标记为failed。这种行为由 stream.non.zero.exit.is.failure 属性(默认 值为true)来控制。

另一种错误情况是子进程JVM突然退出,可能由于JVM软件缺陷而导致 MapReduce用户代码由于某些特殊原因造成JVM退出。在这种情况下, tasktracker会注意到进程已经退出并将此次任务尝试标记为failed(失 败)。

任务挂起的处理方式则有不同。一旦tasktracker注意到已经有一段时间没 有收到进度的更新,便会将任务标记为failed。在此之后,JVM子进程将 被杀死。05任务失败的超时间隔通常为10分钟,可以以作业为基础(或以集 群为基础)mapred.task.timeout属性设置为以毫秒为单位的值。 超时(timeout)设置为0将关闭超时判定,所以长时间运行的任务永远不会被 标记为failed。在这种情况下,被挂起的任务永远不会释放它的任务槽并 随着时间的推移最终降低整个集群的效率。因此,尽量避免这种设置,同 时充分确保每个任务能够定期汇报其进度。参见6.1.1节的补充材料 “MapReduce中进度的组成”。

jobtracker被告知一个任务尝试失败后(通过tasktracker的“心跳”调用), 将重新调度该任务的执行。jobtracker会尝试避免重新调度以前尝试失败的 tasktracker上的任务。此外,如果一个任务的失败次数超过4次,将不会再 重试。这个值是可以设置的:对于map任务,运行任务的最多尝试次数由 mapred.map.max.attempts属性控制|而对于reduce任务,则由 mapred.reduce.max.attempts属性控制。在默认情况下,如果任何任务 失败次数大于4(或最多尝试次数被配置为4),整个作业都会失败。

 

对于一些应用程序,我们不希望一旦有少数几个任务失败就中止运行整个 作业,因为即使有任务失败,作业的一些结果可能还是可用的。在这种情 况下,可以为作业设置在不触发作业失败的情况下允许任务失败的最大百 分比。map任务和reduce任务可以独立控制,分别通过mapred.max. map.failures.percent mapred.max.reduce.failures.percent 属性来设置。

任务尝试(task attempt)也是可以中止的(killed),这与失败不同。任务尝试可 以被中止是因为它是一个推测副本(相关详情可参见6.5.2节“推测执 行”),或因为它所处的tasktracker失败,导致jobtracker将它上面运行的 所有任务尝试标记为killed。被中止的任务尝试不会被计入任务运行尝试次 数(由 mapred.map.max.attempts mapredreduce.max.attempts 设 置),因为尝试中止并不是任务的过错。

用户也可以使用Web UI或命令行方式(输入hadoop job査看相应的选项) 来中止或取消任务尝试。也可以采用相同的机制来中止作业。

2.1.2. tasktracker 失败

tasktracker失败是另一种失败模式。如果一个tasktracker由于崩溃或运行过于缓慢而失败,会停止向jobtracker发送“心跳”(或很少发送“心跳”)。jobtracker会注意到已经停止发送“心跳”的tasktracker (假设它有10分钟没有接收到一个“心跳”。这个值由mapred.tasktracker.expiry.interval属性设置,以毫秒为单位)并将它从等待任务调度的tasktracker 池中移除。如果是未完成的作业,jobtracker会安排此tasktracker上已经运 行并成功完成的map任务重新运行,因为reduce任务无法访问它们的中间 输出结果(都存放在失败的tasktracker的本地文件系统上)。任何正在进行的 任务也都会被重新调度。

即使tasktracker没有失败,也可能被jobtracker列入黑名单。如果在一个特定的 tasktracker 上超过 4 (通过 mapre.max.tracker.failures 设置)来 自同一个作业的任务失败了,jobtracker就会将此记录为出错。如果 tasktracker上面的失败任务数超过最小阈值(默认值为4,mapred.max. tracker.blacklists设置)并远远高于集群中tasktracker的平均失败任 务数,就会被列入黑名单。

列入黑名单的tasktracker不再被分配任务,但会继续和jobtracker通信。随着错误期满(每天一次的比率)tasktracker有机会再次运行作业。另外,如 果有可修复的潜在错误(比如替换硬件),在tasktracker重启并重新加入集群后,它将从jobtracker的黑名单中移出。

2.1.3. jobtracker 失败

在所有失败中,jobtracker失败是最严重的。目前,Hadoop没有处理jobtracker失败的机制一一它是一个单点故障——因此在这种情况下,作业的执行注定是失败的。然而,这种失败发生的概率很小,因为具体某台机 器失败的几率很小。YARN进一步改善了这种情况,它的设计目标之一是 消除MapReduce中单点失败的可能性。

jobtracker重启后,在它停止时运行的所有士业都需要再次提交。配置选项 mapred.jotracker. restart. recover(默认为关闭)可尝试恢复所有运行作业,但它还不太可靠,因此建议不要用。

 

转载请注明:全栈大数据 » 6.2. 失败 6.2.1. 经典MapReduce中的失败

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址