HDFS Federation(联邦)

1.简介

hdfs federation即hdfs的联邦，可以简单理解为多个hdfs集群聚合到一起，更准确的理解是有多个namenode节点的hdfs集群

hadoop1.x的hdfs架构

主要由namespace（命名空间）和Block Storage（块的存储）两层组成

1.1.namespace

由目录、文件、块组成。

支持创建、删除、修改、列举命名空间相关系统的操作

1.2.Block Storage

block management：

块的管理，在namenode中完成

通过控制注册和阶段性的心跳来保证datanode正常运行

处理块的信息报告，维护块的位置信息

创建，修改，删除，查询块

管理副本和副本位置

1.3 Storage：（在datanode上）

提供对块的读写操作

单namenode架构的局限性

1.namespace命名空间限制
namenode把所有元数据存储在内存中，单个namenode所能存储的对象（文件+块）有限制
2.性能瓶颈（吞吐量）
整个hdfs文件系统的吞吐量受限于单个namenode的吞吐量
3.隔离问题
无法隔离应用程序，一个实验程序，可能影响整个集群
4.单点故障
5.namespace和block management紧密耦合

紧密耦合导致使用另外一种namenode方案比较困难，也限制了其他想使用快存储的应用

6.纵向扩展namenode为什么不可行
启动时间长，调试困难，集群易宕机
比如将Namenode的Heap空间扩大到512GB。
第一个问题就是启动问题，启动花费的时间太长。当前具有50GB的Heap Namenode的HDFS启动一次大概需要30分钟到2个小时，那512GB呢？
第二个潜在的问题就是Namenode在Full GC时，如果发生错误将会导致整个集群宕机。

第三个问题是对大JVMHeap进行调试比较困难。优化Namenode的内存使用性价比比较低

2 Federation架构

1.这些namenode直接相互独立，各自分工管理自己的区域，且不需要互相协调，一个namenode挂掉了不会影响其他的namenode
2.datanode被用作通用的数据存储设备，每个datanode要向集群中所有的namenode注册，且周期性的向所有namenode发送心跳和报告，并执行来自所有namenode的命令
3.一个block pool由属于同一个namespace的数据块组成，每个datanode可能会存储集群中所有block pool 数据块
每个block pool内部自治，各自管理各自的block，不会与其他block pool交流

4.namenode和block pool一起被称作namespace volume，它是管理的基本单位，当一个namespace被删除后，所有datanode上与其对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级

2.1Federation关键技术点

命名空间管理

Federation中存在多个命名空间，在Federation中采用"文件名hash"的方法，因为该方法的locality非常差，
比如：某个目录下的文件，采用"文件名hash"的方法，这些文件可能会被放到不同的namespace中，hdfs要访问所有的namespace，代价太大。
为了方便管理多个命名空间，HDFS Federation采用了经典的Client Side Mount Table

下面四个深色的三角代表4个独立的命名空间，上方的灰色三角形代表从客户角度去访问的子命名空间。

各个深色的命名空间mount到灰色的表中，客户端可以通过不同的挂载点来访问不同的命名空间，如同linux系统中访问不同挂载点一样。这就是federation的基本原理：将各个命名空间挂载到全局mount-table中，就可以将数据全局共享，同样的命名空间挂载到个人的mount-table中，就成为应用程序可见的命名空间视图

Block Pool管理

HDFS Federation的不足
HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但对于单个namenode来说，仍然存在单点故障。
如果某个namenode挂掉了，其管理的相应文件便不可以访问。
Federation中每个namenode仍然像之前一样，配有一个secondary namenode，以便主namenode挂掉后，用于还原元数据信息

2 Federation Configuration

2.1 配置

Step 1: Add the dfs.nameservices parameter to your configuration and configure it with a list of comma separated NameServiceIDs. This will be used by the Datanodes to determine the Namenodes in the cluster.

Step 2: For each Namenode and Secondary Namenode/BackupNode/Checkpointer add the following configuration parameters suffixed with the correspondingNameServiceID into the common configuration file:

Daemon	Configuration Parameter
Namenode	dfs.namenode.rpc-address
Namenode	dfs.namenode.servicerpc-address
Namenode	dfs.namenode.http-address
Namenode	dfs.namenode.https-address
Namenode	dfs.namenode.keytab.file
Namenode	dfs.namenode.name.dir
Namenode	dfs.namenode.edits.dir
Namenode	dfs.namenode.checkpoint.dir
Namenode	dfs.namenode.checkpoint.edits.dir
Secondary Namenode	dfs.namenode.secondary.http-address
Secondary Namenode	dfs.secondary.namenode.keytab.file
BackupNode	dfs.namenode.backup.address
BackupNode	dfs.secondary.namenode.keytab.file

2.2 配置示例

Here is an example configuration with two Namenodes:

<configuration>
  <property>
    <name>dfs.nameservices</name>
    <value>ns1,ns2</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.ns1</name>
    <value>nn-host1:rpc-port</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.ns1</name>
    <value>nn-host1:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.secondaryhttp-address.ns1</name>
    <value>snn-host1:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.ns2</name>
    <value>nn-host2:rpc-port</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.ns2</name>
    <value>nn-host2:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.secondaryhttp-address.ns2</name>
    <value>snn-host2:http-port</value>
  </property>

  .... Other common configuration ...
</configuration>

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

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

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

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

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

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

3.2 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</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的访问地址。

3.3 hdfs federation配置
为了解决这种麻烦，为用户提供统一的全局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>

经过以上配置后，你可以像1.0那样，访问HDFS上的文件，比如：其中，“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>

中的“/usr/”将被映射成“hdfs://namenode1:9000/user/”。

Client-side mount table的引入为用户使用HDFS带来极大的方便，尤其是跨namenode的数据访问。

点赞 1
————————————————
版权声明：本文为CSDN博主「bluedream」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fengxuezhiye/article/details/80513313