自2006年诞生以来，Hadoop改变了企业对数据的存储、处理和分析的过程，形成了一个极其丰富的技术生态圈，并在经历了大数据技术高速发展之后，迎来了3.x的时代。本文将按照存储和计算两个方向，分别介绍Hadoop社区当前的热点话题及后续规划。本文整理自堵俊平、谭望达近日在Apache Hadoop技术社区中国Meetup上发表的演讲。

存储的三个演进方向

存储最主要是向三个方向演进：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出去。

演讲嘉宾介绍：
堵俊平，来自腾讯，在腾讯大数据负责海量存储和海量计算。之前是Apache Hadoop社区的Committer和PMC，同时也是Apache基金会的Member。
谭望达，来自Cloudera，负责计算平台，也是Hadoop社区的Committer和PMC。

创作场景

Hadoop 迎来 3.x 时代，昔日大数据霸主如何应对云计算挑战？