【转】Hadoop 1.x中fsimage和edits合并实现

  在NameNode运行期间,HDFS的所有更新操作都是直接写到edits中,久而久之edits文件将会变得很大;虽然这对NameNode运行时候是没有什么影响的,但是我们知道当NameNode重启的时候,NameNode先将fsimage里面的所有内容映像到内存中,然后再一条一条地执行edits中的记录,当edits文件非常大的时候,会导致NameNode启动操作非常地慢,而在这段时间内HDFS系统处于安全模式,这显然不是用户要求的。能不能在NameNode运行的时候使得edits文件变小一些呢?其实是可以的,本文主要是针对Hadoop 1.x版本,说明其是怎么将edits和fsimage文件合并的,Hadoop 2.x版本edits和fsimage文件合并是不同的。
  用过Hadoop的用户应该都知道在Hadoop里面有个SecondaryNamenode进程,从名字看来大家很容易将它当作NameNode的热备进程。其实真实的情况不是这样的。SecondaryNamenode是HDFS架构中的一个组成部分,它是用来保存namenode中对HDFS metadata的信息的备份,并减少namenode重启的时间而设定的!一般都是将SecondaryNamenode单独运行在一台机器上,那么SecondaryNamenode是如何namenode重启的时间的呢?来看看SecondaryNamenode的工作情况:
  (1)SecondaryNamenode会定期的和NameNode通信,请求其停止使用edits文件,暂时将新的写操作写到一个新的文件edit.new上来,这个操作是瞬间完成,上层写日志的函数完全感觉不到差别;
  (2)SecondaryNamenode通过HTTP GET方式从NameNode上获取到fsimage和edits文件,并下载到本地的相应目录下;
  (3)SecondaryNamenode将下载下来的fsimage载入到内存,然后一条一条地执行edits文件中的各项更新操作,使得内存中的fsimage保存最新;这个过程就是edits和fsimage文件合并;
  (4)SecondaryNamenode执行完(3)操作之后,会通过post方式将新的fsimage文件发送到NameNode节点上
  (5)NameNode将从SecondaryNamenode接收到的新的fsimage替换旧的fsimage文件,同时将edit.new替换edits文件,通过这个过程edits就变小了!整个过程的执行可以通过下面的图说明:
  在(1)步骤中,我们谈到SecondaryNamenode会定期的和NameNode通信,这个是需要配置的,可以通过core-site.xml进行配置,下面是默认的配置:

1 <property>
2   <name>fs.checkpoint.period</name>
3   <value>3600</value>
4   <description>The number of seconds between two periodic checkpoints.
5   </description>
6 </property>

  其实如果当fs.checkpoint.period配置的时间还没有到期,我们也可以通过判断当前的edits大小来触发一次合并的操作,可以通过下面配置

1 <property>
2   <name>fs.checkpoint.size</name>
3   <value>67108864</value>
4   <description>The size of the current edit log (in bytes) that triggers
5        a periodic checkpoint even if the fs.checkpoint.period hasn‘t expired.
6   </description>
7 </property>

  当edits文件大小超过以上配置,即使fs.checkpoint.period还没到,也会进行一次合并。顺便说说SecondaryNamenode下载下来的fsimage和edits暂时存放的路径可以通过下面的属性进行配置:

 1 <property>
 2   <name>fs.checkpoint.dir</name>
 3   <value>${hadoop.tmp.dir}/dfs/namesecondary</value>
 4   <description>Determines where on the local filesystem the DFS secondary
 5       name node should store the temporary images to merge.
 6       If this is a comma-delimited list of directories then the image is
 7       replicated in all of the directories for redundancy.
 8   </description>
 9 </property>
10
11 <property>
12   <name>fs.checkpoint.edits.dir</name>
13   <value>${fs.checkpoint.dir}</value>
14   <description>Determines where on the local filesystem the DFS secondary
15       name node should store the temporary edits to merge.
16       If this is a comma-delimited list of directoires then teh edits is
17       replicated in all of the directoires for redundancy.
18       Default value is same as fs.checkpoint.dir
19   </description>
20 </property>

  从上面的描述我们可以看出,SecondaryNamenode根本就不是Namenode的一个热备,其只是将fsimage和edits合并。其拥有的fsimage不是最新的,因为在他从NameNode下载fsimage和edits文件时候,新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的!当然,如果NameNode中的fsimage真的出问题了,还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage,虽然已经不是最新的fsimage,但是我们可以将损失减小到最少!
  在Hadoop 2.x通过配置JournalNode来实现Hadoop的高可用性,这样主被NameNode上的fsimage和edits都是最新的,任何时候只要有一台NameNode挂了,也可以使得集群中的fsimage是最新状态!

转载自:http://www.iteblog.com/archives/969

时间: 2024-10-06 03:40:49

【转】Hadoop 1.x中fsimage和edits合并实现的相关文章

