SecondNamenode
来源:互联网 发布:xp网络被劫持 编辑:程序博客网 时间:2024/05/18 00:25
什么是Namenode
相当于一个领导者,负责调度 比如你需要存一个640m的文件 如果按照64m分块 那么namenode就会把这10个块(这里不考虑副本)分配到集群中的datanode上 并记录对于关系 。当你要下载这个文件的时候namenode就知道在那些节点上给你取这些数据了,它主要维护两个map: 一个是文件到块的对应关系 一个是块到节点的对应关系。
什么是SecondNamenode
SecondNamenode是对主Namenode的一个补充,它会周期的执行对HDFS元数据的检查点。 当前的设计仅仅允许每个HDFS只有单个SecondNamenode结点。
SecondNamenode是有一个后台的进程,会定期的被唤醒(唤醒的周期依赖相关配置)执行检查点任务,然后继续休眠。 它使用ClientProtocol协议与主Namenode通信。
SecondNamenode最好与Namenode部署到不同的服务器( 应该在merge的过程中,SecondNamenode对内存的需求与Namenode是相同的,所以对于那些大型的生产系统 中,如果将两者部署到同台服务器 上,在 内存上会出现 瓶颈。)
他只是Namenode的一个小助手(helper),可以防止edits过大,进而导致下次Namenode启动加载过慢。
1,检查点到底是做什么用的呢?
先抛开SecondNamenode不说,先介绍下Namenode中与检查点相关的两个文件,以及他们之间的关系。fsimage文件与edits文件是Namenode结点上的核心文件。
Namenode中仅仅存储目录树信息,而关于BLOCK的位置信息则是从各个Datanode上传到Namenode上的。
Namenode的目录树信息就是物理的存储在fsimage这个文件中的,当Namenode启动的时候会首先读取fsimage这个文件,将目录树信息装载到内存中。
而edits存储的是日志信息,在Namenode启动后所有对目录结构的增加,删除,修改等操作都会记录到edits文件中,并不会同步的记录在fsimage中。
而当Namenode结点关闭的时候,也不会将fsimage与edits文件进行合并,这个合并的过程实际上是发生在Namenode启动的过程中。
也就是说,当Namenode启动的时候,首先装载fsimage文件,然后在应用edits文件,最后还会将最新的目录树信息更新到新的fsimage文件中,然后启用新的edits文件。
整个流程是没有问题的,但是有个小瑕疵,就是如果Namenode在启动后发生的改变过多,会导致edits文件变得非常大,大得程度与Namenode的更新频率有关系。
那么在下一次Namenode启动的过程中,读取了fsimage文件后,会应用这个无比大的edits文件,导致启动时间变长,并且不可能控,可能需要启动几个小时也说不定。
Namenode的edits文件过大的问题,也就是SecondeNamenode要解决的主要问题。
SecondNamenode会按照一定规则被唤醒,然后进行fsimage文件与edits文件的合并,防止edits文件过大,导致Namenode启动时间过长。
2,检查点被唤醒的条件?
控制检查点的参数有两个,分别是(时间或者空间的超出):
**时间:**fs.checkpoint.period:单位秒,默认值3600,检查点的间隔时间,当距离上次检查点执行超过该时间后启动检查点。
**空间:**fs.checkpoint.size:单位字节,默认值67108864,当edits文件超过该大小后,启动检查点。
上面两个条件是或的关系,只要满足启动一个条件,检查点即被唤醒。
3,检查点执行的过程?
a,初始化检查点
b,通知Namenode启用新的edits文件
c,从Namenode下载fsimage和edits文件
d,调用loadFSImage装载fsimage
e,调用loadFSEdits应用edits日志
f,保存合并后的目录树信息到新的image文件中
g,将新产生的image上传到Namenode中,替换原来的image文件
h,结束检查点
4,SecondNamenode最好于Namenode部署到不同的服务器
应该在merge的过程中,SecondNamenode对内存的需求与Namenode是相同的,所以对于那些大型的生产系统中,如果将两者部署到同台服务器上,在内存上会出现瓶颈。所以最好将他们分别部署到不同的服务器,修改hadoop配置文件的master文件。
5,关于SecondNamenode的思考
其实检查点的执行过程最好在Namenode结点搞定,也就说能有个任务定期的将Namenode的内存结果刷新到fsimage中,而不是仅仅在Namenode启动的时候才进行一次合并。
如果可以实现定期的对Namenode执行检查点,那么SecondNamenode完全没有存在的必要了。
或者在SecondNamenode方面实现增量的刷新,每次不需要将fsimage整个装载到内存中,而仅仅将增量刷新就OK了。
不过这样会让系统变得复杂一些,可以参考Oracle中的检查点的处理,还是有些复杂的。简单就是美?!!
参考
Hadoop详解
- SecondNamenode
- secondnamenode详解
- hadoop SecondNamenode
- hadoop SecondNamenode
- hadoop SecondNamenode详解
- secondNamenode chkpiont的理解
- hadoop SecondNamenode详解
- hadoop SecondNamenode详解
- hadoop HDFS SecondNamenode详解
- SecondNamenode详解与设置
- hadoop SecondNamenode详解
- hadoop SecondNamenode详解
- hadoop SecondNamenode详解
- Hadoop--NameNode && SecondNameNode
- hadoop SecondNamenode详解
- hadoop SecondNamenode详解
- Hadoop--SecondNameNode导致服务启动时间超长
- hadoop的namenode和secondnamenode分开部署在不同服务器
- Dubbo分布式服务框架入门(附工程)
- 【SQL Server学习笔记】8:T-SQL部分基本语法
- 除了443、14000端口,还有哪些端口是https的?
- Spring4 Quartz2 动态任务,Spring4整合quartz2.2.3简单动态任务
- 用shell脚本运行Java程序
- SecondNamenode
- python中os和sys模块的使用
- 初学者实践日志3
- Angular学习视频资料
- 斐波那契数列Fibonacci
- [初学笔记] matlab中 struct的用法,以及如何保存在xls中
- LeetCode 189. Rotate Array
- Android开发板串口(SerialPort)通信
- 《深度学习Ng》课程学习笔记01week3——浅层神经网络