前言

在大数据时代，随着业务的迅速扩张，很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题，比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-based的功能在一定程度上能优化这块的管理。但是上述2个方案还不能完全cover住HDFS的多cluster管理的痛点问题，比如在一些用户写死在code中的地址，如何能做到纹丝不动的适配到viewfs多集群模式？本文我们来谈论谈论这个话题以及目前社区对此的解决方案。

Hadoop ViewFs的问题痛点

Hadoop ViewFs功能实现的时间可以说是非常早的了，当时最初解决的问题是在client端构建一个视图逻辑上统一的文件系统，ViewFs下不同的路径实际指向的具体的物理cluster地址。简单来说，就是我们在client端添加了一个类似mount point的映射表mapping关系。

因为是基于client side的改动，因此这会导致一个很容易出现的问题，ViewFs的重新部署更新会变得极为的麻烦，在这里面至少会涉及到如下相关服务的变更：

集群内部DataNode上的mount point配置更新
外部Hadoop client的mount point更新
写死在用户应用程序中或者一些hive metastore内部的地址得更新

针对上面的第一，第二点，社区通过实现了server-side的解决方案即HDFS RBF，已经基本可以解决这个问题了。但是对于上述第三点，RBF看似也还是不能很完美地解决。

另外随着当前外部cloud存储的兴起，存储形式已经绝不仅仅依赖于HDFS一种，它可以是S3或者是Ozone类似别的存储系统。Hadoop内部通过构造Hadoop兼容性文件系统(Hadoop Compatible FileSystem，简称HCFS)的方式，能把数据写到这个第三方的cloud storage里去。令人高兴的一点是，目前ViewFs mount point是能够支持这种第三方HCFS的数据写出。不过RBF的实现目前还只能是HDFS内部单一集群的映射，这又是RBF实现的一个不足。

综上所述，我们列举一下上面提到的目前来看所有潜在的问题点：

ViewFs mount point文件的client端维护管理问题
如果使用RBF功能解决client端配置维护问题，如何做到HCFS的访问，达到访问HDFS和non-HDFS系统的透明度和无缝契合。
用户Job程序和一些hard-coded在metastore serivce内的地址还是不好去更新

Hadoop ViewFs的重载hdfs schema方式

社区在JIRAHDFS-15289: Allow viewfs mounts with hdfs scheme and centralized mount table里提到了一种支持重载hdfs schema的方式来改进上面提到的uri地址hard-coded的问题。

既然我们改用户hard-coded或者metadata service里的hdfs uri地址代价这么高的话，那么我们就直接让这些地址进行重新映射，映射关系类似于ViewFs里的那种映射关系不就可以了。

下面通过一个例子来具体看下这个重载schema的模式。

比如在原有系统中，系统和应用程序是通过设置fs.DefautlFS的方式来直接标明其所要访问的目标cluster地址，

// Existing configuration with single HDFS
fs.defaultFS=hdfs://clusterA

然后这个时候我们打算引入多集群的方案，但是又不想改上面这个defaultFS的话，在新的支持重载schema的模式下，我们可以做到如下的mount point mapping：

fs.viewfs.mountable.clusterA.link./User/data → hdfs://clusterB/User/data
fs.viewfs.mountable.clusterA.link./data → s3a://bucketData/data
fs.viewfs.mountable.clusterA.linkfallback → hdfs://clusterA/

对应的语义如下：

当用户通过clusterA地址访问/User/data目录时，它实际请求的是clusterB集群的对应目录数据。
当用户通过clusterA地址访问/data目录时，它实际请求的是s3a外部Hadoop兼容性文件系统对应的目录数据，这个还是支持的，因为重载schema是在ViewFs下做的扩展。
当用户通过clusterA地址访问剩余目录时，则访问的是hdfs://clusterA/自身的集群地址。

这样来看，ViewFs的支持hdfs scheam重载功能可以大大减轻外部相关服务的hdfs uri地址的更新调整所带来的麻烦。

ViewFs的mount point中心化管理问题

在HDFS-15289里，它还提到了关于ViewFs下的mount point中心化管理的问题。Server-side方案RBF无法做到ViewFs下的兼容各种HCFS访问的功能，但ViewFs目前又不具备RBF这种具有中心化管理mount point mapping这样的功能属性。

于是社区也提到了对ViewFs这块的改进之处，有以下几个设想方案：

方案一，将mount point配置文件放在远程server 上，然后通过xml xinclude的方式，以http的请求path去拿到这个配置信息，样例如下：

<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
	<xi:include href="http://localhost:9870/webhdfs/v1/mountTable/mount-table.xml?op=Open"/>
</configuration>

此方案的缺点在于远程server的单点问题，无法保证远程server的high availability，一旦这个配置不可得，对于外部访问HDFS的应用影响巨大。

方案二，利用现有HDFS，将mount point放在HDFS上，通过改进Hadoop Configuration的解析，使其能够支持xml带hdfs地址的数据解析访问。

<property>
	<name>fs.viewfs.mounttable.path</name>
	<value>hdfs://localhost:9000/mountTable/mount-table.xml</value>
</property>

不过上述两种方案存在部分共同问题：

每次job启动都会进行一次额外的mount point信息的请求解析，这是否会给server端造成一定的压力？同时这部分会增加少许的latency，如果用户job频繁做这样的解析的话。
如果在job运行过程中更改server端的mapping关系，job的task可能会看到不一样的mount point关系，会造成后续的问题影响。

上述2点问题在实际场景可能问题没有那么的大，但是也是需要去注意和考虑的点。不过总的来看，ViewFs的支持hdfs schema方案在用户端调整这块还是能够带来很多改进之处的。