hadoop源码分析（MapReduce）

原文地址：http://wwangcg.iteye.com/category/171858【good 也有其他方面的内容】

hadoop 源码分析(一) jobClient 提交到JobTracker

博客分类： 
• hadoop

hadoopjobclientjobTracker 

  

   Hadoop 用了2年多了.从最初一起创业的11人20台服务器集群到后来独立搭建基于hadoop nutch的搜索引擎并商用化 到现在也2年了.这两年来应用了很多新技术也经历了很多,从数据仓库的Hive pig 到mapreduce的编码去解决算法或是etl的问题 等等都离不开hadoop.觉得用了2年多也到了该总结的时候了.故此想重新翻译hadoop 源码,按照不同的类方法的不同作用.也希望读到这篇博客的人和我一起 经历这一段岁月,一起讲hadoop的核心结合实用主义 传递给中国的开源软件使用者。

 

 下图为 jobClient 提交到 Mapreduce 作业到JobTracker 核心逻辑。

 

 

 1.JobProfile类：

　job的描述性元语,相当于bean的功能.其中包括:

  user job的提交者

  jobid 唯一的标志一个job的ID  ->JobID 类生成：

      --jobid 包括两部分.第一部分代表jobTracker 标志,第二部分代表时间.如果是本地job(local Job) 则为local,最后为 job数量,代表是第   几个job

  jobFile job运行时文件

  url  定位该条job的描述性信息url

  name  job的名字

  queueName  job 队列名称,

 

2.JobStatus 类：

   -- job的几种状态

  running

  successed

  failed

    prep

  killed

3.copyAndConfigureFiles（） 方法：

 1.JobSubmissionFiles  工具类 负责管理 job 相关文件：

   conf 路径

   jar 包路径

   分布式缓存(distributed cache files(archives,libjars,)) 路径

 拷贝job执行文件到 job执行目录 

4.writeNewSplits（）

 mapred.max.split.size 设置最小输入分片

  mapred.max.split.size  最大分片的大小

 计算输入分片

 FileInputFormat  ->getSplits（）->computeSplitSize（）方法 

分片计算法：

 1.首先 获取文件的长度 length

 2.获取blocksize

 3. 获取最 大分片大小 getMaxSplitSize

 4.取 maxsize 和 block 中 的较小者 A

 5. 取 最新分片和 A 中的最大者 作为分片大小

 6.如果文件长度 length/分片大小 >1.1 则调用FileSplit 分片

FileInputFormat 类:

setInputPaths（(Job job,  Path... inputPaths) 可添加多个输入路径

 

 

• 查看图片附件

1.JobClient 客户端类 通过调用 JobSubmissionProtocol 接口 的 submit 方法提交作业 
2. JobSubmissionProtocol  接口为 JobClient 和JobTracker 共同执行的接口，因此它是一个可代理的接口 
3. 调用 createRPCProxy() 通过远程RPC 调用实现动态代理 JobTracker 类的 submitJob 方法 

Java代码  

1. private static JobSubmissionProtocol createRPCProxy(InetSocketAddress addr,  
2.      Configuration conf) throws IOException {  
3.    return (JobSubmissionProtocol)[color=red][size=medium] RPC.getProxy[/size][/color](JobSubmissionProtocol.class,  
4.        JobSubmissionProtocol.versionID, addr,   
5.        UserGroupInformation.getCurrentUser(), conf,  
6.        NetUtils.getSocketFactory(conf, JobSubmissionProtocol.class));  
7.  }  

打开RPC 类 的 getProxy 方法 

Java代码  

1. public static VersionedProtocol getProxy(  
2.       Class<? extends VersionedProtocol> protocol,  
3.       long clientVersion, InetSocketAddress addr, UserGroupInformation ticket,  
4.       Configuration conf, SocketFactory factory, int rpcTimeout) throws IOException {  
5.   
6.     if (UserGroupInformation.isSecurityEnabled()) {  
7.       SaslRpcServer.init(conf);  
8.     }  
9.     VersionedProtocol proxy =  
10.         (VersionedProtocol)[color=red][size=medium] Proxy.newProxyInstance[/size][/color](  
11.             protocol.getClassLoader(), new Class[] { protocol },  
12.             new Invoker(protocol, addr, ticket, conf, factory, rpcTimeout));  
13.     long serverVersion = proxy.getProtocolVersion(protocol.getName(),   
14.                                                   clientVersion);  
15.     if (serverVersion == clientVersion) {  
16.       return proxy;  
17.     } else {  
18.       throw new VersionMismatch(protocol.getName(), clientVersion,   
19.                                 serverVersion);  
20.     }  
21.   }  

