前言
在大数据时代,随着业务的迅速扩张,很多大公司往往内部会有多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内的地址还是不好去更新