1 文档编写目的

本文主要介绍HDFS Federation（联邦）相关知识，为后续文章《如何为CDH集群启用Federation（联邦）》做一个简单的铺垫。Federation即为“联邦”，该特性允许一个HDFS集群中存在多组Namenode同时对外提供服务，分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的Datanode存储资源。

文章目录结构：

1. 文档编写目的

2. Federation

2.1 单组Namenode架构

2.2 单组Namenode局限性

2.3 为什么要引入Federation

3. Federation介绍

3.1 Federation架构

3.1.1 主要优点

3.1.3 主要缺点

3.2 Federation局限性

4. 总结

2 Federation背景

2.1 单组Namenode架构

HDFS主要有两大模块：

Namespace（命名空间）：由目录、文件和块组成，它支持所有命名空间相关的文件操作，如创建、删除、修改，查看所有文件和目录。
Block Storage Service（块存储服务）：包括Block管理和存储两部分

Block管理

通过控制注册以及阶段性的心跳，来保证Datanode的正常运行；
处理Block的报告信息和维护块的位置信息；
支持Block相关的操作，如创建、删除、修改、获取Block的位置信息；
管理Block的冗余信息、创建副本、删除多余的副本等。

存储

Datanode提供本地文件系统上Block的存储、读写、访问等。

单组Namenode架构

通常情况下，单组Namenode能够满足集群大部分需求，单点故障问题可以通过启用HA解决，单组Namenode包含一主一备两个Namenode，通过Zookeeper保障及控制Failover，而Zookeeper本身具有高可用特性，好像完全不用担心单点故障造成集群不可用的问题，一切看起来似乎非常完美。然而，随着集群规模不断的增长，似乎又不是那么完美了。

2.2 单组Namenode局限性

单组Namenode只允许整个集群有一个活动的Namenode，管理所有的命名空间。随着集群规模的增长，在1000个节点以上的大型Hadoop集群中，单组Namenode的局限性越发的明显，主要表现在以下几个方面：

扩展性：Namenode内存使用和元数据量正相关。180GB堆内存配置下，元数据量红线约为7亿，而随着集群规模和业务的发展，即使经过小文件合并与数据压缩，仍然无法阻止元数据量逐渐接近红线。
可用性：随着元数据量越来越接近7亿，CMS GC频率也越来越高，期间也曾发生过一次在CMS GC过程中由于大文件“get Block location”并发过高导致的promotion fail。
性能：随着集群规模增长，Namenode响应的RPC QPS也在逐渐提高。越来越高并发的读写，与Namenode的粗粒度元数据锁，使Namenode RPC响应延迟和平均RPC队列长度都在慢慢提高。
隔离性：由于Namenode没有隔离性设计，单一对Namenode负载过高的应用，会影响到整个集群的服务能力。

既然单组Namenode存在上述局限性，那么为什么要通过Federation的方式横向拓展Namenode，纵向拓展Namenode为什么不行？不选择纵向拓展Namenode的原因主要体现在以下三个方面：

启动时间长：Namenode启动需要将元数据加载到内存中，具有128 GB Java Heap的Namenode启动一次大概需要40分钟到1个小时，那512GB呢？
调试困难：对大JVM Heap进行调试比较困难，优化Namenode的内存使用性价比比较低。
集群易宕机：Namenode在Full GC时，如果发生错误将会导致整个集群宕机。

2.3 为什么要引入Federation

1.采用Federation的最主要的原因是简单，Federation能够快速的解决大部分单Namenode的问题。

2.Federation是简单鲁棒的设计，由于联邦中各个Namenode之间是相互独立的。Federation整个核心设实现大概用了3.5个月。大部分改变是在Datanode、Config和Tools，而Namenode本身的改动非常少，这样Namenode的原先的鲁棒性不会受到影响。比分布式的Namenode简单，虽然这种事先的扩展性比起真正的分布式的Namenode要小些，但是可以迅速满足需求。

3.Federation良好的向后兼容性，已有的单Namenode的部署配置不需要进行太大的改变就可以继续工作。

3 Federation介绍

3.1 Federation架构

为了水平扩展名称服务，Federation使用多组独立的Namenodes/Namespaces。所有的Namenodes是联邦的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。Datanode被用作通用的数据块存储设备，每个DataNode要向集群中所有的Namenode注册，且周期性的向所有Namenode发送心跳和块报告，并执行来自所有Namenode的命令。

Federation架构与单组Namenode架构相比，主要是Namespace被拆分成了多个独立的部分，分别由独立的Namenode进行管理。

Federation架构

Block Pool（块池）

Block Pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。同时一个Namenode失效不会影响其下Datanode为其他Namenode服务。
每个Block Pool内部自治，也就是说各自管理各自的block，不会与其他Block Pool交流。一个Namenode挂掉了，不会影响其他NameNode。
当DN与NN建立联系并开始会话后自动建立Block Pool。每个block都有一个唯一的标识，这个标识我们称之为扩展块ID,在HDFS集群之间都是惟一的，为以后集群归并创造了条件。
DN中的数据结构都通过块池ID索引，即DN中的BlockMap，storage等都通过BPID索引。
某个NN上的NameSpace和它对应的Block Pool一起被称为NameSpace Volume。它是管理的基本单位。当一个NN/NS被删除后，其所有DN上对应的Block Pool也会被删除。当集群升级时，每个NameSpace Volume作为一个基本单元进行升级。

