ViewFs Guide

简介

文件浏览系统（ViewFs）提供了一个管理多个Hadoop文件系统命名空间（或者叫Namespace Volume）的方式。它对于有多个NameNode的联邦集群特别有用。ViewFs与Unix/Linux系统中client side mount tables类似。ViewFs可被用来创建个人命名空间视图，也可以每个集群一个公共的试图。

本指南描述了，在有多个集群的Hadoop系统中，每一个集群都可能联合起来形成多个命名空间。也描述了如何在联邦的HDFS中用ViewFs为每一个集群提供一个全局的命名空间，以使应用程序可以以类似于联邦之前的方式运行。

旧的世界（联邦之前）

在联邦之前，一个集群只有一个NameNode为集群提供一个文件系统命名空间。假设有多个集群。每一个集群的文件系统命名空间是完全独立的，没有交互。此外，物理存储是不在集群中共享的（也就是DataNode不在集群中共享，一个DataNode不同时服务于两个集群）。

每一个集群的core-site.xml文件中都有一个配置，设置默认的文件系统：

<property>    <name>fs.default.name</name>   <value>hdfs://namenodeOfClusterX:port</value></property>

这个配置属性允许你把不是相对路径的path解析成相对于这个集群的NameNode的路径。例如，用上边的配置，路径/foo/bar被解析成hdfs://namenodeOfClusterX:port/foo/bar。

这个配置属性在集群中和集群的每个重要的服务像JobTracker and Oozie的每个gateway被设置。

路径名的使用模式

1.      /foo/bar

         这在之前等于 hdfs://namenodeOfClusterX:port/foo/bar。

2.      hdfs://namenodeOfClusterX:port/foo/bar

         虽然这是一个有效的路径名，但是你最好使用/foo/bar，因为需要的时候，它允许应用和它的数据可以被透明的移植到其他的集群。

3.      hdfs://namenodeOfClusterY:port/foo/bar

这是一个引用了另一个集群ClusterY上的路径的URI。特别地，下面的命令是从集群ClusterY上拷贝文件到集群ClusterZ：      

distcp hdfs://namenodeClusterY:port/pathSrc hdfs://namenodeClusterZ:port/pathDest

4.      webhdfs://namenodeClusterX:http_port/foo/bar 和hftp://namenodeClusterX:http_port/foo/bar

这些文件系统的URI各自代表通过WebHDFS文件系统和HFTP文件系统访问文件。注意NameNode的WebHDFS和HFTP的端口号不是RPC端口号。

5.      http://namenodeClusterX:http_port/webhdfs/v1/foo/bar and http://proxyClusterX:http_port/foo/bar

这些HTTP URL各自代表通过WebHDFS REST API和HDFS proxy访问文件系统。

路径名使用最佳实践

当你使用一个集群时，建议用上边第一种类型代替第二种全限定名的类型。全限定名URL处理起来相似，而且不允许程序和其数据移植。

新世界 联邦和ViewFs

集群将会如何

假设有多个集群。每一个集群都有一个或者多个NameNode。每一个NameNode都有自己的命名空间。一个NameNode只属于一个集群。同一个集群中NameNode共享集群的物理存储。跨集群的NameNode各自独立。

业务基于存储需要，决定一个集群中的每一个NameNode中存放的东西。例如，他们可能会将用户数据（/user/<username>）放到一个NameNode中，所有的提要数据（/data）在另一个NameNode中，所有的项目数据（/projects）在另另一个NameNode中，等等。

使用ViewFs为每一个集群应用一个全局的命名空间

为了与旧的世界透明，ViewFs文件系统（也就是客户端挂载表）被用来为每一个独立的集群创建一个命名空间视图，这也旧世界中的命名空间类似。客户端挂载表就像Unix挂载表，它们用旧的命名方式挂载新的Namespace Volume。下面的图片展示了一个挂载了四个Namespace Volume的挂载表/user, /data, /projects, and /tmp。

ViewFs实现了Hadoop文件系统的接口，就行HDFS和本地文件系统一样。它仅允许连接到其他的文件系统，就此而言，它是一个简单的文件系统。因为ViewFs实现了Hadoop文件系统的接口，它作为一个透明Hadoop的工具。例如，所有ViewFs的shell命令就像HDFS和本地文件系统的一样。

