Scheme覆盖式的ViewFileSystem设计实现

前言

---

在多HDFS集群模式中，我们为了使得多集群对于client端的透明使用，一般可以采用的是ViewFs的方案。当然后来社区实现的HDFS RBF功能无疑是更佳的选择，但是在RBF出现，ViewFs实现的更早且方案更为简单，因此ViewFs是通过在client端实现的一个请求解析以及转发。但是本文我们来讨论一个ViewFs使用的痛点问题：ViewFs高成本的配置更新问题以及更为tricky的hdfs路径写死 metadata和应用程序里的问题。前者我们可以通过中心化统一viewfs配置的方式解决，而本文我们来主题聊聊后面这个难题。这里提到的写死hdfs路径在应用服务中的情况，它实质所要表达的意思是：如何在不改变现有程序中的路径的情况下，server端还是能够自动帮我重定向到新的target路径上去。本文笔者来聊聊目前社区对此的功能实现。

Scheme覆盖式的ViewFileSystem

---

我们再来用一个简单的例子来阐述下上面提到的例子。

我们现有以下写死的配置，路径指向关系如下：

hdfs://clusterA/a —> hdfs://clusterA/a
hdfs://clusterB/b —> hdfs://clusterB/b

现在我们突然有个临时需求，需要将写入到hdfs://clusterA/a的数据能够转向写到hdfs://clusterB/a上去。但是此时这些hdfs路径都是写死的，如果按照老HDFS FileSystem访问方式，它将还是按照地址直接访问clusterA集群的路径来的。

因此，在这里我们需要一个能够带有覆盖scheme方式的FileSystem，它的新映射关系如下：

hdfs://clusterA/a —> hdfs://clusterB/b
hdfs://clusterB/b —> hdfs://clusterB/b

这种模式我们可以扩展在现有的VIewFileSystem模式下，效果图如下所示：

如上图所示，scheme覆盖式的FileSystem叫做ViewFileSystemOverloadScheme。它和原来ViewFileSystem最大的区别是它可以在非viewfs scheme的路径((比如原始hdfs路径)下做到原来Viewfs的多路径mount table mapping的功能。这点带来的改进就可以很好的解决，那些hard-code hdfs路径导致访问地址无法更新的问题。

但是在ViewFileSystemOverloadScheme中，上面defaultFs路径写的hdfs://xxx，就不再指的是实际的DistributedFileSystem实例了，而是ViewFileSystemOverloadScheme。

OK，下面我们来进一步探讨ViewFileSystemOverloadScheme如何做到覆盖式scheme的处理的。

ViewFileSystemOverloadScheme的实现

---

使用ViewFileSystemOverloadScheme的第一步，先把defaultFs指向的fs.impl给替换掉。

替换规则如下

<property>
  <name>fs.<scheme>.impl</name>
  <value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value>
</property>

如果原有defaultFs的scheme是hdfs的话，则进行如下替换

<property>
  <name>fs.hdfs.impl</name>
  <value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value>
</property>

这样的话，程序在解析hdfs://xxx路径时就会总向ViewFileSystemOverloadScheme的逻辑。

对应代码逻辑如下，FileSystem类:

  private static FileSystem createFileSystem(URI uri, Configuration conf)
      throws IOException {
   
    Tracer tracer = FsTracer.get(conf);
    try(TraceScope scope = tracer.newScope("FileSystem#createFileSystem")) {
   
      scope.addKVAnnotation("scheme",