标签：博客   文件   元数据   架构   创建   命令   服务   cti   默认   

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如何承载每秒上千次的高并发访问

hadoop中HDFS的NameNode原理

标签：博客   文件   元数据   架构   创建   命令   服务   cti   默认   

原文地址：https://www.cnblogs.com/sky-chen/p/11346879.html