Hadoop源代码分析(三七)

Secondary NameNode的成员变量很少,主要的有:  privateCheckpointStorage checkpointImage;
Secondary NameNode使用的Storage
  privateNamenodeProtocol namenode;
和NameNode通信的接口
  privateHttpServer infoServer;
传输文件用的HTTP服务器
main方法是Secondary NameNode的入口,它最终启动线程,执行SecondaryNameNode的run。启动前的对SecondaryNameNode的构造过程也很简单,主要是创建和NameNode通信的接口和启动HTTP服务器。
SecondaryNameNode的run方法每隔一段时间执行doCheckpoint(),从NameNode的主要工作都在这一个方法里。这个方法,总的来说,会从NameNode上取下FSImage和日志,然后再本地合并,再上传回NameNode。这个过程结束后,从NameNode上保持了NameNode上持久化信息的一个备份,同时,NameNode上已经完成合并到FSImage的日志可以抛弃,一箭双雕。
具体的的流程是:
1:调用startCheckpoint,为接下来的工作准备空间。startCheckpoint会在内部做一系列的检查,然后调用CheckpointStorage的startCheckpoint方法,创建目录。
2:调用namenode的rollEditLog方法,开始一次新的检查点过程。调用会返回一个CheckpointSignature(检查点签名),在上传合并完的FSImage时,会使用这个签名。
Namenode的rollEditLog方法最终调用的是FSImage的同名方法,前面提到过这个方法,作用是关闭往edits上写的日志,打开日志到edits.new。明显,在Secondary NameNode下载fsimage和日志的时候,对命名空间的修改,将保持在edits.new的日志中。
注意,如果FSImage这个时候的状态(看下面的状态机,前面出现过一次)不是出于CheckpointStates.ROLLED_EDITS,将抛异常结束这个过程。
3:通过downloadCheckpointFiles下载fsimage和日志,并设置本地检查点状态为CheckpointStates.UPLOAD_DONE。
4:合并日志的内容到fsimage中。过程很简单,CheckpointStorage利用继承自FSImage的loadFSImage加载fsimage,loadFSEdits应用日志,然后通过saveFSImage保存。很明显,现在保存在硬盘上的fsimage是合并日志的内容以后的文件。
5:使用putFSImage上传合并日志后的fsimage(让NameNode通过HTTP到从NameNode取文件)。这个过程中,NameNode会:
调用NameNode的FSImage.validateCheckpointUpload,检查现在的状态;
利用HTTP,从Secondary NameNode获取新的fsimage;
更新结束后设置新状态。
6:调用NameNode的rollFsImage,最终调用FSImage的rollFsImage方法,前面我们已经分析过了。
7:调用本地endCheckpoint方法,结束一次doCheckpoint流程。
其实前面在分析FSImage的时候,我们在不了解SecondaryNameNode的情况下,分析了很多和Checkpoint相关的方法,现在我们终于可以有一个比较统一的了解了,下面给出NameNode和Secondary NameNode的存储系统在这个流程中的状态转移图,方便大家理解。

图中右侧的状态转移图:

文件系统上的目录的变化(三六中出现):

更多精彩内容请关注:http://bbs.superwu.cn

关注超人学院微信二维码:

时间: 2024-08-24 17:02:32

Hadoop源代码分析(三七)的相关文章

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辅助类 I)

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

Hadoop源代码分析(MapReduce概论)

大家都熟悉文件系统,在对HDFS进行分析前,我们并没有花很多的时间去介绍HDFS的背景,毕竟大家对文件系统的还是有一定的理解的,而且也有很好的文档.在分析Hadoop的MapReduce部分前,我们还是先了解系统是如何工作的,然后再进入我们的分析部分.下面的图来自http://horicky.blogspot.com/2008/11/hadoop-mapreduce-implementation.html,是我看到的讲MapReduce最好的图. 以Hadoop带的wordcount为例子(下面

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.input)

接下来我们按照MapReduce过程中数据流动的顺序,来分解org.apache.hadoop.mapreduce.lib.*的相关内容,并介绍对应的基类的功能.首先是input部分,它实现了MapReduce的数据输入部分.类图如下: 类图的右上角是InputFormat,它描述了一个MapReduceJob的输入,通过InputFormat,Hadoop可以: l          检查MapReduce输入数据的正确性: l          将输入数据切分为逻辑块InputSplit,这

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

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

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源代码分析(IFile)

Mapper的输出,在发送到Reducer前是存放在本地文件系统的,IFile提供了对Mapper输出的管理.我们已经知道,Mapper的输出是<Key,Value>对,IFile以记录<key-len, value-len, key,value>的形式存放了这些数据.为了保存键值对的边界,很自然IFile需要保存key-len和value-len.和IFile相关的类图如下: 其中,文件流形式的输入和输出是由IFIleInputStream和IFIleOutputStream抽象