介绍
视图文件系统(ViewFs)提供了一种方法来管理多个Hadoop文件系统名字空间(或名字空间卷)。这种方法对于拥有多个名称节点和名字空间卷的联邦HDFS特别有用。ViewFs类似于Unix / Linux系统中的客户端挂载表。ViewFs可用于创建个性化的名字空间视图以及每个群集的通用访问。
本指南在具有多个集群的Hadoop系统上下文中呈现,每个集群可以联合到多个命名空间中。它还描述了如何在联邦HDFS中使用ViewFs来为每个群集提供全局的名字空间,以便于应用程序可以用联邦前的方式运行。
旧系统(联邦前)
单Namenode集群
在联邦HDFS之前的旧系统中,集群只有一个namenode,为该集群提供单个文件系统的名字空间。假设有多个集群。每个集群的文件系统名字空间是完全独立的,不相交的。而且,物理存储不会跨群集共享(即Datanodes不会在群集之间共享)。
每个集群的core-site.xml都有一个配置属性,用于将默认文件系统设置为该集群的namenode:
<property> <name>fs.default.name</name> <value>hdfs://namenodeOfClusterX:port</value> </property>
这样的配置属性允许使用斜杠命名来解析相对于集群节点的路径。例如,对于上述配置,路径/foo/bar是指使用上述配置的hdfs//namenodeOfClusterX:port/foo/bar。
该配置属性在集群上的每个网关以及该集群的关键服务(如JobTracker和Oozie)上进行设置。
路径名使用模式
因此,在集群X中,将core-site.xml设置为上面所述,典型的路径名称是
-
/foo/bar
- 这相当于以前的hdfs://namenodeOfClusterX:port/foo/bar。
-
hdfs://namenodeOfClusterX:port/foo/bar
- 虽然这是一个有效的路径名,但是最好使用/foo/bar,因为它允许应用程序及其数据在需要时透明地移动到另一个集群。
-
hdfs://namenodeOfClusterY:port/foo/bar
- 它是用于引用另一个集群(如Cluster Y)上的路径名的URI。具体一点,将文件从集群Y复制到集群Z的命令如下所示:
distcp hdfs://namenodeClusterY:port/pathSrc hdfs://namenodeClusterZ:port/pathDest
-
webhdfs://namenodeClusterX:http_port/foo/bar and hftp://namenodeClusterX:http_port/foo/bar
- 这些是分别用于通过WebHDFS文件系统和HFTP文件系统访问文件的文件系统URI。请注意,WebHDFS和HFTP使用namenode的HTTP端口而不是RPC端口。
-
http://namenodeClusterX:http_port/webhdfs/v1/foo/bar 和 http://proxyClusterX:http_port/foo/bar
- 这些是分别通过WebHDFS Rest API和HDFS代理访问文件的HTTP URL 。
新系统 - 联邦和ViewFs
集群概述
假设有多个集群。每个集群都有一个或多个节点。每个namenode都有自己的命名空间。每个namenode仅属于唯一的一个集群。同一集群中的NameNode共享该集群的物理存储。群集之间的名字空间与之前一样是独立的。
根据存储需求,操作决定集群内每个节点上存储的内容。例如,他们可以将所有用户数据(/user/<username>)放在一个NameNode中,所有的反馈数据(/data)存放到另一个NameNode中,所有项目数据(/projects)存放到再另一个NameNode中,等等。
使用ViewFs为每个群集创建全局名字空间
为了提供与旧世界的透明度,ViewFs文件系统(即客户端挂载表)用于为每个集群创建独立的集群名字空间视图,该视图类似于旧系统中的名字空间。客户端挂载表类似Unix挂载表,并使用旧的命名约定挂载新的名字空间卷。下图显示了一个挂载表,其中挂载了四个名字空间卷/ user,/ data,/ projects和/ tmp:
ViewFs实现了Hadoop文件系统界面,就像HDFS和本地文件系统一样。这是一个分区文件系统,它只允许链接到其他文件系统来使用。由于ViewFs实现了Hadoop文件系统界面,因此它具有透明的Hadoop工具。例如,与HDFS和本地文件系统一样,所有的shell命令都可以与ViewFs一起使用。
挂载表的挂载点由Hadoop的标准配置文件指定。在每个集群的配置中,默认文件系统设置为该集群的挂载表,如下所示(与单个Namenode集群中的配置进行比较)。
<property> <name>fs.default.name</name> <value>viewfs://clusterX</value> </property>
再URI如viewfs://scheme中,后面的是挂载表名称。它确定了集群的挂载表应以何命名。然后Hadoop系统将在Hadoop配置文件中查找名为“clusterX”的挂载表。在所有设置了如上挂载表的网关和服务机器中的集群进行操作,默认文件系统被设置为该集群的ViewFs挂载表,如上所述。
路径名使用模式
因此,在集群X上,当core-site.xml中的默认文件系统被设置为使用该集群的挂载表时,典型的路径名称为:
-
/foo/bar
- 这相当于使用viewfs//clusterX/foo/bar。如果在旧的非联邦系统中使用这样的路径名,那么向联邦系统的过渡是透明的。
-
viewfs://clusterX/foo/bar
- 虽然这是一个有效的路径名,但是更推荐使用/foo/bar,因为它允许应用程序及其数据在需要时透明地移动到另一个集群。
-
viewfs://clusterY/foo/bar
- 它是用于引用另一个集群(如Cluster Y)上的路径名的URI。特别地,将文件从集群Y复制到集群Z的命令如下所示:
distcp viewfs://clusterY:/pathSrc viewfs://clusterZ/pathDest
-
viewfs://clusterX-webhdfs/foo/bar and viewfs://clusterX-hftp/foo/bar
- 这些是分别通过WebHDFS文件系统和HFTP文件系统访问文件的URI。
-
http://namenodeClusterX:http_port/webhdfs/v1/foo/bar and http://proxyClusterX:http_port/foo/bar
- 这些是分别通过WebHDFS REST API和HDFS代理访问文件的HTTP URL。请注意,它们与以前相同。
路径名用法最佳实践
当使用集群时,建议使用上述类型(1)的路径名,而不是像类型(2)这样的完全限定的URI。此外,应用程序不应该使用挂载点的信息做出像hdfs://namenodeContainUserDirs:port/joe/foo/bar这样的路径来引用特定namenode中的文件,而应该使用/user/joe/foo/bar路径来代替。
在名字空间之间重命名路径
回想一下,在旧系统中不能在多个namenode之间或集群中重命名文件或目录。新系统也是如此,但还有一点。在旧系统中可以使用如下命令。
rename /user/joe/myStuff /data/foo/bar
在新系统中,如果/user和/data实际上存储在集群中的不同节点上,这将不会成功执行。
常问问题
-
当我从非联邦系统转变为联邦系统时,我将不得不跟踪不同卷的数据; 我怎么做?
不,你不需要。请参阅上面的示例 - 您可以使用相对路径并使用默认文件系统,或将路径从hdfs://namenodeCLusterX/foo/bar更改为viewfs://clusterX/foo/bar。
-
操作会怎样将一些文件从一个namenode移动到集群中的另一个namenode?
操作可能会将文件从一个NameNode移动到另一个NameNode来处理存储容量的问题。他们会这样做来避免应用程序崩溃。我们举一些例子。
- 示例1:/user和/data在同一个namenode上,后来他们需要部署在分开独立的namenode上来处理容量问题。实际上,操作会为/user和/data创建单独的挂载点。在更改之前,/user和/data的mount将指向相同的namenode,例如namenodeContainingUserAndData。操作会更新挂载表,以便挂载点分别更改为namenodeContaingUser和namenodeContainingData。
- 示例2:所有项目都安装在一个namenode上,但后来他们需要两个或更多的namenode。ViewFs允许像/project/foo和/project/bar这样的挂载。这样可以使挂载表更新为指向相应的namenode。
-
每个core-site.xml中的挂载表是否在自己的单独文件中?
该计划是将挂载表保存在单独的文件中,并设置到core-site.xml中。虽然可以在每个机器上本地保存这些文件,但最好使用HTTP从中央位置访问它们。
-
配置挂载表是否只需要一个集群集群进行配置或所有集群都需要进行配置?
挂载表配置应配置到所有集群中,因为一个集群需要访问其他集群中的数据(如distcp)。
-
由于操作可能会随着时间的推移更改挂载表,因此挂载表实际读取时间是多少?
当作业提交到群集时,开始读取挂载表。core-site.xml中的XInclude在作业提交时被扩展。这意味着如果挂载表更改,那么作业需要重新提交。由于这个原因,我们希望实现一个挂载表合并,这将大大减少更改挂载表的需要。此外,我们想在将来通过一个其他的机制来读取挂载表,在作业开始时就进行初始化。
-
JobTracker(或yarn资源管理器)本身会使用ViewFs吗?
不需要。NodeManager也同样不需要。
-
ViewFs只允许在顶层安装吗?
不是的; 它更加通用。例如,可以挂载 /user/joe和/user/jane。在这种情况下,在挂载表中创建/user这个内部只读目录。/user上的所有的属于只读属性的操作都是有效的。
-
一个应用程序在整个集群中的工作需要持久存储文件路径。 应该选择哪些路径进行存储?
您应该存储viewfs://cluster/path类型的路径名,与运行应用程序时所使用的路径名相同。只要操作以透明的方式进行移动,这将使您不必在集群内的数据集中移动数据。如果数据从一个集群移动到另一个集群,它不会使您绝望; 旧的系统(联邦前)并没有保护你在集群之间形成这样的数据移动。
-
代理令牌怎么办?
要提交作业的群集(包括该群集的挂载表中所有已挂载的卷)以及map-reduce作业的输入和输出路径(包括指定输入和输出涉及到的挂载表的所有卷)的代理令牌路径都被自动处理。此外,有一种方法可以在特殊情况下为基本群集配置添加额外的代理令牌。
附录:安装表配置示例
通常,用户不必定义挂载表或core-site.xml来使用挂载表。这是通过操作完成的,正确的配置是在相应的网关机器上设置的,就像今天对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”的定义是由三个节点管理的三个命名空间卷的联邦。
- nn1-clusterx.example.com:8020,
- nn2-clusterx.example.com:8020,和
- nn3-clusterx.example.com:8020。
这里/home和/tmp位于由namenode nn1-clusterx.example.com:8020管理的命名空间中,/project/foo和/bar托管在联邦集群的其他节点上。主目录基本路径设置为/home,以便每个用户可以使用FileSystem/FileContext中定义的getHomeDirectory()方法访问其主目录。
<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>