JobTracker知道一个task attempt失败后(通过TaskTracker的“心跳”调用),它将重新调度该任务的执行。JobTracker会尝试重新调度失败过的TaskTracker上的任务。此外,如果一个任务失败次数超过4次,它将不会再被重试。这个值是可以设置的:对于map任务,运行任务的最多尝试数由mapred.map.max.attempts属性控制;而对于reduce任务,则由mapred.reduce.max.attempts属性控制。在默认情况下,如果有任何任务失败次数大于4,整个作业都会失败。
对于一些应用程序,我们不希望一旦有少数几个任务失败就终止运行整个作业,因为即使有任务失败,作业的一些结果可能还是有可用的。在这种情况下,可以为作业设置在不触发作业失败的情况下允许任务失败的最大百分比。Map任务和reduce任务可以独立控制,分别通过mapred.max.map.failures.percent和mapred.max.reduce.failures.percent属性来设置。
任务尝试(task attempt)也是可以终止的(killed),这与失败不同。Task attempt可以中止是因为他是一个推测副本,或因为他所处的TaskTracker失败,导致JobTracker将它上面运行的所有task attempt标记为killed。被中止的task attempt不会被记入任务运行尝试次数,因为尝试中止并不是任务的错。
用户也可以使用web UI或命令行方式来中止或取消task attempt。作业可以采用相同的机制来中止。
4.2.TaskTracker失败
TaskTracker失败是另一种失败模式。如果一个TaskTracker由于崩溃或运行过于缓慢而失败,它将停止向JobTracker发送“心跳”。JobTracker会注意到已经停止发送“心跳”的TaskTracker(假设他有10分钟没有收到一个“心跳”。这个值由mapred.tasktracker.expiry.interval属性来设置,以毫秒为单位),并将它从等待任务调度的TaskTracker池中移除。如果是未完成的作业,JobTracker会安排此TaskTracker上已运行的map任务重新运行,因为reduce任务无法访问。他们的中间输入(都存放在失败的TaskTracker的本地文件系统上)。任何进行中的任务也都会被重新调度。
即使TaskTracker没有失败,也可能被JobTracker列入黑名单。如果TaskTracker上面的失败任务数远远高于集群的平均失败任务数,他就会被列入黑名单。被列入黑名单的TaskTracker可以通过重启从JobTracker的黑名单中移出。
4.3.JobTracker失败
JobTracker失败在所有失败中是最为严重的一种。较早版本的Hadoop没有处理JobTracker失败的机制—他是一个单点故障—因此在这种情况下,作业注定失败。然而,这种失败发生的概率很小,因为具体某台机器失败的几率很小。当前Hadoop可以通过Hadoop HA的配置解决这个故障。
5.作业的调度
早期版本的Hadoop使用一种非常简单的方法来调度用户的作业:按照作业提交的顺序,使用FIFO调度算法运行作业。典型情况下,每个作业都会使用整个集群,因此作业必须等待直到轮到自己运行。虽然共享集群极有可能为多用户提供大量资源,但问题在于如何公平的在用户之间分配资源,这需要一个更好的调度器。
随后,加入设置作业优先级的功能,可以通过设置mapred.job.priority属性或jobClient的setJobPriority()方法来设置优先级。作业调度器选择要运行的下一个作业时,他选择的是优先级最高的那个作业。然而,在FIFO调度算法中,优先级并不支持抢占,所以高优先级的作业仍然会被那些在高优先级作业被调度之前开始运行的、长时间运行的低优先级的作业所阻塞。
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-37299-7.html
的瑟的很
很重要
如果你说日本后面的主子才是关键