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