Hadoop Federation联邦机制

比眉伴天荒 2022-05-28 02:08 262阅读 0赞

## Hadoop1.0 单namenode架构局限性 ##

1.  NameSpace（命名空间的限制）  
    由于Namenode在内存中存储所有的元数据（metadata）。NN在管理大规模的命名空间时，单个Namenode所能存储的对象（文件+块）数目受到Namenode所在JVM的堆【内存大小的限制】。  
    随着数据的飞速增长，存储的需求也随之增长。50G的heap能够存储20亿个对象—>4000个datanode—>12PB的存储（假设文件平均大小为40MB）。单个datanode从4T增长到36T，集群的尺寸增长到8000个datanode。存储的需求从12PB增长到大于100PB。
2.  性能的瓶颈  
    由于是单个Namenode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。这将成为下一代MapReduce的瓶颈。
3.  隔离问题  
    由于仅有一个Namenode，无法隔离各个程序，因此HDFS上的一个实验程序很可能影响整个HDFS上运行的程序。 NN在内部用一把全局锁撸遍所有的元数据操作来保证数据的一致性
4.  集群的可用性  
    在只有一个Namenode的HDFS中，此Namenode的宕机无疑会导致整个集群的不可用。（低可用性）
5.  Namespace和Block Management(管理)的紧密耦合  
    Hadoop 1.x在Namenode中的Namespace和Block Management组合的紧密耦合关系会导致如果想要实现另外一套。Namenode方案比较困难，而且也限制了其他想要直接使用块存储的应用。

为什么纵向扩展目前的NameNode不可行？比如将NameNode的Heap堆空间扩大到512GB。

1.启动时间太长。（Hadoop 1.x具有50GB Heap Namenode的HDFS启动一次大概需要30分钟到2小时） 
    2.Namenode在Full GC时，如果发生错误将会导致整个集群宕机。 
    3.对大JVM Heap进行调试比较困难。优化Namenode的内存使用性价比比较低。

## Federation联邦机制 ##

在Hadoop2.0之前，HDFS的单NameNode设计带来诸多问题：  
单点故障、内存受限，制约集群扩展性和缺乏隔离机制（不同业务使用同一个NameNode导致业务相互影响）等  
为了解决这些问题，除了用基于共享存储的HA解决方案我们还可以用HDFS的Federation机制来解决这个问题。  
【单机namenode的瓶颈大约是在4000台集群，而后则需要使用联邦机制】

1.  什么是Federation机制  
    Federation是指HDFS集群可使用多个独立的NameSpace(NameNode节点管理)来满足HDFS命名空间的水平扩展  
    这些NameNode分别管理一部分数据，且共享所有DataNode的存储资源。
    
    NameSpace之间在逻辑上是完全相互独立的(即任意两个NameSpace可以有完全相同的文件名)。在物理上可以完全独立(每个NameNode节点管理不同的DataNode)也可以有联系(共享存储节点DataNode)。一个NameNode节点只能管理一个Namespace
2.  Federation机制解决单NameNode存在的以下几个问题  
    （1）HDFS集群扩展性。每个NameNode分管一部分namespace，相当于namenode是一个分布式的。  
    （2）性能更高效。多个NameNode同时对外提供服务，提供更高的读写吞吐率。  
    （3）良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理，这样不同业务之间影响很小。  
    （4）Federation良好的向后兼容性，已有的单Namenode的部署配置不需要任何改变就可以继续工作。
3.  Federation是简单鲁棒的设计  
    鲁棒性（健壮和强壮）：在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃
    
    由于联盟中各个Namenode之间是相互独立的：Federation整个核心设计大部分改变是在Datanode、Config和Tools，而Namenode本身的改动非常少，这样Namenode原先的鲁棒性不会受到影响。比分布式的Namenode简单，虽然扩展性比真正的分布式的Namenode要小些，但是可以迅速满足需求。
    
    另外一个原因是Federation良好的向后兼容性，可以无缝的支持目前单Namenode架构中的配置。已有的单Namenode的部署配置不需要任何改变就可以继续工作。
4.  Federation不足之处  
    HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障。因此 Federation中每个namenode配置成HA高可用集群，以便主namenode挂掉一下，用于快速恢复服务。

**Federation 架构**

![这里写图片描述][70]

1.  为了水平扩展namenode，federation使用了多个独立的namenode/namespace  
    这些namenode之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的datanode被用作通用的数据块存储存储设备。每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。
2.  每个namenode维护一个命名空间卷（namespace volume）  
    由命名空间的元数据和一个数据块池组成，数据块池（block pool）包含该命名空间下文件的所有数据块。
3.  命名空间卷之间相互独立  
    两两之间并不互相通信，甚至其中一个namenode的失效也不会影响由其他namenode维护的命名空间的可用性。
4.  一个namespace和它的blockpool作为一个管理单元（称为namespace volume）  
    数据块池不再切分，则集群中的DataNode需要注册到每个namenode，并且存储着来自多个数据块池中的数据块。当namenode/namespace被删除后，其所有datanode上对应的block pool也会被删除。集群升级时，这个管理单元也独立升级。

**Block Pool(块池)**

Block pool就是属于单个命名空间的一组block。每一个datanode为所有的block pool存储块。
    Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念。
    Block pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。
    
    当datanode与Namenode建立联系并开始会话后自动建立Block pool。
    每个block都有一个唯一的标识，这个标识我们称之为扩展的块ID（Extended BlockID=BlockID+BlockID）
    这个扩展的块ID在HDFS集群之间都是唯一的，这为以后集群归并创造了条件。
    Datanode中的数据结构都通过BlockPoolID索引，即datanode中的BlockMap，storage等都通过BPID索引。
    在HDFS中，所有的更新、回滚都是以Namenode和BlockPool为单元发生的。
    即同一HDFS Federation中不同的Namenode/BlockPool之间没有什么关系。
    Hadoop1.x版本中Block Pool的管理功能放在Namenode中，以后Block Pool的管理功能移动的新的功能节点中。

**Namespace Volume(命名空间卷)**

一个Namespace和它的块池合并在一起称为Namespace Volume，它是一个独立完整的管理单元。
    当一个Namenode/Namespace被删除，与之相对应的块池也被删除。
    在升级时，每一个nanespace Volume也会整体作为一个单元。

**ClusterId(节点标识)**

在HDFS Federation中添加了ClusterID用来标示集群所有节点
    当格式化一个Namenode时，这个Cluster Id会自动生成或者手动提供。
    在格式化统一集群中其他Namenode时会用到这个ClusterID。

## HA+Federation ##

参看博客：[http://blog.csdn.net/xhh198781/article/details/44727335][http_blog.csdn.net_xhh198781_article_details_44727335]

![这里写图片描述][70 1]

[70]: /images/20220528/a595df7f84ba419c9d0cf1eda8c81e22.png
[http_blog.csdn.net_xhh198781_article_details_44727335]: http://blog.csdn.net/xhh198781/article/details/44727335
[70 1]: /images/20220528/9a0c170bae08465c9952953800ace2ad.png