Hadoop之NameNode Federation图文详解

一. 前言

1.NameNode架构的局限性

（1）Namespace（命名空间）的限制

由于NameNode在内存中存储所有的元数据（metadata），因此单个NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储（假设文件平均大小为40MB）。随着数据的飞速增长，存储的需求也随之增长。单个DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。

（2）隔离问题

由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

（3）性能的瓶颈

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。

2.HDFS Federation架构设计，如图所示

能不能有多个NameNode

HDFS Federation架构设计

二.实现

NameNode HA是为了解决NameNode可用性的问题，而NameNode Federation则主要是为了解决NameNode扩展性，隔离性，以及单个NameNode性能方面的问题。NameNode Federation架构如下：

NameNode Federation使用了多个命名空间，这些命名空间互相独立，自制（其实是对元数据的水平切分），而集群中所有DataNode向所有NameNode都进行注册，而一个块池（block pool）有属于同一个命名空间的数据块组成，每个DataNode可能会存储集群中所有块池的数据块，每个块池互相独立，有一个挂掉了也不会影响其他块池正常工作。

同时部署了NameNode HA和NameNode Federation时，集群结构会相对复杂一点，如下图。在实际的生成环境中，NameNode HA几乎是必备，而当集群规模在1000台以下时，几乎是不需要NameNode Federation的。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对脚本之家的支持。如果你想了解更多相关内容请查看下面相关链接

您可能感兴趣的文章:

• Hadoop 2.X新特性回收站功能的讲解
• Hadoop计数器的应用以及数据清洗
• ubantu 16.4下Hadoop完全分布式搭建实战教程
• Hadoop 2.x与3.x 22点比较,Hadoop 3.x比2.x的改进
• ubuntu docker搭建Hadoop集群环境的方法
• 在CentOS中搭建Hadoop的详细步骤
• hadoop的wordcount实例代码
• Java/Web调用Hadoop进行MapReduce示例代码
• Hadoop中namenode和secondarynamenode工作机制讲解