一文理解HDFS( 二 ) _HDFS

因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当namenode出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。
4、小文件问题以及DATANODE水平扩展极限问题Hadoop中每个目录、文件和block都会以对象的形式保存在NameNode的内存中。根据经验每个对象在内存中大概占用150个字节。HDFS中保存2000万个文件，每个文件都在同一个文件夹中，而且每个文件都只有一个block，则NameNode需要6GB内存。
小文件问题：
1、当NameNode重启时，它都需要从本地磁盘读取每个文件的元数据，意味着你要读取300GB数据到内存中，不可避免导致NameNode启动时间较长。
2、一般来说，NameNode会不断跟踪并检查每个数据块的存储位置。这是通过DataNode的定时心跳上报其数据块来实现的。数据节点需要上报的block越多，则也会消耗越多的网络带宽/时延。即使节点之间是高速网络(万兆/光纤)，但不可避免的会带来一些不好的影响。
3、NameNode本身使用300G内存，相当于JVM你需要配置300GB的heap，对于JVM来说本来就存在稳定性的风险，比如GC时间较长。
另外大量小文件意味着大量的随机磁盘IO，磁盘IO通常是MapReduce性能的最大瓶颈之一，在HDFS中对于相同数量的数据，一次大的顺序读取往往优于几次随机读取的性能。
5、HDFS为什么是128M这么大的一个数据块呢？在文件系统中，系统存储文件时，需要定位该数据在磁盘中的位置，再进行传输处理。
定位在磁盘的位置需要时间，同样文件传输也是需要时间的。

T(存储时间)=T(定位时间)+T(传输时间)
如果每个要传输的块设置得足够大，那么从磁盘传输数据的时间可以明显大于定位这个块开始位置的时间。

文章插图

假如文件太小，在namenode 的映射列表就会非常大，影响寻址时间，寻址时间如果大于传输时间，就没有意义了。
但如果block 设置过太大，在MapReduce 任务中，Map或者Reduce任务的个数小于集群机器数量，会使得作业运行效率很低。
6、namenode还存在哪些问题以及怎么解决？存在问题：

单点故障问题
不可以水平扩展（是否可以通过纵向扩展来解决？）
系统整体性能受限于单个名称节点的吞吐量
单个名称节点难以提供不同程序之间的隔离性

解决方案
热备份 (HDFS HA)
HDFS HA（High Availability）是为了解决单点故障问题
HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”
两种名称节点的状态同步，可以借助于一个共享存储系统来实现
一旦活跃名称节点出现故障，就可以立即切换到待命名称节点
Zookeeper确保一个名称节点在对外服务
名称节点维护映射信息，数据节点同时向两个名称节点汇报信息

文章插图

存在的问题就有可能出现脑裂的问题。
Federation多个命名空间。为了处理一个namenode的局限性，搞了几个namanode大家一起来管理。就像编程中的命名空间一样

文章插图

在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容
HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报
属于同一个命名空间的块构成一个“块池
HDFS Federation设计可解决单名称节点存在的以下几个问题：
1. HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目
2. 性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率
3. 良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小
参考文章
https://developer.ibm.com/zh/articles/os-cn-hadoop-name-node/
https://blog.csdn.net/xjz729827161/article/details/79463140