一个挂载表的挂载点在一个标准Hadoop配置文件中被指定。在每一个集群的配置中，默认的文件系统被设置为集群的挂载表，就像下面这样：

<property>    <name>fs.default.name</name>    <value>viewfs://clusterX</value></property>

URI中的authority 部分遵循 viewfs://模式，此部分也是挂载名。建议一个集群的挂载表应该以集群的名字命名。Hadoop系统将用Hadoop配置文件中的集群名字clusterX查找挂载表。业务布置所有的网关和服务机器包含挂载了所有集群的挂载表，像这样，对于每一个集群，默认的文件系统被设置为ViewFs挂载表，就像上边描述的那样。

路径名使用模式

在集群X中，在core-site.xml文件中设置默认的文件系统为viewfs://

模式来使用集群的挂载表。典型的路径名是：

1.      /foo/bar

这等于viewfs://clusterX/foo/bar。如果这个路径名之前被用在非联邦的集群中，转换到联邦的集群中是透明的。

2.      viewfs://clusterX/foo/bar

虽然这是个有效的路径名，更好的做法是用/foo/bar，因为需要的时候它允许应用和应用的数据被透明的移植到其他的集群上。

3.      viewfs://clusterY/foo/bar

这是一个引用到另一个集群clusterY的路径的URI。特别地，下面的命令式从集群y中拷贝文件到集群Z：

distcp viewfs://clusterY:/pathSrc viewfs://clusterZ/pathDest

4.      viewfs://clusterX-webhdfs/foo/bar and viewfs://clusterX-hftp/foo/bar

这两个URI各自代表铜多WebHDFS文件系统和HFTP文件系统访问文件。

5.      http://namenodeClusterX:http_port/webhdfs/v1/foo/bar and http://proxyClusterX:http_port/foo/bar

这两个HTTP URL分别表示通过WebHDFS REST API和HDFS代理来访问文件。注意和之前的相同。

路径名使用最佳实现

当你使用一个集群时，建议使用第一种类型的路径名代替像类型2那样的全路径名。而且，应用不应该知道挂载点的相关信息和使用像hdfs://namenodeContainingUserDirs:port/joe/foo/bar这样的路径来引用一个特定namenode上的文件。你应用/user/joe/foo/bar代替。

重命名跨命名空间的文件名

在旧的世界中，你不能跨集群命名空间重命名文件和目录。新世界中也是一样，但是有特殊情况。例如，在旧世界中，你可以运行下面的命令：

rename /user/joe/myStuff /data/foo/bar

新世界中，如果 /user and /data 真的存储在一个集群的不同命名空间中，这将不起作用。

FAQ

1.      当我将一个非联邦集群转换成联邦的集群时，我必须为不同的Volume对各个NameNode保持联系，我可以这么做么？

NO，you won’t。看上边的例子，要么你正在利用默认文件系统使用相对路径，要么将你的路径从hdfs://namenodeCLusterX/foo/bar 转成 viewfs://clusterX/foo/bar。

2.      当从一个集群的一个NameNode复制文件到另一个NameNode是，发生了什么？

这个操作可能会从一个NameNode中移动文件到另一个NameNode，以解决存储能力的问题。这个过程将会以避免应用崩溃的方式进行。让我们举些例子：

1>    例1：/user and /data在一个NameNode上，后来，它们需要被放到不同的NameNode来解决存储能力的问题。的确，这个操作将会为 /user and /data创建单独的挂载。在改变之前，/user and /data的挂载会指向同一个NameNode，也就是namenodeContainingUserAndData。这个操作将更新挂载表以使挂载点各自变为namenodeContaingUser and namenodeContainingData。

2>    例2：所有的项目被安装在一个NameNode上，但是之后，需要两个或者更多的NameNode。ViewFs允许像 /project/foo and /project/bar这样挂载。这会使挂载表被更新来指向相应的NameNode。

3.      挂载表在每一个core-site.xml配置文件还是在自己在一个单独的文件里？

设计是保持挂载表在一个单独的文件中，然后使core-site.xml文件包含这个独立的文件。虽然你可以在每一台机器本地保存这些文件，最好的做法是用HTTP从一个中心存储位置获取。

