在很多时候,我们会碰到数据融合的需求,比如说原先有A集群,B集群,后来管理员认为有2套集群,数据访问不方便,于是设法将A,B集群融合为一个更大的集群,将他们的数据都放在同一套集群上.一种办法就是用Hadoop自带的DistCp工具,将数据进行跨集群的拷贝.当然这会带来很多的问题,如果数据量非常庞大的话.本文给大家介绍另外一种解决方案,ViewFileSystem,姑且可以叫做视图文件系统.大意就是让不同集群间维持视图逻辑上的唯一性,不同集群间还是各管各的.

为了形成对比,下面描述一下数据合并中常用的数据合并的做法,就是搬迁数据.举例在HDFS中,也会想到用DistCp工具进行远程拷贝.虽然DistCp本身就是用来干这种事情的,但是随着数据量规模的升级,会有以下问题的出现:

1. 拷贝周期太长,如果数据量非常大,在机房总带宽有限的情况,拷贝的时间将会非常长.
2. 数据在拷贝的过程中,一定会有原始数据的变更与改动,如何同步这方面的数据也是需要考虑的方面.

ViewFileSystem: 视图文件系统

ViewFileSystem不是一个新的文件系统,只是逻辑上的一个视图文件系统,在逻辑上是唯一的.
ViewFileSystem就帮大家做了一件事情：将各个集群的真实文件路径与ViewFileSystem的新定义的路径进行关联映射

上面这句话的意思就好比文件系统中的mount,挂载的意思.进一步地说,ViewFileSystem会在每个客户端中维护一份mount-table挂载关系表,就是上面说的集群物理路径->视图文件系统路径这样的指向关系.但是在mount-table中,关系当然不止1个,会有很多个.比如下面所示的多对关系:

/user          -> hdfs://nn1/containingUserDir/user
/project/foo   -> hdfs://nn2/projects/foo
/project/bar   -> hdfs://nn3/projects/bar

前面是ViewFileSystem中的路径,后者才是代表的真正集群路径.所以你可以理解为ViewFileSystem真正干的事情就是路径的路由解析.下面给出简单的原理图:

image.png

HDFS Federation产生背景

在Hadoop 1.0中，HDFS的单NameNode设计带来诸多问题，包括单点故障、内存受限制约集群扩展性和缺乏隔离机制（不同业务使用同一个NameNode导致业务相互影响）等，为了解决这些问题,Hadoop 2.0引入了基于共享存储的HA解决方案和HDFS Federation，这里重点介绍HDFS Federation。

HDFS Federation是指HDFS集群可同时存在多个NameNode，这些NameNode分别管理一部分数据，且共享所有DataNode的存储资源。这种设计可解决单NameNode存在的以下几个问题：

• HDFS集群扩展性。多个NameNode分管一部分目录，使得一个集群可以扩展到更多节点，不再像1.0中那样由于内存的限制制约文件存储数目
• 性能更高效。多个NameNode管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
• 良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理，这样不同业务之间影响很小。

需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每个NameNode都存在在单点故障问题，你需要为每个namenode部署一个backup namenode以应对NameNode挂掉对业务产生的影响。

HDFS Federation架构

在hadoop2.0架构中，namenode federation（联合）通过多个namenode/namespace把元数据的存储和管理分散到多个节点中，使到namenode/namespace可以通过增加机器来进行水平扩展，并且能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候不会也降低HDFS的性能。还有可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。

image.png

如果上图所示，一个block pool由属于同一个namespace的数据块组成，每个namenode管理一个namespace，即每个namenode负责存储和管理一个block pool的元数据。而每个datanode是会连接所有的namenode的，为所有的block pools所共享，即每个datanode都会存储所有的block pools的数据块。每个block pool通过namespace隔离开来，对一个block pool的操作不会影响另外一个block pool。

从配置和使用的角度来看，整个HDFS有一个唯一的clusterid，如“hellokitty”，它可以配置多个block pool/namespace（也叫name service），如“mycluster”和“yourcluster”。为了方便访问不同名字空间的目录和文件，federation还提供了一个类似linux的Client Side Mount Table的挂载机制，提供了一个统一的全局的文件系统视图（viewfs）。用户可以根据自己的需要把各个namespace挂载到一个叫做viewFS的文件系统视图的不同目录下。例如namespace/name service “mycluster”和“yourcluster”分别挂载到viewfs的“/my”和“/your”目录下，如下图所示：

image.png

federation和HA

上面提到的每个namespace/name service配置一个namenode，这样这个namespace/name service的单点问题还是存在，因此可以给每个namespace/name service配置成HA。

