hadoop–JobTracker 相关

JobTracker 内部使用三层表示：

JobInProgress： 跟踪和监控作业运行状态的对象。每个Job分成了多个Task。并为每个Task创建一个TaskInProgress跟踪和监控其运行状态。

而Task在运行过程中由于多种原因，比如软件Bug，硬件故障、推测机制等，每个Task可能尝试运行多次，直到运行成功或者超过尝试次数而失败。

每次的尝试为TaskAttemp。

作业使用JobId区分，JobId ： job的前缀字符串、JobTracker启动时间和作业提交顺序。

比如job_20128071706_0009

每个任务使用TaskID来区分， TaskID: JobID(前缀字符串为task)、任务类型(map 或者redice) 任务编号

比如task_201208071706_0009_m_000000  表示上面JobId表示的一个Job的一个Task

TaskAttemp也是用ID来区分，TaskAttemptID： 任务ID(前缀字符串attempt) 和运行尝试次数(从0开始)

比如 attempt_201208071706_0009_m_000000_0 表示上面TaskID表示的Task的一次尝试。

JobTracker的容错

  从作业的恢复粒度，当前存在三种不同级别的恢复机制，按照级别从低到高依次为

1. 作业级别: 将作业分成挖成的未完成的。对未完成的作业全部重新执行(包括作业中已经完成的Task)。
2. 任务级别：将任务分为完成的任务和未完成的任务。仅对未完成的任务重新执行。
3. 记录级别：仅对Task中未处理的记录重新执行。(学术研究中)

   级别越低实现越简单，但是资源的浪费越严重。目前简化设计考虑，采用的是作业级别的恢复机制。

任务推测执行

为解决部分作业慢拖后腿的问题，提出了任务推测执行机制。为拖后的任务启动一个备份任务。该任务和原始任务同时处理同一份数据，最终选用先成功运行完成的任务的计算结果作为最终的结果。

     该问题出现的原因为Hadoop设计上的假设

1. 每个节点的计算能力是一样的
2. 任务的执行进度随时间线性增加
3. 启动一个备份任务的代价可以忽略不计
4. 一个任务的进度可以表示成已完成工作量占总工作量的比例。
5. 同一个作业的同种类型的任务的工作量是一样的。所用时间也相同。

    实际情况是复杂的，由于集群异构或者负载不均衡，就会产生问题。

  hadoop 1.0.0的算法

        一个任务同时满足以下添加，就会为该任务启动一个备份任务：

1. 该任务尚未进入skip mode(由于推测执行机制和跳过坏记录机制均会拖慢任务执行进度，考虑到性能问题，不会同时启用这两个功能)
2. 该任务没有其他正在运行的备份任务(当前Hadoop最多允许一个任务同时启动两个Task Attempt)
3. 该任务已经运行时间超过60 s，并且当前正在运行的Task Attempt落后(通作业内所有TaskAttempt)平均进度的20%。

   当任务的某个Task Attempt成功运行后，JobTracker会杀掉另外一个Task Attempt

      上面算法的问题是：

1. 20% 空间问题。即当作业内大部分任务已经完成，而若干个Task Attempt的进度已经大于等于80%，则永远不会触发启动备份任务。
2. 缺乏保证备份任务执行速度的机制：新启动的备份任务需要首先处理原始Task Attempt已经处理完的数据，因此需要保证备份任务的运行速度不低于原始Task Attempt，否则就没有必要启动备份任务。
3. 参数不可配置： 即设定的20%% 和60s都是不可配置的。不能满足用户根据自己集群特点定制参数的要求

0.21.0版本的算法

    配置选项

1. mapreduce.job.speculative.slownodethreshold ： 任意一个TaskTracker 已完成任务的平均进度增长率和所有已完成任务的平均进度增长率的最大允许差距。 默认为1. 超过阈值时标明该TaskTracker的性能比较低，不会在其上启动一个备份任务。
2. mapreduce.job.speculative.slowtaskthreshold： 作业的任意一个任务的平均进度增长率与所有正在运行任务的平均进度增长率的最大允许差距。默认为1.超过阈值标明该任务运行过慢，需要启动一个备份任务。
3. mapreduce.job.speculative.speculativecap： 限定作业允许启动备份任务的任务数目占正在运行任务的百分比。默认为0.1，即为一个作业启动推测执行功能的任务数不能超过过正在运行任务的10%

   启动备份任务

1. 判断Task Tracker X是否是一个慢Task Tracker，如果是，则不能启动任何备份任务
2. 检查作业J 是否启动的备份任务数超过限制。
3. 筛选出作业J总满足调价的任务保存在数据candidates中
1. 该任务未在TaskTracker X上运行失败过。
2. 该任务没有其他正在运行的备份任务
3. 该任务以运行时间超过60s
4. 该任务已经出现拖后腿现象。
4. 按照运行剩余时间从大到小对candidates中的任务派讯，选择剩余时间最大的任务为其启动备份任务。

     该算法的缺点是：

1. 任务进度和剩余时间估算不准确，导致部分正常任务被误认为是拖后腿，从而造成资源浪费
2. 未针对任务类型节点分类： 即需要对Map Task和Reduce Task区分，对于Map Task是慢节点的，对Reduce Task也许是快节点。

2.0 版本的算法

    重点关注备份任务是否有潜力比当前正在运行的任务完成的更早。

调度策略

1. 针对Map Task 考虑数据本地性
2. Map task选择策略
1. 优先选择运行失败的任务
2. 其次是尚未运行的任务
3. 最后是正在运行的任务，为拖后腿的任务启动备份任务
3. Reduce Task 选择策略 从未运行的任务列表中选择第一个满足条件的任务。