通过RPC  远程调用连接到服务端后.通过传入代理接口 获取到JobTracker 类 
代理模式 就详细的讲了,如有必要 可翻看java代理模式 

这里 getPoxy() 方法中调用  new Invoker(protocol, addr, ticket, conf, factory, rpcTimeout)) 通过new Invoker() 获得client.该cleintt 先判断ClientCache 是不是已经含有该client 如果有则加+1 如果没有 则new Client 生成一个 代码如下 

Java代码  

1.  private synchronized Client getClient(Configuration conf,  
2.         SocketFactory factory) {  
3.       // Construct & cache client.  The configuration is only used for timeout,  
4.       // and Clients have connection pools.  So we can either (a) lose some  
5.       // connection pooling and leak sockets, or (b) use the same timeout for all  
6.       // configurations.  Since the IPC is usually intended globally, not  
7.       // per-job, we choose (a).  
8.       Client client = clients.get(factory);  
9.       if (client == null) {  
10.         client = new Client(ObjectWritable.class, conf, factory);  
11.         clients.put(factory, client);  
12.       } else {  
13.         client.incCount();  
14.       }  
15.       return client;  
16.     }  
17. /* 每次 +1 */  
18.  synchronized void incCount() {  
19.     refCount++;  
20.   }  
21.     

JobTracker 将其加入到job队列中 

该过程 完成了 用户通过JobClient 像JobTracker 提交作业的流程,提交的过程中不是通过直接提交而是通过了rpc 通信 创建JobClient 代理 通过代理模式提交 

• 查看图片附件

hadoop 源码分析(三) hadoop RPC 机制

博客分类： 
• hadoop

hadooprpc 

  
  Hadoop 通信机制采用自己编写的RPC. 相比于其他复杂的rpc框架着实清爽了许多.rpc在hadoop中扮演的角色是通信和数据传输在client和server端,以及datanode和namenode 心跳数据以及jobTracker 和taskTracker 通信 


1. Client 与 server 端通信采用Writable 序列化形式.因此hadoop中信息的传递 必须继承自writable 接口,writable 接口有两个方法 write 和read 
2. Client 端通过调用Call 方法,将消息序列化为writable 形式与server端通信 
3. Client 调用sendPing() 到server端.每隔一定时间,Ping时间间隔通过ipc.ping.interval 配置 
4. connection方法为多路复用.多个call请求公用一个call方法,通过addCall( ) 将call 加入hash 的call队列中，但是response则单独处理,call 队列 Hashtable<Integer, Call> calls = new Hashtable<Integer, Call>() 
5. Server 端通过NIO方式将serveraddress bind到lister. 
6. Reader为读入监听到的动作key 交给doRead 去读出来 


其实hadoop的RPC 比较简单,无非就是通过wirtable 序列化 在client 和server 端传输数据.其中包括 心跳检测.client 传参数给服务端代理执行器方法等,jobClient 代理直接JobTracker的方法其中传参数的协议就是通过RPC 序列化参数传给服务端 

Java代码  

1. /** Get a connection from the pool, or create a new one and add it to the 
2.    * pool.  Connections to a given ConnectionId are reused. */  
3.    private Connection getConnection(ConnectionId remoteId,  
4.                                    Call call)  
5.                                    throws IOException, InterruptedException {  
6.     if (!running.get()) {  
7.       // the client is stopped  
8.       throw new IOException("The client is stopped");  
9.     }  
10.     Connection connection;  
11.     /* we could avoid this allocation for each RPC by having a   
12.      * connectionsId object and with set() method. We need to manage the 
13.      * refs for keys in HashMap properly. For now its ok. 
14.      */  
15.     do {  
16.       synchronized (connections) {  
17.         connection = connections.get(remoteId);  
18.         if (connection == null) {  
19.           connection = new Connection(remoteId);  
20.           connections.put(remoteId, connection);  
21.         }  
22.       }  
23.     } while (!connection.addCall(call));  
24.       
25.     //we don't invoke the method below inside "synchronized (connections)"  
26.     //block above. The reason for that is if the server happens to be slow,  
27.     //it will take longer to establish a connection and that will slow the  
28. //entire system down.  
29. // setupIOstreams 方法建立IO通道.client和server 建立链接  
30.     connection.setupIOstreams();  
31.     return connection;  
32.   }  

