Hadoop ViewFs允许hdfs schema的重载

前言

---

在大数据时代，随着业务的迅速扩张，很多大公司往往内部会有多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方式