假设我们有4台namenode，分别是namenode1，namenode2，namenode3，namenode4。其中namenode1和namenode2是namespace/name service“mycluster”的两个主备namenode节点，NN_ID分别是“mycluster”的“nn1”和“nn2”；而namenode3和namenode4是namespace/name service“yourcluster”的两个主备namenode节点，NN_ID分别是“yourcluster”的“nn1”和“nn2”。

“mycluster”和“yourcluster”分别挂载在viewfs的“/my”和“/your”目录下。

image.png

一般1000台机器一下的中小规模的hadoop集群，一个namespace/name service就足够了，不需要考虑federation，以免增加不必要的复杂性。

HDFS Federation配置介绍

下面将通过介绍HDFS客户端配置方法，并通过对客户端配置的讲解让大家深入理解HDFS Federation引入的“client-side mount table”（viewfs）这一概念，这是通过新的文件系统viewfs实现的。

Hadoop 1.0中的配置

在Hadoop 1.0中，只存在一个NameNode，所以，客户端设置NameNode的方式很简单，只需在core-site.xml中进行以下配置：

`<``property``>`

`<``name``>fs.default.name</``name``>`

`<``value``>[hdfs://host0001:9000](hdfs://host0001:9000)</``value``>`

`</``property``>`

设置该参数后，当用户使用以下命令访问hdfs时，目录或者文件路径前面会自动补上“hdfs://host0001:9000”：

bin/hadoop fs –ls /home/xxx/data

其中“/home/xxx/data”将被自动替换为“hdfs://host0001:9000/home/xxx/data”

当然，你也可以不在core-site.xml文件中配置fs.default.name参数，这样当你读写一个文件或目录时，需要使用全URI地址，即在前面添加“hdfs://host0001:9000”，比如：

bin/hadoop fs –ls hdfs://host0001:9000/home/xxx/data

Hadoop 2.0中的配置

在Hadoop 2.0中，由于引入了HDFS Federation，当你启用该功能时，会同时存在多个可用的namenode，为了便于配置“fs.default.name”，你可以规划这些namenode的使用方式，比如图片组使用namenode1，爬虫组使用namenode2等等，这样，爬虫组员工使用的HDFS client端的core-site.xml文件可进行如下配置：

<property>

<name>fs.default.name</name>

<value>[hdfs://namenode1:9000](hdfs://namenode1:9000)</value>

</property>

图片组员工使用的HDFS client端的core-site.xml文件可进行如下配置：

<property>
    <name>fs.default.name</name>
    <value>hdfs://namenode2:9000</value>
 </property>

从HDFS和HBase使用者角度看，当仅仅使用单NameNode上管理的数据时，是没有问题的。但是，当考虑HDFS之上的计算类应用，比如YARN/MapReduce应用程序，则可能出现问题。因为这类应用可能涉及到跨NameNode数据读写，这样必须显式的指定全URI，即输入输出目录中必须显式的提供类似“hdfs://namenode2:9000”的前缀，以注明目录管理者NameNode的访问地址。

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

<configuration xmlns:xi="http://www.w3.org/2001/XInclude"> 
<xi:include href="mountTable.xml"/>
<property> 
<name>fs.default.name</name> 
<value>viewfs://ClusterName/</value> 
</property>
</configuration>

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

假设你的集群中有三个namenode，分别是namenode1，namenode2和namenode3，其中，namenode1管理/usr和/tmp两个目录，namenode2管理/projects/foo目录，namenode3管理/projects/bar目录，则可以创建一个名为“cmt”的client-side mount table，并在mountTable.xml中进行如下配置：

<configuration> 
<property> 
<name>fs.viewfs.mounttable.cmt.link./user</name> 
<value> hdfs://namenode1:9000/user </value> 
</property> 
<property>
<name>fs.viewfs.mounttable.cmt.link./tmp</name> 
<value> hdfs:/ namenode1:9000/tmp </value> 
</property> 
<property> 
<name>fs.viewfs.mounttable.cmt.link./projects/foo</name> 
<value> hdfs://namenode2:9000/projects/foo </value> 
</property> 
<property> 
<name>fs.viewfs.mounttable.cmt.link./projects/bar</name> 
<value> hdfs://namenode3:9000/projects/bar</value> 
</property> 
</configuration>

经过以上配置后，你可以像1.0那样，访问HDFS上的文件，比如：bin/hadoop fs –ls /usr/xxx/data

中的“/usr/xxx/data”将被映射成“hdfs://namenode1:9000/user/xxx/data”。
Client-side mount table的引入为用户使用HDFS带来极大的方便，尤其是跨namenode的数据访问。