• 查看图片附件

hadoop 源码分析(四)JobTracker 添加job 到schduler 队列中

博客分类： 
• hadoop

hadoopjobtracker 

  启动 JobTracker 
1. 进入main方法： 
   

Java代码  

1. //执行startTracker 方法  
2.      JobTracker tracker = startTracker(new JobConf());  
3.     //执行offerService()方法  
4.      tracker.offerService();  

3.startTracker()方法中 
       

Java代码  

1. // new JobTracker 方法  
2.          result = new JobTracker(conf, identifier);  
3.        result.taskScheduler.setTaskTrackerManager(result);  

2. JobTracker()构造方法中初始化信息 
     (1) static constants 变量 
     (2) 加载调度器 默认为FIFO 调度 
      /

Java代码  

1. / Create the scheduler  
2.           Class<? extends TaskScheduler> schedulerClass  
3.           = conf.getClass("mapred.jobtracker.taskScheduler",  
4.           JobQueueTaskScheduler.class, TaskScheduler.class);  
5. taskScheduler=(TaskScheduler)ReflectionUtils.newInstance(schedulerClass, conf);  

taskScheduler 默认的执行类为JobQueueTaskScheduler ,当启动JobTracker 的时候 调用了 tracker.offerService();该方法执行了父类的 start()方法.该start()方法为 JobQueueTaskScheduler 的start方法: 
       

Java代码  

1.   @Override  
2.           public synchronized void start() throws IOException {  
3.            super.start();  
4. taskTrackerManager.addJobInProgressListener(jobQueueJobInProgressListener);  
5. eagerTaskInitializationListener.setTaskTrackerManager(taskTrackerManager);  
6.            eagerTaskInitializationListener.start();  
7.            taskTrackerManager.addJobInProgressListener(  
8.            eagerTaskInitializationListener);  
9.   }  

在这个方法中调用了addJobInProgressListener()将lister 加入到了 jobTracker中,这个过程很绕,可通过下面的流程图梳理清楚 

3. 启动jettyServer 

Java代码  

1. infoServer.addServlet("reducegraph", "/taskgraph", TaskGraphServlet.class);  
2. infoServer.start();  

  JobTracker 提交job 
1. jobClient()通过代理 调用JobTracker的submit方法提交job 
2. submitJob方法中 调用了 addJob()将job添加到job队列中，等待执行 
3. addJob方法： 
   

Java代码  

1. private synchronized JobStatus addJob(JobID jobId, JobInProgress job)   
2.     throws IOException {  
3.    totalSubmissions++;  
4.   
5.    synchronized (jobs) {  
6.      synchronized (taskScheduler) {  
7.        jobs.put(job.getProfile().getJobID(), job);  
8.       // jobInProgressListeners list 在start jobTracker 的时候,在JobQueueTaskScheduler 的start方法中初始化加入了两个listener ：  
9.       eagerTaskInitializationListener 和jobQueueJobInProgressListener   
10.        for (JobInProgressListener listener : jobInProgressListeners) {  
11.          listener.jobAdded(job);  
12.        }  
13.      }  
14.    }  
15.    myInstrumentation.submitJob(job.getJobConf(), jobId);  
16.    job.getQueueMetrics().submitJob(job.getJobConf(), jobId);  
17.   
18.    LOG.info("Job " + jobId + " added successfully for user '"   
19.             + job.getJobConf().getUser() + "' to queue '"   
20.             + job.getJobConf().getQueueName() + "'");  
21.    AuditLogger.logSuccess(job.getUser(),   
22.        Operation.SUBMIT_JOB.name(), jobId.toString());  
23.    return job.getStatus();  
24.  }  

• 查看图片附件

hadoop 源码分析(五)hadoop 任务调度TaskScheduler

博客分类： 
• hadoop

hadoopmapreducetaskScheduler 

hadoop mapreduce  之所有能够实现job的运行,以及将job分配到不同datanode 上的map和reduce task 是由TaskSchduler 完成的. 

TaskScheduler mapreduce的任务调度器类,当jobClient 提交一个job 给JobTracker 的时候.JobTracker 接受taskTracker 的心跳.心跳信息含有空闲的slot信息等.JobTracker 则通过调用TaskScheduler 的assignTasks()方法类给报告心跳信息中含有空闲的slots信息的taskTracker 分布任务、 

