存储最主要是向三个方向演进：Scalability、Cloud、Machine Learning。
Scalability 主要是指 Hadoop 的分布式文件系统 HDFS 仍然有提高扩展性的需求和空间，后面会详细展开讲。Cloud 也是一个非常重要的方向，云上的对象存储甚至有取代 HDFS 成为云端大数据默认存储的趋势，所以 HDFS 如何与云端对象存储配合是一个重要的趋势。另一方面，随着机器学习 AI 的兴起，从数据存储的角度来看，这和传统大数据的存储方式很不一样，比如小的数据碎片会很多，这对 HDFS 带来了很多新场景和新挑战。
扩展性增强
先看 Scalability 的问题，我们先来回顾一下 HDFS 的架构。
如图所示，在 Master 节点也即 Namenode 这里主要有两部分工作：一是命名空间管理，另外一个是数据块管理。分工也很明确：前者负责维护文件路径到数据块 ID 的映射，后者负责从数据块 ID 到 Datanode 上数据块位置的映射。两个映射结合就可以从文件路径来定位到具体数据块存储的位置，便于对数据的访问。
这里有几个核心特点：
- Namenode 把所有的元数据信息存到内存中；
- 元数据信息的操作延迟是非常低的，便于快速响应元数据信息访问的需求；
- 它整体的架构和 I/O 模型是易于扩展到 PB 乃至上百 PB 级数据规模的。
这个架构的长处同时也是它的短处。设想当集群扩展至 4000 个节点以上时，并且存储超过 5 亿个文件时，所有元数据（命名空间、块管理等）要存放在 Namenode 的内存里，同时要考虑到同时并行的文件操作以及数据块上报、RPC 的响应等因素，这个时候就会遭遇扩展瓶颈。更不幸的是，如果集群存储的是海量小文件，这个瓶颈期会更快到来。
从上面可以看到，Namenode 很容易成为整个集群扩展性的瓶颈，所以很多优化都是围绕于此。首先看观察者 Namenode 这个特性。我们注意到超过一半的对 Namenode 访问属于读访问，而之前为了实现高可用性，HDFS 早已实现主备（active-standby）架构。如果读请求可以由之前基本闲置的 standby Namenode 来响应，就可以有效降低对主 Namenode 的压力。从社区报告的一些生产集群的应用实测可以发现，这个特性可以缓解主 Namenode 大约 20% 的压力。
其次来看一下 Namenode 联邦（Federation）这个特性。这个特性有两个版本：一个是早期的实现，通过把集群的所有节点划分成不同的子集群，子集群有独立的命名空间，用户 / 客户端需要显式的指定子集群的命名空间。这种方式的缺点很明显，即逻辑上所有数据无法采用统一的命名空间，也无法横跨多集群来做在平衡等。
另外一个是最近开发的基于路由的联邦（Router Based Federation，简称 RBF）特性。这个特性的设计思路是比较通用的方式，包括 YARN 也采用了类似的方案。基本设计理念是提供一个单独的联邦层，包含路由（Router）以及状态存储 (State Store) 两大模块。路由提供和 Namenode 一样的服务，只是所有的访问会通过路由进入相应的 HDFS 子集群，反馈相应的结果。而状态存储则会保存命名空间和子集群的映射关系，方便路由来跟踪记录并提供相应的服务。这种实现方式对客户端更友好，完全可以达到对客户端透明。
面向云的演化
对于 Hadoop 存储面向云的演化，主要是看 HDFS 如何跟云上的对象存储配合。
这里有四种不同的架构：如图所示，第一种架构是主体采用 HDFS，云的对象存储主要起备份和恢复的作用；第二种架构是输入在云对象存储，输出到 HDFS；第三种架构，输入输出都在云对象存储，HDFS 用来转储中间结果；最后一种，应用无需感知对象存储，由 HDFS 来负责数据在对象存储里的写入与加载。我们认为最后一种是比较理想的一种情况，因为线下运行良好的大数据应用无需任何修改即可迁移至云端。
针对第四种架构，HDFS 社区开发了对象存储挂载这个特性。
如图所示，在 HDFS 的命名空间的任何位置都可以设置挂载点来挂载远程的命名空间，标识成 PROVIDED 层次。HDFS 会通过 StoragePolicy 来管理数据在不同层次之间的移转。
机器学习
针对云和机器学习场景，Hadoop 社区开发了 OZone 项目。这个前景远大的产品有很多特点，包括：无限的扩展能力，强一致性的对象存储能力，与主流计算调度框架 YARN 和 Kubernetes 无缝对接，以及同时兼容对象存储与 HDFS API 等。目前 Ozone 还处于 Alpha 阶段，下一个 Release 也就是 0.5 Release 是 Beta 版本。在 Ozone 项目上，腾讯的工程师也做出了很多的贡献，比如像 Topology Awareness（拓扑感知）、性能优化等等。
除了刚才提到的大的场景突破，还有一些持续不断的改进和优化，也列在这里，包括：对于非易失性存储的支持，对新的 trace 框架 -opentracing 的支持，以及扩展性压力测试工具 Dynamometer 等等。
计算的新功能
下面重点介绍关于计算部分（Compute）的更新，主要包括 YARN 和 Submarine。未来，计算资源会越来越多容器化。以前容器化主要是被 DevOps 和微服务所使用，最近随着大数据应用的依赖越来越复杂，我们也需要用容器化做更好的依赖管理和资源隔离。
下面是一些重点的计算方面新的功能。
第一个功能是 YARN-5139 Global Scheduling Framework。这是在 3.0.0 里加入的功能，它可以每次看多个节点，里面加入了一些 Ability 优化，就算只有一个 Thread 情况下都可以跑得比较快。另外它加入了多个 allocation threads，可以在并行状态下进行 allocate。经过一些模拟测试可以看到很多场景下达到 5-10 倍的 allocation throughput，现在到每秒钟 3000、4000 个 Container 的 allocation 是比较正常通过测试的数值。当然，实际可能会有些出入，如果有更精确的数字，希望大家在社区里跟我们沟通。
对于 Containerization，下面是相关的 Improvement。第一个是在 3.1.0 里已经说 Docker container 是 Ready for production；3.2 和 3.3 也有很多功能和稳定化的东西。3.3 第一个功能是支持 Interactive Docker Shell，用户可以登陆到你的 Docker container 里 Run 一些命令，不用去 SSH 到对应的节点，这样比较方便调试。第二块是 OCI/squashfs（Like runc）的支持。这边的趋势是大家很多不希望用 Docker container，希望用其他的 runtime。OCI 和 Squashfs 是对应的标准，社区在比较积极的推进。大部分 Test 都已经有 Patch，应该可以在 3.3 里出现。第三块是 Docker image localization 和相关的 Improvement。以前 YARN 破 Image 时不太清楚知道到底铺了多少。这块可以帮助用户了解当 Docker image 比较大时到底进度是怎么样的。
在 YARN+Cloud 的环境下，也有一些对应的改进。这部分改进目前还在不断进行中，希望大家多提提需求，看看对应的场景是什么。第一块是 Auto scaling，在云上做扩容、缩容的工作；第二块是做更好的 Scheduling，比如把 Container 能 pack 到尽量小的漏斗。第三块，比如 Spot instances，当出现一些 Spot instances 时怎么做 allocation，保证尽量少对好的 Job 带来影响。云上经常会出现有些时候漏斗突然不可用的情况，相对私有的数据中心来讲，这条相对更容易出现。这块也要知道怎么更好的做 Decommissioning，还有就是对于 Services data 的处理。
这块场景下大家如果有什么想法或者在云上已经有了一些工作，可以到 YARN-9548 上评论。
机器学习这块的工作主要是 Submarine。Submarine 是 3.2.0 第一次加入到 Hadoop 里作为 YARN 的子项目。在今年早些时间，我们把它剥离成在 Hadoop 下的子项目，跟 YARN 和 HDFS 是平级的。之后我们也做了一个 Release0.2.0，0.3.0 里还有很多新的东西。
下图是社区的 Release Plan：
先回顾一下 2018 年的 Release。2018 年做了 2.6、2.7、2.8 的 Maintenance Release，2.9 是一个新的 Release，做了关于 YARN Federation 和 Optimistic Container，这两块都是由微软去做的。3.0 加入了 EC、全局调度器、Resource types、Timeline V2，3.1 加入了 GPU/FPGA、YARN Service、Placement Constraint 可以做一些相关工作。
2019 年到目前为止做了两个 Release。3.1.2 是一个 Stabilization Release，3.2 加入了 Node Attribute，可以去 Tach，Node 可以在调度时做相应调度，也加入了 Submarine、HDFS 的 SPS，云的 Connector 上也有一些比较大的 Improvement。
今年剩下的四个月准备多做几个 Release。第一个是 2.8.6 社区，很希望能做一些 Maintenance Patch，3.1.3 和 3.2.1 也准备做两个 Maintenaece Release，刚刚介绍的很多关于 HDFS 和 Hadoop 社区的一些工作，像 Federation、Opentracing，这块大部分功能都准备放到 3.3 里，还有刚刚提到的一些关于 Docker container 等等功能。现在在 3.3 里的 Patch 已经有 1000 多个，整个 Hadoop 社区都在全力准备尽早把这个版本 Release 出去。
