hadoop中HDFS的NameNode原理
程序员文章站
2022-04-09 21:29:07
1. hadoop中HDFS的NameNode原理 1.1. 组成 包括HDFS(分布式文件系统),YARN(分布式资源调度系统),MapReduce(分布式计算系统),等等。 1.2. HDFS架构原理 比如现在要上传一个1T的大文件,提交给HDFS的 (用以存放文件目录树,权限设置,副本数设置等 ......
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♪(・ω・)ノ) - 我特别不懂的地方就是既要保证顺序性,为什么还能用多线程并发?
参考:
用大白话告诉你小白都能看懂的hadoop架构原理
大规模集群下hadoop namenode如何承载每秒上千次的高并发访问