TaskScheduler 类为hadoop的 调度器的抽象类。默认继承它作为hadoop调度器的方式为FIFO,当然也有Capacity 和Fair等其他调度器,也可以自己编写符合特定场景所需要的调度器.通过继承TaskScheduler 类即可完成该功能、 
下面就 FIFO 调度器进行简单的说明： 

JobQueueTaskScheduler 类为FIFO 调度器的实现类. 
1. 首先JobQueueTaskSchduler 注册两个监听器类： 
JobQueueJobInProgressListener jobQueueJobInProgressListener; 
EagerTaskInitializationListener eagerTaskInitializationListener; 

JobQueueJobInProgressListener 维护一个job的queue ,其中JobSchedulingInfo 中包含job调度的信息:priority,startTime,id.以及 jobAdd update 等操作jobqueue的方法 
EagerTaskInitializationListener 初始化job的listener ,这里所谓的初始化不是初始化job的属性信息，而是针对已经存在jobqueue中 即将被执行job的初始化, 

Java代码  

1. class JobInitManager implements Runnable {  
2.      
3.     public void run() {  
4.       JobInProgress job = null;  
5.       while (true) {  
6.         try {  
7.           synchronized (jobInitQueue) {  
8.             while (jobInitQueue.isEmpty()) {  
9.               jobInitQueue.wait();  
10.             }  
11.             job = jobInitQueue.remove(0);  
12.           }  
13.           threadPool.execute(new InitJob(job));  
14.         } catch (InterruptedException t) {  
15.           LOG.info("JobInitManagerThread interrupted.");  
16.           break;  
17.         }   
18.       }  
19.       LOG.info("Shutting down thread pool");  
20.       threadPool.shutdownNow();  
21.     }  
22.   }  

resortInitQueue 按照priority 和starttime 来排序 
jobRemoved() 
jobUpdated() 
jobStateChanged()当priority或是starttime被改变的时候则重新调用resortInitQueue()重新排序 

Java代码  

1. public EagerTaskInitializationListener(Configuration conf) {  
2.     numThreads = conf.getInt("mapred.jobinit.threads", DEFAULT_NUM_THREADS);  
3.     threadPool = Executors.newFixedThreadPool(numThreads);  
4.   }  

在JobTracker 启动的时候 创建 mapred.jobinit.threads 改数量的线程去监控jobqueue.当jobqueue 中含有job的时候 则initjob 

Java代码  

1. class InitJob implements Runnable {  
2.     
3.     private JobInProgress job;  
4.       
5.     public InitJob(JobInProgress job) {  
6.       this.job = job;  
7.     }  
8.       
9. //调用run方法 回调TaskTrackerManager  
10.     public void run() {  
11.       ttm.initJob(job);  
12.     }  
13.   }  

调度其中核心逻辑在assignTasks()方法中 
下面分析分析 FIFO模式下的 assignTasks() 

Java代码  

