Hadoop源代码分析(Task的内部类和辅助类)

从前面的图中,我们可以发现Task有很多内部类,并拥有大量类成员变量,这些类配合Task完成相关的工作,如下图。

MapOutputFile管理着Mapper的输出文件,它提供了一系列get方法,用于获取Mapper需要的各种文件,这些文件都存放在一个目录下面。
我们假设传入MapOutputFile的JobID为job_200707121733_0003,TaskID为task_200707121733_0003_m_000005。MapOutputFile的根为
{mapred.local.dir}/taskTracker/jobcache/{jobid}/{taskid}/output
在下面的讨论中,我们把上面的路径记为{MapOutputFileRoot}
以上面JogID和TaskID为例,我们有:
{mapred.local.dir}/taskTracker/jobcache/job_200707121733_0003/task_200707121733_0003_m_000005/output
需要注意的是,{mapred.local.dir}可以包含一系列的路径,那么,Hadoop会在这些根路径下找一个满足要求的目录,建立所需的文件。MapOutputFile的方法有两种,结尾带ForWrite和不带ForWrite,带ForWrite用于创建文件,它需要一个文件大小作为参数,用于检查磁盘空间。不带ForWrite用于获取以建立的文件。
getOutputFile:文件名为{MapOutputFileRoot}/file.out;
getOutputIndexFile:文件名为{MapOutputFileRoot}/file.out.index
getSpillFile:文件名为{MapOutputFileRoot}/spill{spillNumber}.out
getSpillIndexFile:文件名为{MapOutputFileRoot}/spill{spillNumber}.out.index
以上四个方法用于Task子类MapTask中;
getInputFile:文件名为{MapOutputFileRoot}/map_{mapId}.out
用于ReduceTask中。我们到使用到他们的地方再介绍相应的应用场景。

介绍完临时文件管理以后,我们来看Task.CombineOutputCollector,它继承自org.apache.hadoop.mapred.OutputCollector,很简单,只是一个OutputCollector到IFile.Writer的Adapter,活都让IFile.Writer干了。

ValuesIterator用于从RawKeyValueIterator(Key,Value都是DataInputBuffer,ValuesIterator要求该输入已经排序)中获取符合RawComparator<KEY>comparator的值的迭代器。它在Task中有一个简单子类,CombineValuesIterator。

Task.TaskReporter用于向JobTracker提交计数器报告和状态报告,它实现了计数器报告Reporter和状态报告StatusReporter。为了不影响主线程的工作,TaskReporter有一个独立的线程,该线程通过TaskUmbilicalProtocol接口,利用Hadoop的RPC机制,向JobTracker报告Task执行情况。

FileSystemStatisticUpdater用于记录对文件系统的对/写操作字节数,是个简单的工具类。

扫一扫超人学院微信二维码:

时间: 2024-11-08 06:27:02

Hadoop源代码分析(Task的内部类和辅助类)的相关文章

Hadoop源代码分析(MapTask辅助类 I)

Hadoop源代码分析(MapTask辅助类 I)MapTask的辅劣类主要针对Mapper的输入和输出.首先我们来看MapTask中用的的Mapper输入,在类图中,返部分位于右上角.MapTask.TrackedRecordReader是一个Wrapper,在原有输入RecordReader的基础上,添加了收集上报统计数据的功能.MapTask.SkippingRecordReader也是一个Wrapper,它在MapTask.TrackedRecordReader的基础上,添加了忽略部分输

Hadoop源代码分析

关键字: 分布式云计算 Google的核心竞争技术是它的计算平台.Google的大牛们用了下面5篇文章,介绍了它们的计算设施. GoogleCluster:http://research.google.com/archive/googlecluster.html Chubby:http://labs.google.com/papers/chubby.html GFS:http://labs.google.com/papers/gfs.html BigTable:http://labs.googl

Hadoop源代码分析(完整版)-转载

Hadoop源代码分析(一) http://blog.csdn.net/huoyunshen88/article/details/8611629 关键字: 分布式云计算 Google的核心竞争技术是它的计算平台.Google的大牛们用了下面5篇文章,介绍了它们的计算设施. GoogleCluster:http://research.google.com/archive/googlecluster.html Chubby:http://labs.google.com/papers/chubby.h

Hadoop源代码分析(MapTask)

接下来我们来分析Task的两个子类,MapTask和ReduceTask.MapTask的相关类图如下: MapTask其实不是很复杂,复杂的是支持MapTask工作的一些辅助类.MapTask的成员变量少,只有split和splitClass.我们知道,Map的输入是split,是原始数据的一个切分,这个切分由org.apache.hadoop.mapred.InputSplit的子类具体描述(前面我们是通过org.apache.hadoop.mapreduce.InputSplit介绍了In

Hadoop源代码分析(MapTask辅助类,III)

接下来讨论的是key,value的输出,这部分比较复杂,不过有了前面kvstart,kvend和kvindex配合的分析,有利于我们理解返部分的代码. 输出缓冲区中,和kvstart,kvend和kvindex对应的是bufstart,bufend和bufmark.这部分还涉及到变量bufvoid,用与表明实际使用的缓冲区结尾(见后面BlockingBuffer.reset分析),和变量bufmark,用于标记记录的结尾.返部分代码需要bufmark,是因为key戒value的输出是变长的,(前

Hadoop源代码分析(MapTask辅助类,II)

有了上面Mapper输出的内存存储结构和硬盘存储结构讨论,我们来仔细分析MapOutputBuffer的流程.首先是成员变量.最先初始化的是作业配置job和统计功能reporter.通过配置,MapOutputBuffer可以获取本地文件系统(localFs和rfs),Reducer的数目和Partitioner. SpillRecord是文件spill.out{spill号}.index在内存中的对应抽象(内存数据和文件数据就差最后的校验和),该文件保持了一系列的IndexRecord,如下图

Hadoop源代码分析(*IDs类和*Context类)

我们开始来分析Hadoop MapReduce的内部的运行机制.用户向Hadoop提交Job(作业),作业在JobTracker对象的控制下执行.Job被分解成为Task(任务),分发到集群中,在TaskTracker的控制下运行.Task包括MapTask和ReduceTask,是MapReduce的Map操作和Reduce操作执行的地方.这中任务分布的方法比较类似于HDFS中NameNode和DataNode的分工,NameNode对应的是JobTracker,DataNode对应的是Tas

Hadoop源代码分析(包hadoop.mapred中的MapReduce接口)

前面已经完成了对org.apache.hadoop.mapreduce的分析,这个包提供了Hadoop MapReduce部分的应用API,用于用户实现自己的MapReduce应用.但这些接口是给未来的MapReduce应用的,目前MapReduce框架还是使用老系统(参考补丁HADOOP-1230).下面我们来分析org.apache.hadoop.mapred,首先还是从mapred的MapReduce框架开始分析,下面的类图(灰色部分为标记为@Deprecated的类/接口): 我们把包m

Hadoop源代码分析(mapreduce.lib.partition/reduce/output)

Map的结果,会通过partition分发到Reducer上,Reducer做完Reduce操作后,通过OutputFormat,进行输出,下面我们就来分析参与这个过程的类. Mapper的结果,可能送到可能的Combiner做合并,Combiner在系统中并没有自己的基类,而是用Reducer作为Combiner的基类,他们对外的功能是一样的,只是使用的位置和使用时的上下文不太一样而已.Mapper最终处理的结果对<key, value>,是需要送到Reducer去合并的,合并的时候,有相同