Hadoop3多namenode支持 hadoop namenode
转载
1. hadoop中HDFS的NameNode原理
1.1. 组成
- 包括HDFS(分布式文件系统),YARN(分布式资源调度系统),MapReduce(分布式计算系统),等等。
1.2. HDFS架构原理
- 比如现在要上传一个1T的大文件,提交给HDFS的
Active NameNode
(用以存放文件目录树,权限设置,副本数设置等),它会在指定目录下创建一个新的文件对象,比如access_20180101.log
- 至于具体数据,它会将它拆分后进行分布式存储,分散在各个DataNode节点,且默认都会有3个副本,防止其中一台机器宕机使得数据缺失
- 这里图之所以这么复杂,原因在于大量的请求提交给
Active NameNode
会不断修改元数据,而元数据是在内存的,为了防止宕机丢失,必须把它存在磁盘,但是频繁的修改磁盘数据,性能是很低的,这是大量的磁盘随机读写,所以有了上述图的方案 - 每次操作请求
Active NameNode
会写一条edits log
放到磁盘文件,不是直接修改磁盘文件内容,而是顺序追加,这个性能就高多了 - 同时它会把
edits log
还会写入JournalNodes
集群,通过JournalNodes
会把操作日志传到Standby NameNode
,这就相当于是个备份服务,确保了Standby NameNode
内存中的元数据和Active NameNode
是一样的,而Standby NameNode
每隔一段时间会把内存里的元数据写一份到磁盘的fsimage
文件,这个文件就是全量的元数据了,不是日志记录 - 再然后会把这个fsimage上传到
Active NameNode
,替换掉内存中的元数据,再清空掉Active NameNode
所在磁盘上的edits log
,重新开始记录日志 - 为什么要这么做?因为为了防止
Active NameNode
突然宕机后,我们需要进行恢复,它的恢复是基于磁盘上的edits log
的,和redis的aof相同的道理,它需要重新运行一遍日志中的所有命令,当时间长了后日志可能会很大,重启时间也就会很长; - 引入
Standby NameNode
的备份机制,就可以在节点重启时,直接从Standby NameNode
的fsimage
读取元数据备份,这就相当于redis的rdb恢复,速度是比较快的,读取完备份再从磁盘的edits log
读取少量的操作日志执行恢复,就完全恢复到宕机前的状态了
1.3. NameNode如何承载每秒上千次的高并发访问
- 分段加锁机制+内存双缓冲机制(老实说我是没看懂,他的博客我也留言问了两个问题,有能看懂了拜托这里留言或在他博客
过眼云烟本尊
这个评论者下留言,Thanks♪(・ω・)ノ) - 我特别不懂的地方就是既要保证顺序性,为什么还能用多线程并发?
本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。