hadoop中fsimage和edits的区别

1.概念: fsimage保存了最新的元数据检查点. edits保存自最新检查点后的命名空间的变化. 2.工作原理: 从最新检查点后,hadoop将对每个文件的操作都保存在edits中,为避免edits不断增大,secondary namenode就会周期性合并fsimage和edits成新的fsimage,edits再记录新的变化. 这种机制有个问题:因edits存放在Namenode中,当Namenode挂掉,edits也会丢失,导致利用secondary namenode恢复Namenod

Hadoop集群管理 fsimage和edits工作机制内幕

一. fsiamges文件通常是整个集群的元数据信息.每次对它的修改很好内存,io. 所以引入了edits 文件.存放每次对元数据修改的记录,并通过Secondary Namenode定期的合并. 二.过程 1.Secondary Namenode请求edits和fsimage合并. 2.Namenode停止对edits文件的修改,并生成edits.new文件,存储在合并期间出现的对元数据的修改 3.Secondary Namenode通过http get方式获取edits文件和fsimages

第124讲:Hadoop集群管理之fsimage和edits工作机制内幕详解学习笔记

客户端对hdfs进行写文件时会首先被记录在edits文件中. edits修改时元数据也会更新. 每次hdfs更新时edits先更新后客户端才会看到最新信息. fsimage:是namenode中关于元数据的镜像,一般称为检查点. 一般开始时对namenode的操作都放在edits中,为什么不放在fsimage中呢? 因为fsimage是namenode的完整的镜像,内容很大,如果每次都加载到内存的话生成树状拓扑结构,这是非常耗内存和CPU. 内容包含了namenode管理下的所有datanode

Hadoop 2.0中单点故障解决方案总结

项目构建 Hadoop 1.0内核主要由两个分支组成:MapReduce和HDFS,众所周知,这两个系统的设计缺陷是单点故障,即MR的JobTracker和HDFS的NameNode两个核心服务均存在单点问题,该问题在很长时间内没有解决,这使得Hadoop在相当长时间内仅适合离线存储和离线计算. 令人欣慰的是,这些问题在Hadoop 2.0中得到了非常完整的解决.Hadoop 2.0内核由三个分支组成,分别是HDFS.MapReduce和YARN,而Hadoop生态系统中的其他系统,比如HBas

Hadoop-2.4.1学习之创建fsimage和edits源码分析

在Hadoop中fsimage保存最新的检查点信息,edits保存自最新检查点后的命名空间的变化.在分析hdfs namenode–format的源代码时,已经明确了该过程根据配置文件的信息创建fsimage和edits文件,这篇文章具体分析一下创建fsimage和edits文件的源代码.在NameNode的format方法中,有如下的代码: FSImage fsImage = new FSImage(conf, nameDirsToFormat, editDirsToFormat); try

Hive数据导入——数据存储在Hadoop分布式文件系统中,往Hive表里面导入数据只是简单的将数据移动到表所在的目录中!

转自:http://blog.csdn.net/lifuxiangcaohui/article/details/40588929 Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中.Hive本身是没有专门的数据存储格式,也没有为数据建立索引,只需要在创建表的时候告诉Hive数据中的列分隔符和行分隔符,Hive就可以解析数据.所以往Hive表里面导入数据只是简单的将数据移动到表所在的目录中! Hive的几种常见的数据导入方式这里介绍四种:(1).从本地文件系统中

去除hadoop启动过程中的警告信息

安装完hadoop后启动hadoop 会报一个Warning.解决办法 vi  /etc/profile 进入编辑模式,添加下面这行 export HADOOP_HOME_WARN_SUPPRESS=1 保存退出 立即生效:source /etc/profile 重新启动hadoop 消除警告成功! 去除hadoop启动过程中的警告信息,布布扣,bubuko.com

Hadoop在eclipse中的配置

在安装完linux下的hadoop框架,实现完所现有的wordCount程序,能够完美输出结果之后,我们开始来搭建在window下的eclipse的环境,进行相关程序的编写. 在网上有很多未编译版本,需要手动进行相关编辑,所以特地找了一个已经编译完好的插件 eclipse版本:SR2-kepler java版本:1.8.101 Hadoop 版本:hadoop2.5.2.tar.gz 需要hadoop的插件:eclipse-hadoop-2.5.2-plugin        http://pa

hadoop 关于java中的public static 变量是不能被改变的?

我在写hadoop的时候,在mapper里定义了一个public static int rownums = 0.但我在main里对这个变量进行了赋值. 结果在循环的过程中,根本没有任何输出,因为我是用这个变量来控制循环的,所以我猜想可能是不能改变这个值,于是我直接在初始定义的时候直接赋上正确的值,所以这样最后程序就正确运行了. 但是我又新建了一个工程写了一个小程序,试了一下,明明是能够改变,正确输出的. 不能理解了. hadoop 关于java中的public static 变量是不能被改变的?