【转】Jobtracker重启Job recovery过程分析

Jobtracker重启Job recovery过程分析

1.  Job Recovery的有关配置项

配置项	默认值	含义
mapred.jobtracker.restart.recover	false	true时JT重启之前运行的job可以在jobtracker restart之后恢复，false则需要重新运行。
mapred.jobtracker.job.history.block.size	3145728	保存Job历史日志文件的大小，job的恢复就是使用这些历史日志。
hadoop.job.history.location	${hadoop.log.dir}/history	Job history存储位置

2.   Job 如何恢复运行

1)   日志文件：jobtracker restart之后恢复一个正在运行的job，首先通过解析job日志文件，通过job日志文件恢复job的一些task的运行状况。

2)   JT restart之后TT再次连接上JT时向JT汇报他们运行task的情况。

3)    JT重启之后，对1）和2）中没有恢复的task和还没运行的task重新调度运行。

3.   Job Recovery 相关类

Job Recover过程主要通过JobTracker.RecoveryManager类进行管理，job日志的记录和解析主要有JobHistory类完成。

4.   Job Recover的详细过程

1)   JobTracker restart之后首先检查是否有需要恢复的job，通过RecoveryManager. checkAndAddJob()实现。

2)    如果有要恢复的job，在offerService()中启动RecoverManager.recover()开始恢复job：

(1)  初始化jobs，根据"mapred.system.dir"目录文件信息缓存需要恢复job的JobID以及该job history日志文件路径。

(2)在日志文件中恢复job：根据job恢复日志的路径得到恢复日志，首先通过 JobHistory.parseHistoryFromFS(String path, Listener l, FileSystem fs)解析job日志文件，提取日志文件的每一行信息（path是指日志文件的路径，Listener是一个监听器），然后通过 JobRecoveryListener.handle()来处理每行日志信息恢复job运行状况。

3)   所有job日志文件解析恢复完成之后，TaskTracker重新连接 上JT的时候，TT会向JT汇报他们上面运行的task状况，实现过程如下（在 JobTracker.updateTaskStatuses(TaskTrackerStatus status)中）：

if (tip != null || hasRestarted()) {
          if (tip == null) {
          tip = job.getTaskInProgress(taskId.getTaskID());
          job.addRunningTaskToTIP(tip, taskId, status, false);
          }        

 }

5.  总结：虽然hadoop提供了Jobtracker restart之后job recover过程，最近在做JobTracker HA，发现但该过程还存在着很多问题

1)   Job日志有缓存，刷入日志文件不急时，这个可能导致的问题：

(1)  jobtracker restart 之后job恢复运行的时候会出现task失去连接：
2012-02-16 17:11:49,224 INFO org.apache.hadoop.mapred.JobTracker: attempt_201202161703_0002_m_000039_0 is 200024 ms debug.
attempt_201202161703_0002_m_000039_0 is 400036 ms debug.
attempt_201202161703_0002_m_000039_0 is 600047 ms debug.
Launching task attempt_201202161703_0002_m_000039_0 timed out.
这样需要等9分钟之后确定该task timeout之后才会重新再运行该task
原 因：由于日志刷入日志文件不够及时，日志文件中记录有一个task的attempt task启动时的信息，而没记录他运行结束时的信息（其实已经运行成功），job恢复的时候，Jt误认为该task还在运行，然后一直等TT向它汇报该 task的信息，直到该task timeout。（实际该task在JT重启前已经完成了，所有JT重启之后，TT不会再汇报该task的状态）

(2)一个小job，所有task都在运行，job日志还没刷入日志文件，这时重启JT的时候，job 再运行的时候出现cleanup job在setup job完成之前完成，导致JT一直认为这个job还在运行中。

(3)JT restart之后重新运行job出现job的reduce task比map task先完成的情况

2)   JT restart之后TT再次连接上JT之后，TT向JT汇报状态时，JT处理时没有考虑cleanup task（killed/failed  uncleanup task）状态的task

if (tip != null || hasRestarted()) {
          if (tip == null) {
          tip = job.getTaskInProgress(taskId.getTaskID());
          job.addRunningTaskToTIP(tip, taskId, status, false);
          }        

 }

如上，JT会把所有的task做相同的处 理：job.addRunningTaskToTIP(tip, taskId, status, false)，此时若果task是cleanup task（killed/failed  uncleanup task）这种task时，JT会把它当作普通的task运行，由于cleanup task（killed/failed  uncleanup task）和之前运行该task时采用相同的attempt ID，最后导致JT调度的时候会出现一个task有两个相同的attempt ID，该task会一直处于holding状态（和HADOOP-5394不同）。

3)   解决方案：

（1）为了解决日志刷新不及时问题可以对log4j新增一个appender支持周期性地刷新log到磁盘。

（2） 为了解决上面2）的问题，可以在if (tip != null || hasRestarted())处加上当task处于cleanup task（killed/failed  uncleanup task）状态时的处理方法。

 

原文链接：http://www.cnblogs.com/MGGOON/archive/2012/02/23/2365055.html