经常关注笔者博客的朋友们，一定看过笔者之前写过的关于HDFS对象存储（Ozone）系列的文章，并且笔者曾经预言这个功能很快将要发布在最新的Hadoop社区版本中。但是在合并此功能分支代码时，社区内部展开了很多讨论：包括内部全新的存储结构设计，以及新结构会对现有HDFS结构造成何种影响。那么有同学就好奇了，为什么一个局部的功能特性代码，合入社区就这么麻烦呢？但是笔者可要郑重其事的说：这可不是普通的小feature的代码，这是会对HDFS现有架构的调整打下地基的，它在里面引入了全新的存储层结构，为了解决的就是HDFS目前遇到的扩展性问题。
现有HDFS的扩展性问题一件事情，凡是有果必有因，这里的“因”就是现有HDFS的扩展性问题。这个想必熟悉HDFS的同学都非常清楚了，2大方面来讲：
Namespace层面：
- Namespace命名空间的扩展问题，直接表现出来的一点是NameNode的内存使用上升。
- 随着命名空间的规模扩增，引发的各种NameNode性能瓶颈问题，包括各种负载,RPC处理耗时等等问题。
- 集群（NameNode）启动时间，因为命名空间扩增，NameNode从FSImage镜像文件中加载的时间也会拉长，这可已经不是1,2分钟的事情了。
Block块层面：
- Block块汇报规模扩增。
- 随着Block块越来越多，DataNode内部对于Block块的管理问题。
鉴于上面分析的HDFS扩展性问题，社区在几年前提出了对象存储的概念，在对象存储的实现过程中引入了新的K-V式的元数据存储模式，旨在未来用此模式替换现有HDFS的元数据管理方式。最近社区将此新的存储结构命名为Hadoop分布式存储层：Hadoop Distributed Storage Layer (HDSL)。
Hadoop分布式存储层的引入Hadoop分布式存储层的引入，一个很重要的点是想未来基于其上构建一个新的HDFS。这里的分布式存储层就是笔者之前介绍过的Ozone里面的KSM，SCM这类的角色服务，感兴趣的读者朋友可以阅读笔者之前写过的一些关于HDFS Ozone系列的文章。鉴于以上的期望，HDFS-7240的名称从Object store in HDFS改为了Scaling HDFS。但是话说回来，仅仅完成一个分布式存储层就完事了嘛，答案显然不是。这里还涉及到如何将现有模式迁移至新的模式。社区提供了以下两种暂时的方法：
第一种，直接在Hadoop分布式存储层上构建新的NameNode（HDFS），这个有独立的JIRA进行跟踪，这里面会涉及现有INode元数据与分布式存储层数据之间的映射转换，细节内容可阅读HDFS-10419：Building HDFS on top of new storage layer (HDSL)。
第二种，提供一种K-V命名空间的文件系统，我们称之为Hadoop兼容文件系统（HCFS）API。提供这样的文件系统API有什么用呢？因为这个新的API写入的数据是存储于新的结构中的，但是它是兼容性文件系统API，可以提供给目前的Spark类的上层应用使用，这样的话，就可以将新的数据迁移到的新的存储结构中。然后，第二步，我们再其中构建新的HDFS结构，如方法一所做的操作。目前Hadoop兼容文件系统（HCFS）API在HDFS-13074：Ozone File System上跟踪实现。
一旦新的HDFS结构构建完成，将会解决目前遇到的NameNode很多性能瓶颈问题，比如NameNode全局锁问题以及前小节提到的一些问题。
参考资料[1]. https://issues.apache.org/jira/browse/HDFS-7240. Scaling HDFS
[2].https://issues.apache.org/jira/browse/HDFS-13074. Ozone File System
[3].https://issues.apache.org/jira/browse/HDFS-10419. Building HDFS on top of new storage layer (HDSL)