4.      一个集群还是所有的集群的配置有挂载表的定义？

所有集群的配置都应该有挂载定义，因为可能需要访问其他集群中的数据，像使用discp时。

5.      随着时间的推移，如果操作改变了挂载表，那么挂载表什么时候被读取？

挂载表在作业提交到集群的时候被读取。core-site.xml文件中的XInclude 在作业提交的时候被打开。这意味着，如果挂载表被改变，作业需要重新被提交。考虑到这个原因，我们想实现合并挂载，这将极大的减少改变挂载表的需要。而且，将来，我们将通过另一个机制读取挂载表，这个机制是在作业开始时挂载表被初始化。

6.      Jobtracker（或者yarn的ResourceManager）自己使用ViewFs么？

不，它不需要。NodeManager也不需要。

7.      ViewFs只允许挂在顶层目录么？

NO；比这更通用。例如，你可以挂在/user/joe and /user/jane。在这种情况下，在挂在表中，一个内部的只读文件夹为/user被创建。所有在/user的操作除了 /user是只读的都是有效的。

8.      一个应用跨集群工作，需要持久地存储文件路径名，我应该用哪一种方式存储？

你应该用viewfs://cluster/path类型的路径名，运行程序的时候也是。这使你隔离一个集群中一个NameNode的数据移动，只要操作以透明的方式移动数据。如果数据被从一个集群移动到另一个，它不会隔离数据。联邦之前的做法将不会保护你免受集群间的数据移动。

9.      关于Delegation tokens。

集群中你正在提交作业的Delegation token（包括集群挂载表挂载的所有Volume），和你的MR作业的输入输出路径（包括所有通过挂载表指定的输入输出路径）的Delegation token被自动处理。另外，有一个增加额外的Delegation token到特殊情况下的基础集群配置的方式。

附录：一个挂载表配置例子

通常，用户不需要通过定义用户挂载表或者core-site.xml来使用挂载表特性。这通过多个操作完成，在正确的gateway机器上有正确的配置，就像现在为 core-site.xml做的。

挂载表可以在 core-site.xml文件中描述，但是最好使用不直接的方式，在 core-site.xml文件中引用一个单独的挂载表配置文件，也就是mountTable.xml。增加下面的配置元素到core-site.xml文件中来引用mountTable.xml：

<configuration xmlns:xi="http://www.w3.org/2001/XInclude">   <xi:include href="mountTable.xml" /></configuration> 

在mountTable.xml文件中，有一个对假想的集群ClusterX的挂载表的定义，这个集群是一个有3个Namespace Volume的联邦集群，被3个NameNode管理：

1.   nn1-clusterx.example.com:8020,

2.   nn2-clusterx.example.com:8020, and

3.   nn3-clusterx.example.com:8020.

命名空间中的 /home and /tmp被nn1-clusterx.example.com:8020管理，/foo and /bar在联邦集群中的另一个NameNode上。Home目录基目录是 /home，所以每一个用户可以用 FileSystem/FileContext的getHomeDirectory() 方法访问自己的home目录。

<configuration>  <property>    <name>fs.viewfs.mounttable.ClusterX.homedir</name>    <value>/home</value>  </property>  <property>    <name>fs.viewfs.mounttable.ClusterX.link./home</name>    <value>hdfs://nn1-clusterx.example.com:8020/home</value>  </property>  <property>    <name>fs.viewfs.mounttable.ClusterX.link./tmp</name>    <value>hdfs://nn1-clusterx.example.com:8020/tmp</value>  </property>  <property>    <name>fs.viewfs.mounttable.ClusterX.link./projects/foo</name>    <value>hdfs://nn2-clusterx.example.com:8020/projects/foo</value>  </property>  <property>    <name>fs.viewfs.mounttable.ClusterX.link./projects/bar</name>    <value>hdfs://nn3-clusterx.example.com:8020/projects/bar</value>  </property></configuration>

融知与行 瀚且高远

------------------------------------

作者：陈振阳

山东瀚高基础软件股份有限公司  研发中心

博客地址：http://blog.csdn.net/xichenguan/

本文链接：http://blog.csdn.net/xichenguan/article/details/38553437

转载请注明地址