HDFS教程（04）- HDFS联邦

01 引言

在前面的教程，我们知道了HDFS的高可用和容错机制了，有兴趣的同学可以参阅：

• 《HDFS教程（01）- 初识HDFS》
• 《HDFS教程（02）- HDFS命令汇总》
• 《HDFS教程（03）- HDFS高可用与容错》

本文接下来主要讲的是HDFS联邦。

02 HDFS联邦 2.1 HDFS联邦概述

HDFS 联邦（HDFS Federation ）：指的是一个集群有多个命名空间，即多个 Namenode（注意这里并非指多个集群）。

2.2 为何需要HDFS联邦？ 2.2.1 旧架构的缺陷

看看Hadoop2.x之前hdfs的架构： HDFS主要包含三个层次：

• 命名空间管理（Namespace） ：指命名空间支持对HDFS中的目录、文件和块做类 似文件系统的创建、修改、删除、列表文件和目录等基本操作
• 块（Block Storage）：块管理主要处理 DataNode 向 NameNode 注册的请求及心跳、接收和维护块。
• 存储管理（Block Storage）：指的是DataNode 把块存储到本地文件系统中，对本地文件系统的读、写。

但是这种架构存在缺陷的：

• 块存储和 namespace 高耦合：当前 namenode 中的namespace和 block management的结合使得这两层架构耦合在一起，难以让其它可能namenode 实现方案直接使用 block storage；
• NameNode 扩展性： DataNode节点是可以水平扩展的，但namespace不可以，因为当前的 namespace 只能存放在单个namenode 上，而 namenode 在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目;
• 性能: 文件操作的性能制约于单个 namenode 的吞吐量，单个 namenode 当前仅支持约 60,000 个并发 task，而下一代Apache MapReduce将支持超过 1,00,000 个并发任务 ，这意味着将需要更多的 Namenode（集群）。
• 隔离性：现在大部分公司的集群都是共享的，每天有来自不同部门的不同用户提交作业，单个NameNode难以提供隔离性。

那么如何解决这些缺陷呢？这个时候，在Hadoop2.0引入了HDFS Federation 及HDFS联邦。

2.2.2 HDFS Federation

Hadoop 2.0引入了基于共享存储的高可用解决方案和 HDFS Federation，其原理图如下： 上图主要有几个角色：

• namenode / namespace：为了水平扩展namenode，federation 使用了多个独立的 namenode / namespace，NameNode之间相互独立且不需要互相协调，各自分工，管理自己的区域；
• datanode：被用作通用的数据块存储存储设备，每个 datanode 要向集群中所有的 namenode注册，且周期性地向所有 namenode发送心跳和块报告，并执行来自所有 namenode 的命令；
• block pool：每个 block pool 内部自治，也就是说各自管理各自的 block，不会与其他 block pool 交互，一个 namenode挂掉了，不会影响其他 namenode。
• 命名空间卷：由namenode 上的 namespace 和它对应的block pool组成。它是管理的基本单位，当一个 namenode / nodespace被删除后，其所有datanode 上对应的 block pool也会被删除，当集群升级时，每个 namespace volume 作为一个基本单元进行升级。

2.3 HDFS联邦案例 2.3.1 原理

在 Hadoop 2.0中，由于引入了 HDFS Federation，当你启用该功能时，会同时存在多个可用的 namenode，为了便于配置 “fs.default.name”，你可以规划这些 namenode的使用方式，比如:

• 图片组使用 namenode2
• 爬虫组使用 namenode1等等

HDFS Federation 借鉴 Linux 提供了client-side mount table，这是通过一层新的文件系统 viewfs 实现的，它实际上提供了一种映射关系，将一个全局（逻辑）目录映射到某个具体的 namenode（物理）目录上，采用这种方式后，core-site.xml配置如下 :

fs.default.name
viewfs://ClusterName/

其中，“ClusterName” 是HDFS 整个集群的名称，你可以自己定义一个。mountTable.xml配置了全局（逻辑）目录与具体 namenode（物理）目录的映射关系，你可以类比 linux挂载点来理解。

2.3.2 举例

假设你的集群中有三个 namenode，分别是 namenode1，namenode2 和 namenode3，其中:

• namenode1管理/usr 和 /tmp 两个目录
• namenode2 管理 /projects/foo目录
• namenode3管理/projects/bar 目录

则可以创建一个名为 “cmt” 的client-side mount table，并在 mountTable.xml 中进行如下配置：

 
 
fs.viewfs.mounttable.cmt.link./user 
 hdfs://namenode1:9000/user  
 

fs.viewfs.mounttable.cmt.link./tmp 
 hdfs:/ namenode1:9000/tmp  
 
 
fs.viewfs.mounttable.cmt.link./projects/foo 
 hdfs://namenode2:9000/projects/foo  
 
 
fs.viewfs.mounttable.cmt.link./projects/bar 
 hdfs://namenode3:9000/projects/bar 
 

经过以上配置后，就可以访问 HDFS 上的文件，比如：

bin/hadoop fs –ls /usr/dongxicheng/data

命令中的 “/usr/dongxicheng/data” 将被映射成 “hdfs://namenode1:9000/user/dongxicheng/data”

03 文末

本文主要讲解HDFS联邦，谢谢大家的阅读，本文完！

参阅文献：

• https://www.hadoopdoc.com/hdfs/hdfs-federation