1. @Override  
2.   public synchronized List<Task> assignTasks(TaskTracker taskTracker)  
3.       throws IOException {  
4.     TaskTrackerStatus taskTrackerStatus = taskTracker.getStatus();   
5. ClusterStatus clusterStatus = taskTrackerManager.getClusterStatus();  
6. //获取集群中TaskTracker 总数  
7. final int numTaskTrackers = clusterStatus.getTaskTrackers();  
8. //集群中map slot总数  
9. final int clusterMapCapacity = clusterStatus.getMaxMapTasks();  
10.  //集群中reduce slot 总数  
11.     final int clusterReduceCapacity = clusterStatus.getMaxReduceTasks();  
12.   
13.     Collection<JobInProgress> jobQueue =  
14.       jobQueueJobInProgressListener.getJobQueue();  
15.   
16.     //  
17.     // Get map + reduce counts for the current tracker.  
18. //  
19. //当前的taskTracker 上map slot 总数  
20. final int trackerMapCapacity = taskTrackerStatus.getMaxMapSlots();  
21. //当前的taskTracker 上reduce slot 总数  
22. final int trackerReduceCapacity = taskTrackerStatus.getMaxReduceSlots();  
23. //当前的taskTracker上正在运行的 map数目  
24. final int trackerRunningMaps = taskTrackerStatus.countMapTasks();  
25. //当前的taskTracker上正在运行的 reduce数目  
26.     final int trackerRunningReduces = taskTrackerStatus.countReduceTasks();  
27.   
28.     // Assigned tasks  
29.     List<Task> assignedTasks = new ArrayList<Task>();  
30.   
31.     //  
32.     // Compute (running + pending) map and reduce task numbers across pool  
33. //  
34. //该taskTracker上剩余的reduce数  
35. int remainingReduceLoad = 0;  
36. //该taskTracker 剩余的map数  
37.     int remainingMapLoad = 0;  
38.     synchronized (jobQueue) {  
39.       for (JobInProgress job : jobQueue) {  
40.         if (job.getStatus().getRunState() == JobStatus.RUNNING) {  
41.           remainingMapLoad += (job.desiredMaps() - job.finishedMaps());  
42.           if (job.scheduleReduces()) {  
43.             remainingReduceLoad +=   
44.               (job.desiredReduces() - job.finishedReduces());  
45.           }  
46.         }  
47.       }  
48.     }  
49.   
50. // Compute the 'load factor' for maps and reduces  
51. //map因子  
52.     double mapLoadFactor = 0.0;  
53.     if (clusterMapCapacity > 0) {  
54.       mapLoadFactor = (double)remainingMapLoad / clusterMapCapacity;  
55.     }  
56.     double reduceLoadFactor = 0.0;  
57.     if (clusterReduceCapacity > 0) {  
58.       reduceLoadFactor = (double)remainingReduceLoad / clusterReduceCapacity;  
59.     }  
60.           
61.     //  
62.     // In the below steps, we allocate first map tasks (if appropriate),  
63.     // and then reduce tasks if appropriate.  We go through all jobs  
64.     // in order of job arrival; jobs only get serviced if their   
65.     // predecessors are serviced, too.  
66.     //  
67.   
68.     //  
69.     // We assign tasks to the current taskTracker if the given machine   
70.     // has a workload that's less than the maximum load of that kind of  
71.     // task.  
72.     // However, if the cluster is close to getting loaded i.e. we don't  
73.     // have enough _padding_ for speculative executions etc., we only   
74.     // schedule the "highest priority" task i.e. the task from the job   
75.     // with the highest priority.  
76.     //  
77.       
78.     final int trackerCurrentMapCapacity =   
79.       Math.min((int)Math.ceil(mapLoadFactor * trackerMapCapacity),   
80.                               trackerMapCapacity);  
81.     int availableMapSlots = trackerCurrentMapCapacity - trackerRunningMaps;  
82.     boolean exceededMapPadding = false;  
83.     if (availableMapSlots > 0) {  
84.       exceededMapPadding =   
85.         exceededPadding(true, clusterStatus, trackerMapCapacity);  
86.     }  
87.       
88.     int numLocalMaps = 0;  
89.     int numNonLocalMaps = 0;  
90.     scheduleMaps:  
91.     for (int i=0; i < availableMapSlots; ++i) {  
92.       synchronized (jobQueue) {  
93.         for (JobInProgress job : jobQueue) {  
94.           if (job.getStatus().getRunState() != JobStatus.RUNNING) {  
95.             continue;  
96.           }  
97.   
98.           Task t = null;  
99.             
100.           // Try to schedule a node-local or rack-local Map task  
101.           t =   
102.             job.obtainNewNodeOrRackLocalMapTask(taskTrackerStatus,   
103.                 numTaskTrackers, taskTrackerManager.getNumberOfUniqueHosts());  
104.           if (t != null) {  
105.             assignedTasks.add(t);  
106.             ++numLocalMaps;  
107.               
108.             // Don't assign map tasks to the hilt!  
109.             // Leave some free slots in the cluster for future task-failures,  
110.             // speculative tasks etc. beyond the highest priority job  
111.             if (exceededMapPadding) {  
112.               break scheduleMaps;  
113.             }  
114.              
115.             // Try all jobs again for the next Map task   
116.             break;  
117.           }  
118.             
119.           // Try to schedule a node-local or rack-local Map task  
120.           t =   
121.             job.obtainNewNonLocalMapTask(taskTrackerStatus, numTaskTrackers,  
122.                                    taskTrackerManager.getNumberOfUniqueHosts());  
123.             
124.           if (t != null) {  
125.             assignedTasks.add(t);  
126.             ++numNonLocalMaps;  
127.               
128.             // We assign at most 1 off-switch or speculative task  
129.             // This is to prevent TaskTrackers from stealing local-tasks  
130.             // from other TaskTrackers.  
131.             break scheduleMaps;  
132.           }  
133.         }  
134.       }  
135.     }  
136.     int assignedMaps = assignedTasks.size();  
137.   
138.     //  
139.     // Same thing, but for reduce tasks  
140.     // However we _never_ assign more than 1 reduce task per heartbeat  
141.     //  
142.     final int trackerCurrentReduceCapacity =   
143.       Math.min((int)Math.ceil(reduceLoadFactor * trackerReduceCapacity),   
144.                trackerReduceCapacity);  
145.     final int availableReduceSlots =   
146.       Math.min((trackerCurrentReduceCapacity - trackerRunningReduces), 1);  
147.     boolean exceededReducePadding = false;  
148.     if (availableReduceSlots > 0) {  
149.       exceededReducePadding = exceededPadding(false, clusterStatus,   
150.                                               trackerReduceCapacity);  
151.       synchronized (jobQueue) {  
152.         for (JobInProgress job : jobQueue) {  
153.           if (job.getStatus().getRunState() != JobStatus.RUNNING ||  
154.               job.numReduceTasks == 0) {  
155.             continue;  
156.           }  
157.   
158.           Task t =   
159.             job.obtainNewReduceTask(taskTrackerStatus, numTaskTrackers,   
160.                                     taskTrackerManager.getNumberOfUniqueHosts()  
161.                                     );  
162.           if (t != null) {  
163.             assignedTasks.add(t);  
164.             break;  
165.           }  
166.             
167.           // Don't assign reduce tasks to the hilt!  
168.           // Leave some free slots in the cluster for future task-failures,  
169.           // speculative tasks etc. beyond the highest priority job  
170.           if (exceededReducePadding) {  
171.             break;  
172.           }  
173.         }  
174.       }  
175.     }  
176.       
177.     if (LOG.isDebugEnabled()) {  
178.       LOG.debug("Task assignments for " + taskTrackerStatus.getTrackerName() + " --> " +  
179.                 "[" + mapLoadFactor + ", " + trackerMapCapacity + ", " +   
180.                 trackerCurrentMapCapacity + ", " + trackerRunningMaps + "] -> [" +   
181.                 (trackerCurrentMapCapacity - trackerRunningMaps) + ", " +  
182.                 assignedMaps + " (" + numLocalMaps + ", " + numNonLocalMaps +   
183.                 ")] [" + reduceLoadFactor + ", " + trackerReduceCapacity + ", " +   
184.                 trackerCurrentReduceCapacity + "," + trackerRunningReduces +   
185.                 "] -> [" + (trackerCurrentReduceCapacity - trackerRunningReduces) +   
186.                 ", " + (assignedTasks.size()-assignedMaps) + "]");  
187.     }  
188.   
189.     return assignedTasks;  
190.   }  

