vlambda博客
学习文章列表

                                                                               文/张鸿

说到数据湖，我们一定会想到海量的数据规模和多样的数据类型，这就要求数据湖必须具备强大的数据存储能力。在数据湖的体系架构中，HDFS和对象存储是数据湖最为重要的两种存储引擎。今天我们主要介绍的是HDFS中的一个重要特性——HDFS联邦架构。

HDFS联邦架构（即HDFS Federation），是Hadoop 2.x的新增特性，它是指HDFS集群可同时存在多个Namenode，这些Namenode分别管理一部分数据，且共享所有Datanode的存储资源。HDFS联邦主要解决了Hadoop 1.x中单Namenode的瓶颈问题，通过扩展Namenode数量提升整个集群存储文件的数量和响应外部请求的能力。HDFS联邦架构更适用于像数据湖这种具有大规模Hadoop集群的应用场景。

接下来，让我们对HDFS联邦架构一探究竟。

1. HDFS 1.X的局限性

1.1. Hadoop1.x的HDFS架构

Hadoop1.x的HDFS 采用单Namenode架构，主要由以下两大模块组成：

Namespace由目录、文件和块组成，它支持所有命名空间相关的文件操作，如创建、删除、修改，查看所有文件和目录。

块存储服务包括Block管理和存储两部分。

1) Block管理

2) 存储

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

1.2. 单Namenode架构的局限性

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

由于Namenode在内存中存储所有的元数据（metadata），因此单个Namenode所能存储的对象（文件+块）数目受到Namenode所在JVM的heap size的限制。按照经验估算，1G内存大约可以存储100万个对象。按照单台服务器256G内存来估算，Namenode最多可存储2亿多个对象。

由于Namenode没有隔离性设计，单一对Namenode负载过高的应用，会影响到整个集群的服务能力，HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

由于是单个Namenode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量。随着集群规模增长，Namenode响应的RPC QPS也在逐渐提高。越来越高并发的读写，与Namenode的粗粒度元数据锁，使Namenode RPC响应延迟和平均RPC队列长度都在慢慢提高。

1.3. 纵向扩展Namenode的问题

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

Namenode启动需要将元数据加载到内存中，具有128 GB Java Heap的Namenode启动一次大概需要40分钟到1个小时，那如果配置512GB甚至更大的内存，启动时间不可接受。

Namenode在Full GC时，如果发生错误将容易导致整个集群宕机。

元数据文件fimage过大，NN合并传递消耗更多的资源。

2. HDFS联邦架构介绍

2.1. 在数据湖中的应用场景

HDFS 联邦架构主要用于构建数据湖中的大型Hadoop集群，该集群具有以下特点：

1、文件数量非常多：数据湖中文件数达到数亿甚至更多。

2、单一集群规模大：数据湖的Hadoop集群规模达到数百台甚至更多。

3、各业务场景需要隔离：数据湖多种业务场景共同部署在一个物理集群，各业务之间要求互不影响。

2.2. 联邦架构原理介绍

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

为了水平扩展Namenode，HDFS联邦架构使用了多个独立的Namenode/Namespace。这些Namenode之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。

分布式的Datanode被用作通用的数据块存储设备。每个Datanode要向集群中所有的Namenode注册，且周期性地向所有Namenode发送心跳和块报告，并执行来自所有Namenode的命令。

2.3. 联邦架构的关键技术

HDFS联邦架构中存在多个命名空间，如何划分和管理这些命名空间非常关键。在联邦架构中并未采用“文件名hash”的方法，因为该方法的locality（局部性）非常差，比如：查看某个目录下面的文件，如果采用“文件名hash”的方法存放文件，则这些文件可能被放到不同Namespace中，HDFS需要访问所有Namespace，代价过大。

为了方便管理多个命名空间，HDFS 联邦架构采用了经典的Client Side Mount Table。

如上图所示，下面四个蓝色三角形代表一个独立的命名空间，上方灰色的三角形代表从客户角度去访问的子命名空间。各个蓝色的命名空间Mount到灰色的表中，客户可以访问不同的挂载点来访问不同的命名空间，这就如同在Linux系统中访问不同挂载点一样。

HDFS 联邦架构中命名空间管理的基本原理：将各个命名空间挂载到全局mount-table中，就可以做将数据到全局共享；同样的命名空间挂载到个人的mount-table中，这就成为应用程序可见的命名空间视图。

HDFS 联邦架构引入了块池（Block Pool）的概念。块池管理的原理如下：

HDFS联邦的挂载点配置，本质上就是HDFS虚拟路径与nameservice路径的映射关系，所以可以在默认挂载点配置存在的情况下，业务可以增加自己的映射关系，屏蔽属于不同联邦的目录，来实现业务在目录路径上的无感知切换。

举个例子，数据湖的用户需要用到/dir/dir1、/dir/dir2、/dir/dir3这三个既定业务目录下的文件，放在平台安装的hdfs://ns1和hdfs://ns2两个联邦nameservice中。

可以如下配置:

也就是说，业务想用到什么目录，可以映射到具体的nameservice目录上，然后业务直接用业务自己的目录就可以了。

这个配置是写入到HDFS的配置文件core-site.xml中，并且是客户端参数，不需要HDFS服务重启，只要配置文件修改就立即生效。

2.4. 数据湖引入联邦架构的必要性

数据湖采用HDFS联邦架构的最主要的原因是，联邦架构能够解决数据湖大规模Hadoop集群面临的单Namenode的问题。

1) HDFS集群扩展性。多个Namenode分管一部分目录，使得一个集群可以扩展到更多节点，不再由于内存的限制制约文件存储数目。

2) 性能更高效。多个Namenode管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。

3) 良好的隔离性。用户可根据需要将不同业务数据交由不同Namenode管理，这样不同业务之间影响很小。

2.5. 联邦架构存在的不足

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

HDFS联邦架构并没有完全解决单点故障问题。虽然Namenode/Namespace存在多个，但是从单个Namenode/Namespace看，仍然存在单点故障：如果某个Namenode挂掉了，其管理的相应的文件便不可以访问。

HDFS 联邦架构采用了Client Side Mount Table分摊文件和负载，该方法更多的需要人工介入以达到理想的负载均衡。

HDFS 联邦架构是改造了客户端的解决方案，重度依赖客户端行为，对客户端不透明。当增加了Namenode，并且进行了Namespace拆分后，如果客户端的挂载点不及时更新，有可能导致客户端的访问是合法但不符合预期。

3. 总结

HDFS联邦是Hadoop2.X提供的增强特性，旨在解决数据湖中单Namenode在集群扩展性不足、性能存在瓶颈、业务无法隔离等问题，但是联邦架构目前仍然存在一些不足之处。相信随着Hadoop不断迭代演进，未来HDFS联邦技术也将更加成熟。

SPRING

END