ClusterID

增加一个新的ClusterID来标识在集群中所有的节点。当一个Namenode

被格式化的时候，这个标识被指定或自动生成，这个ID会用于格式化集群中的其它Namenode。

3.1.1 主要优点

Namespace的可扩展性

HDFS的水平扩展，但是命名空间不能扩展，通过在集群中增加Namenode来扩展Namespace,以达到大规模部署或者解决有很多小文件的情况。

Performance（性能）

在之前的框架中，单个Namenode文件系统的吞吐量是有限制的，增加更多的Namenode能增大文件系统读写操作的吞吐量。

Isolation（隔离）

一个单一的Namenode不能对多用户环境进行隔离，一个实验性的应用程序会加大Namenode的负载，减慢关键的生产应用程序，在多个Namenode情况下，不同类型的程序和用户可以通过不同的Namespace来进行隔离。

3.1.2 主要缺点

交叉访问问题

由于Namespace被拆分成多个，且互相独立，一个文件路径只允许存在一个Namespace中。如果应用程序要访问多个文件路径，那么不可避免的会产生交叉访问Namespace的情况。比如MR、Spark任务，都会存在此类问题。

管理性问题

启用Federation后，HDFS很多管理命令都会失效，比如“hdfs dfsadmin、hdfs fsck”等，除此之外，“hdfs dfs cp/mv”命令同样失效，如果要在不同Namespace间拷贝或移动数据，需要使用distcp命令，指定绝对路径。

3.2 Federation局限性

在解决NameNode扩展能力方面，社区虽然提供了Federation，但这个方案有很强的局限性：

HDFS路径Scheme需要变为ViewFs，ViewFs路径和其他Scheme路径互不兼容，比如DistributedFileSystem无法处理ViewFs为Scheme的路径，也就是说如果启用，则需要将Hive meta、ETL脚本、MR/Spark作业中的所有HDFS路径均的scheme改为viewfs。
如果将fs.defaultFS的配置从hdfs://ns1/变为viewfs://ns/，将导致旧代码异常，通过脚本对用户上万个源码文件的分析，常用的HDFS路径风格多样，包括hdfs:///user、hdfs://ns1/user、/user等，如果fs.defaultFS有所更改，hdfs:///user将会由于缺失nameservice变为非法HDFS路径。
ViewFs路径的挂载方式与Linux有所区别：

如果一个路径声明了挂载，那么其同级目录都需要进行挂载，比如/user/path_one挂载到了hdfs://ns1/user/path_one上，那么/user/path_two也需要在配置中声明其挂载到哪个具体的路径上。
如果一个路径声明了挂载，那么其子路径不能再声明挂载，比如/user/path_one挂载到了hdfs://ns1/user/path_one上，那么其子路径也自动并且必须挂载到hdfs://ns1/user/path_one上。

一次路径请求不能跨多个挂载点：

由于HDFS客户端原有的机制，一个DFSClient只对应一个nameservice，所以一次路径处理不能转为多个nameservice的多次RPC。
对于跨挂载点的读操作，只根据挂载配置返回假结果。
对于跨挂载点的rename（move路径）操作，会抛出异常。

Federation架构中，NameNode相互独立，NameNode元数据、DataNode中块文件都没有进行共享，如果要进行拆分，需要使用DistCp，将数据完整的拷贝一份，存储成本较高；数据先被读出再写入三备份的过程，也导致了拷贝效率的低效。
Federation是改造了客户端的解决方案，重度依赖客户端行为。方案中NameNode相互独立，对Federation没有感知。另外HDFS为Scheme的路径，不受Federation挂载点影响，也就是说如果对路径进行了namespace拆分后，如果因为代码中的路径或客户端配置没有及时更新，导致流程数据写入老数据路径，那么请求依然是合法但不符合预期的。

对其中一些名词的解释：

在HDFS中namespace是指NameNode中负责管理文件系统中的树状目录结构以及文件与数据块的映射关系的一层逻辑结构，在Federation方案中，NameNode之间相互隔离，因此社区也用一个namespace来指代Federation中一组独立的NameNode及其元数据。
Scheme是URI命名结构（[scheme:][//authority][path][?query][#fragment]）中的一部分，用于标识URI所使用的协议，HDFS路径也是一个URI，常见的Scheme为HDFS，在Federation的方案中，HDFS路径Scheme为ViewFs。
挂载点（mount point），它在HDFS Federation中和Linux中的概念近似，指在HDFS客户端上下文中，将ViewFs为Scheme的一个路径，比如viewfs://ns/user，映射到一个具体的HDFS路径上，比如hdfs://ns2/user，这个路径可以是任意Scheme的HDFS路径，这样对于viewfs://ns/user实际上会被转换为对hdfs://ns2/user的操作。