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

自 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 大数据技术

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。