上面方法中真正执行task的方法为： 
obtainNewNodeOrRackLocalMapTask 和obtainNewNonLocalMapTask 
下一张详细的分析这两个方法 

• 查看图片附件

hadoop 源码分析(六)hadoop taskTracker 生成map 和reduce任务流程

博客分类： 
• hadoop

hadooptaskTrackermapreduce 

taskTracker 生成map reduce 任务详解 

1. 启动 TaskTracker ,执行main方法 new TaskTracker(conf) 启动taskTracker 
2. taskTrack 构造方法初始化变量 
mapred.tasktracker.map.tasks.maximum taskTracker 可launch 的最大map数 默认是2 
mapred.tasktracker.map.tasks.maximum taskTracker 可launch 的最大reduce数 默认是2 
mapred.disk.healthChecker.interval   磁盘健康度检查时间间隔 mills 默认是60*1000 
构造rpc 链接jobTACKER 
tasktracker.http.threads taskTracker 工作线程数,默认是40 ,copy数据的线程数 
initialize(); 构造方法,该方法是一个独立于taskTracker的方法,可循环调用,在taskTracker 处于关闭状态时 仍可用 
该方法主要用户构造一些 运行时目录 和心跳RPC 信息初始化分布式缓存开发map任务监听线程 初始化new TaskLauncher() 启动map 和reduce 任务抓取线程 

Java代码  

