GOON

人生如棋,我愿为卒,行动虽慢,却不曾后退半步!

导航

统计

公告

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)状态时的处理方法。

posted on 2012-02-23 16:01 知_卒 阅读(...) 评论(...) 编辑 收藏