在Hadoop中提升task的启动速度

来源：互联网发布：2016外商直接投资数据编辑：程序博客网时间：2024/06/05 09:53

在增量DUMP过程中，我们的job比较小，但是启动非常频繁，每个job的执行时间短，通过执行的日志发现，有时会出现一个job的启动时间很长，需要几十秒。由于我们很看重增量的速度，所以几十秒的等待是不可接受的。

分析：

我们当时使用的Hadoop CDH3 Beta4 的版本。通过ganglia图表分析，出问题的tasktracker会出现一些流量的凸起。但是离带宽限制还很远。通过仔细分析TaskTracker的日志发现，Child子进程启动过程中，存在等待的问题。经过分析源码，Child子进程在启动过程是在一个线程中串行完成，启动过程包括了distributedcache文件的获取。由于Hadoop集群同时可能有各种各样的任务提交，所以当某个task的启动时间长，主要是下载distributedcache文件时间长，会影响下一个task的启动，严重的时候会影响tasktracker发送心跳。

处理方案1：

找出这些比较大的distributedcache，通过命令hadoop dfs -setrep [-R] <path> 设置更多的备份块，让网络负载能更均匀一些，这样对于当台机器而言，可以减少网络的out 流量，但是不能减少in流量，这样修改可以加快下载distributedcache的下载速度，缓解启动慢的问题，但是不能根本解决这个问题，而且当再次出现大的distributedcache任务时，问题还会重现。

处理方案2：

修改tasktracker的工作方式，最简单的办法，是让每个task各自通过一个task线程来启动，避免各个task之间的竞争，从根本上解决这个问题。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
classStartNewTask extendsThread {
  TaskInProgress tip = null;
 
  publicStartNewTask(TaskInProgress tip) {
    this.tip = tip;
  }
 
  publicvoid run() {
    try{
      LOG.debug("(StartNewTask start) tip="   tip.getTask().toString());
      startNewTask(tip);
      LOG.debug("(StartNewTask finish) tip="   tip.getTask().toString());
    }catch(InterruptedException e) {
      return;
    }catch(Throwable th) {
      LOG.error("TaskLauncher error "   StringUtils.stringifyException(th));
    }
  }
}

并且在TaskLauncher.run()中增加 new StartNewTask(tip).start()。

但是在解决过程这个问题的过程中，带入了新的问题，TaskTracker中关于正在运行的Job有两种锁，一个是runningJobs，用来锁住对Map<JobID, RunningJob> runningJobs 的访问，这个HashMap里放的是正在运行的所有job。另一个是rjob，用来存放单个job的信息。由于之前的代码中，是先获得runningJobs锁，再获得rjob锁，最后再释放runningJobs锁，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
privateRunningJob addTaskToJob(JobID jobId,
                                  TaskInProgress tip) {
    synchronized(runningJobs) {
      RunningJob rJob = null;
      if(!runningJobs.containsKey(jobId)) {
        rJob = newRunningJob(jobId);
        rJob.tasks = newHashSet();
        runningJobs.put(jobId, rJob);
      }else{
        rJob = runningJobs.get(jobId);
      }
      synchronized(rJob) {
        rJob.tasks.add(tip);
      }
      returnrJob;
    }
  }

由于setupCache的操作是在rJob锁里完成，这样也会间接导致runningJobs一直等待rJob。这样即使task启动是多线程，也会由于别的任务在下载distributedcache，长期暂用rjob的锁，导致其他线程的runningJobs等待rjob，导致当前的task启动在无法获得runningJobs。当然也有一个暴力的方法，就是强行把runningJobs和rjob分开，只有在更新runningJobs这个Map的时候，才需要获得锁，且锁住的范围，不包括rjob。但是这样的改动范围大，而且容易出错，造成死锁。

通过查看官方的jira https://issues.apache.org/jira/browse/MAPREDUCE-2364 这里解决的是当下载distributedcache时，去掉rjob的锁，从而使runningJobs和rjob锁住的操作中，没有长时间的任务。通过增加以下两个变量：

volatile boolean localized;

boolean localizing;

这两个变量控制是否需要下载distributedcache，从而去掉rjob的锁，具体修改可以查看这里的patch。

最终，我们的Hadoop版本，包括实现了多线程启动task和MAPREDUCE-2364的Patch。

结论：

通过以上2种方法，标本兼治，我们的task启动实现了没有延时，也不会相互干扰，稳定的运行增量DUMP任务。

0 0