炼数成金 门户 大数据 网络技术 查看内容

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

2019-8-26 17:30| 发布者: 炼数成金_小数| 查看: 18919| 评论: 0|原作者: 堵俊平、谭望达|来自: AI前线

摘要: Scalability 主要是指 Hadoop 的分布式文件系统 HDFS 仍然有提高扩展性的需求和空间,后面会详细展开讲。Cloud 也是一个非常重要的方向,云上的对象存储甚至有取代 HDFS 成为云端大数据默认存储的趋势,所以 HDFS 如 ...

存储 Hadoop 架构 集群 Docker

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

声明:本文版权归原作者所有,文章收集于网络,为传播信息而发,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花
1

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2019-9-24 04:40 , Processed in 0.179251 second(s), 25 queries .