在传统的Apache Hadoop集群系统中，计算和存储资源是紧密耦合的，HDFS为大数据存储带来便利的同时，也面临着一些挑战：

当存储空间或计算资源不足时，只能同时对两者进行扩容。假设用户对存储资源的需求远大于对计算资源的需求，那么同时扩容计算和存储后，新扩容的计算资源就被浪费了，反之，存储资源被浪费。

这导致扩容的经济效率较低，额外增加成本。而独立扩展的计算和存储则更加灵活，同时可显著降低成本。

现在Hadoop采用存算分离的架构的趋势越来越明显。

XSKY HDFS Client是为XEOS存储集群和Hadoop计算集群量身打造的连接器。通过XSKY HDFS Client，Hadoop应用可以访问存储在XEOS中的所有数据。

但是，在引入XEOS存储后，会出现原有HDFS与XEOS共存的情况，如何将两套存储集群都利用起来是需要解决的问题。

1

数据跨集群拷贝

一般情况下，计算应用需要访问的数据，如果保存在不同的集群中，那么应该将其中一个集群的数据拷贝到另一个集群上。一般情况下使用Hadoop自带的DistCp工具，对数据进行跨集群的拷贝。

这种方式虽然在一定程度上可以解决数据合并的问题，但如果数据量比较大，并且机房带宽有限制的情况下，可能拷贝数据的时间会非常长。还有一个就是在拷贝过程中原始数据发生改动，就还需要考虑增量同步的问题。

2

联邦HDFS和ViewFS

在Hadoop 2.x发行版中引入了联邦HDFS功能，期望可以解决NameNode的内存问题。联邦HDFS允许系统通过添加多个NameNode来实现扩展，其中每个NameNode管理文件系统命名空间中的一部分。

但是，在实际应用中，系统管理员需要维护多个NameNodes（所有NameNode都需要高可用）和负载均衡服务，这又增加了管理成本。所以HDFS的联邦方案并没有被生产环境所采用。

在提供联邦HDFS方案同时，Hadoop 2.x还提供了ViewFS，用来管理所有多个命名空间视图。

虽然联邦HDFS方案并没有被大规模应用，但ViewFS却可以用来解决XEOS与HDFS共存问题。

03

ViewFS的实现

ViewFS全称是ViewFileSystem，它不是一个新的文件系统，只是逻辑上的一个视图文件系统，它实现了标准的Hadoop FileSystem接口。但是，真实的请求处理还是在各自真实的存储集群上。

ViewFS会维护一个mount-table，主要是viewfs的逻辑目录与实际底层存储的映射关系。在接收到应用的调用时，ViewFS会解析用户的访问请求，并通过mount-table找到对应的底层存储目录，转发相应的请求到底层存储。

ViewFS会把所有应用层的FileSystem调用透传到底层真实文件系统中。由于ViewFs实现了Hadoop文件系统接口，因此使用它透明地运行Hadoop工具。例如，所有shell命令都可以与HDFS和本地文件系统一起使用ViewFS。

在集群的core-site配置中，fs.defaultFS被设置为ViewFS的root目录，也就是指定的mount-table。

在集群的配置中增加ViewFS的mount-table配置，示例如下：

Hadoop系统将在Hadoop配置文件中查找名称为 “ClusterX” 的mount-table。将所有gateway和server配置包含“ClusterX”，如上示例。

4

ViewFS的应用场景

ViewFS可以在如下场景中使用：

非结构化的原始数据可以通过DistCp等工具直接存储在XEOS上，业务数据库结构化数据和应用买点数据可以通过ETL以Hive的外部表方式存储到XEOS中。HBase和Hive继续在原有的HDFS上面运行，也就是HBase表数据和Hive内部表数据仍然通过HDFS来存储。

这样的好处是海量非结构化数据，甚至是海量小文件都可以用XEOS来承载，减轻HBase的压力，同时Hive新增数据全部通过XEOS来存储，后续扩容容量仅扩展XEOS存储集群即可。

5

XEOS配置ViewFS

大数据平台基于CDH 6.3.2。HDFS core-site.xml 增加如下配置：

Hadoop FS命令行：

执行wordcount测试结果如下：

6

小结

XSKY通过ViewFS的方式，在不改变用户使用习惯的前提下，将原有HDFS数据与新增XEOS数据打通，解决了原有HDFS集群与新XEOS集群的共存问题。原有的HDFS数据可以继续使用，而XEOS可以用于承载新生成的数据。

这种方式不仅可以充分利用旧有设备，达到节约成本的目的。同时，能够借助XEOS横向扩展能力，实现存储单独扩容。