1. synchronized void initialize() throws IOException, InterruptedException {  
2.     this.fConf = new JobConf(originalConf);  
3.       
4.      
5.   
6.   
7.     // 绑定地址.taskTracker 的地址 绑定到rpc中 为传送心跳信息做准备  
8.     String address =   
9.       NetUtils.getServerAddress(fConf,  
10.                                 "mapred.task.tracker.report.bindAddress",   
11.                                 "mapred.task.tracker.report.port",   
12.                                 "mapred.task.tracker.report.address");  
13.     InetSocketAddress socAddr = NetUtils.createSocketAddr(address);  
14.     String bindAddress = socAddr.getHostName();  
15.     int tmpPort = socAddr.getPort();  
16.       
17. //初始化jvm 管理类  
18.     this.jvmManager = new JvmManager(this);  
19.   
20.      
21. // RPC 初始化  
22.     int max = maxMapSlots > maxReduceSlots ?   
23.                        maxMapSlots : maxReduceSlots;  
24.     //set the num handlers to max*2 since canCommit may wait for the duration  
25. //of a heartbeat RPC  
26. //此处taskTracker 汇报的 处理任务的slot 在实际的基础上*2,因为在心跳汇报的阶段传输这段时间会空出来一部分slot.在新的heartbeat 过来的时候 有2倍的slot处理能力  
27.     this.taskReportServer = RPC.getServer(this, bindAddress,  
28.         tmpPort, 2 * max, false, this.fConf, this.jobTokenSecretManager);  
29.     this.taskReportServer.start();  
30.   
31.      
32.   
33.     // 初始化分布式缓存,在写mr代码的时候 讲一个文件写入DistributedCache 的时候, DistributedCache 在这个位置进行初始化  
34.     this.distributedCacheManager = new TrackerDistributedCacheManager(  
35.         this.fConf, taskController);  
36.     
37.   
38. // start the thread that will fetch map task completion events  
39. //在该位置启动 map和reduce任务的处理线程  
40.     this.mapEventsFetcher = new MapEventsFetcherThread();  
41.     mapEventsFetcher.setDaemon(true);  
42.     mapEventsFetcher.setName(  
43.                              "Map-events fetcher for all reduce tasks " + "on " +   
44.                              taskTrackerName);  
45.     mapEventsFetcher.start();  
46.   
47.   //这里 初始化了两个类TaskLauncher reduce 和map 这两个类是具体的 生成map和reduce 的任务类.  
48.     mapLauncher = new TaskLauncher(TaskType.MAP, maxMapSlots);  
49.     reduceLauncher = new TaskLauncher(TaskType.REDUCE, maxReduceSlots);  
50.     mapLauncher.start();  
51.     reduceLauncher.start();  

下面详细的讲一下TaskLauncher类,该类为taskTracker 类的内部类，在启动taskTracker 的时候 通过独立的initialize()方法启动. 
该类是一个线程类.通过addToTaskQueue() 方法将新的任务添加到 tasksToLaunch list (List<TaskInProgress> tasksToLaunch)中,这个list 很重要,jobTracker将需要job 通过assginTaks 将需要执行的task 通过心跳信息 传给taskTracker，taskTracker 的run()方法调用offerService()解析心跳信息，将解析得来的task执行信息 添加到这个list中， 然后启动run方法 时刻去查看 tasksToLaunch list中是不是有新的 任务放进来.r如果有则去执行,如果没有则调用tasksToLaunch.wait(); 等待.调用startNewTask 方法调用launchTaskForJob() 通过调用 launchTask 去执行map 和reduce任务, launchTask 要判断任务的状态. UNASSIGNED FAILED_UNCLEAN KILLED_UNCLEAN RUNNING 

TaskTracker 主要是通过监听jobTracker 通过心跳信息传过来的task任务放在 task的队中 去执行task. 

在这个过程中 还会有一些 例如 numFreeSlots 的判断 ,tip 完全是 同步的,等等 
jobTracker 通过调用JobQueueTaskScheduler的assginTasks()方法 分配task,两种方式 生成tak 
obtainNewNodeOrRackLocalMapTask 和obtainNewNonLocalMapTask 
obtainNewNodeOrRackLocalMapTask 即为hadoop 机架感知功能,调度的时候根据location 因素去分配taskTracker 
obtainNewNodeOrRackLocalMapTask 非机架感知 

 

• 查看图片附件

hadoop 性能调优

博客分类： 
• hadoop

Hadoop

hadoop 性能调优

环境：

4台suse 各 4G 内存 1T硬盘 4核cpu
3台 redhat 各 2G内存 500G 硬盘 双核cpu

由于没有真正意义上的服务器,所以当运行大量map reduce任务的时候 map 运行速度还可以接受 但reduce 速度 特别慢,所以开发

 

对集群进行调优。

 

hadoop集群调优分两个方面,map和reduce

 

map调优：

map 任务执行会产生中间数据,但这些中间结果并没有直接IO到磁盘上,而是先存储在缓存(buffer)中,并在缓存中进行一些预排序来优化整个map的性能,该存储map中间数据的缓存默认大小为100M，由io.sort.mb 参数指定.这个大小可以根据需要调整。当map任务产生了非常大的中间数据时可以适当调大该参数,使缓存能容纳更多的map中间数据，而不至于大频率的IO磁盘,当系统性能的瓶颈在磁盘IO的速度上(由于我的是pc 机,因此磁盘读写速度很慢,相信大多数的人都是这样的情况,可以交流),可以适当的调大此参数来减少频繁的IO带来的性能障碍.
由于map任务运行时中间结果首先存储在缓存中,但是不是当整个缓存被填满时才将其写入磁盘,这样会增加map任务的等待,所以默认当 缓存的使用量达到80%(或0.8)的时候就开始写入磁盘,这个过程叫做spill(也叫做磁盘溢出),进行spill的缓存大小可以通过io.sort.spill.percent 参数调整，这个参数可以影响spill的频率.进而可以影响IO的频率.当map任务计算成功完成之后(也可以不成功单个的map)如果map任务有输出.则会产生多个spill。这些文件就是map的输出结果,但

是此时map任务虽然产生了输出结果，但是切记此时map任务仍然没有退出作业,接下来map必须将些spill进行合并,这个过程叫做merge, merge过程是并行处理spill的,每次并行多少个spill是由参数io.sort.factor指定的默认为10个.但是当spill的数量非常大的时候，merge一次并行运行的spill仍然为10个,这样仍然会频繁的IO处理,因此适当的调大每次并行处理的spill数有利于减少merge数因此可以影响map的性能。当map输出中间结果的时候也可以配置压缩，这个在前面的文章中我提到过，这里不再赘述了.

 

reduce调优：

reduce 运行阶段分为shuflle(copy) sort reduce, shuffle 阶段为reduce 全面拷贝map任务成功结束之后产生的中间结果,如果上面map任务用了压缩的方式,那么reduce 将map任务中间结果拷贝过来的时候首先要做的第一件事情就是解压缩,这一切是在reduce的 缓存中做的,当然也会占用一部分cpu,但是应该不会cpu的性能有影响,我的pc 没有发现cpu 因为这个过程被占用的 过多.为了优化reduce的执行时间,reduce也不是等到所有的map数据都拷贝过来的时候才开始运行reduce任务，而是当job执行完第一个map执行完才开始运行的.reduce 在shuffle阶段 实际上是从不同的并且已经完成的map上去下载属于自己的这个reduce,由于map任务数很多,所有这个copy过程是并行的,既同时有许多个reduce取拷贝map.这个并行 的线程是通过mapred.reduce.parallel.copies 参数指定的默认为5个,也就是说无论map的任务数是多少个，默认情况下一次只能有5个reduce的线程去拷贝map任务的执行结果.所以当map任务数很多的情况下可以适当的调整该参数，这样可以让reduce快速的获得运行数据来完成任务。reduce线程在下载map数据的时候也可能因为各种各样的原因,网络原因,系统原因，存储该map数据所在的datannode 发生了故障，这种情况下reduce任务将得不到该

datanode上的数据了,同时该 download thread 会尝试从别的datanode下载,可以通过mapred.reduce.copy.backoff (默认为30秒)来调整下载线程的下载时间，如果网络不好的集群可以通过增加该参数的值来增加下载时间,以免因为下载时间过长reduce将该线程判断为下载失败。
reduce 下载线程在map结果下载到本地时,由于是多线程并行下载，所以也需要对下载回来的数据进行merge,所以map阶段设置的io.sort.factor 也同样会影响这个reduce的。同map也一样，reduce 将从map下载来的数据也立刻写入磁盘,而是当缓冲区被占用到一定的阀值的时候才写入磁盘,reduce的这个大小mapred.job.shuffle.input.buffer.percent（默认为0.7）来指定，同map一样 该缓冲区大小也不是等到完全被占满的时候才写入磁盘而是默认当当完成0.66的时候就开始写磁盘操作,该参数是通过mapred.job.shuffle.merge.percent 指定的。当reduce 开始进行计算的时候通过：mapred.job.reduce.input.buffer.percent 来指定需要多少的内存百分比来作为reduce读已经sort好的数据的buffer百分比,默认为0.当默认时reduce是全部从磁盘开始读处理数

据

总结：总之map reduce调优的一个原则就是 给shuffle 尽量多的内存,给中间结果多些内存，给并行任务数调大(当然一些都得因人而异,根据自己集群及网络的实际情况来调优,调优的时候可以根据工具ganglia来查看效果）