Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >腾讯大数据之新一代资源管理与调度平台

腾讯大数据之新一代资源管理与调度平台

作者头像
腾讯大数据
发布于 2018-01-26 10:06:05
发布于 2018-01-26 10:06:05
3.4K0
举报

云计算大数据经常意味着需要调动数据中心大量的资源,如何能够快速的匹配合适资源,需要一个聪明的“大脑”。数据平台部的TDW,是腾讯自主研发,支持百PB级的数据存储和计算,提供海量、高效、稳定的大数据平台支撑和决策支持,成为腾讯大数据处理的核心平台。更大规模的集群,更多新的分布式编程框架,更多不同的业务场景,都给这个大脑提出了挑战。

同时,我们也在思考一个并非只为TDW服务的通用资源管理系统。这些价值正是Google Borg十余年来作为secret weapon提供的强大能力,也是Mesos、Corona、Yarn都想追随Borg脚步的原因。

 图1. 腾讯数据平台整体架构
图1. 腾讯数据平台整体架构

大数据领域开源技术林立,Hadoop又在持续升温,开源已经悄悄在主宰世界。流行的资源系统的开源项目主要有Yarn、Corona以及Mesos,我们考虑到目前与公司项目的结合度以及未来的趋势,把结论落在了Yarn上。

业务支持上,它可以兼容tdw原来的MR、hive等任务,对于storm、spark等,Yarn也可以有较好支持;从Yarn自身看,虽然它出现最晚,目前也最不成熟,但是它的可扩展性的架构优势以及良好的兼容性,Container的资源管理方式等,都代表了未来资源管理系统的趋势;最后从社区的活跃度以及生态圈看,不但有MR On Yarn、Storm On Yarn,Hive On Yarn,Hbase On Yarn,而比较新兴的samza、spark等,也都在“On Yarn”。Corona和Mesos主要是facebook和twitter在使用,并且他们也同时使用Hadoop集群,这两个开源项目社区都远远不如Hadoop社区活跃,影响力也差很多。基于这些现实情况,我们最终选择了目前并不是很完善的Yarn。

然而,如前所述,Yarn还非常不完善。尤其是在腾讯的场景下,集群规模更大,作业并发度更高,业务场景更多,把开源Yarn直接拿过来使用,显然是不够的。因此,我们依托做过自研集群资源管理和调度系统的优势,开发了自研的调度器sfair,提升Yarn的调度能力以及集群的可扩展性,同时,在资源管理方面,优化了Yarn的内存资源管理,增加了网络带宽等维度的管理。因此,我们的集群资源管理和调度系统又不仅仅是Yarn。

Gaia(盖娅):希腊神话中的大地之神,是众神之母,所有神灵中最德高望重的显赫之神。Gaia以后可以承载各种编程框架、各种应用,是个统一的资源管理调度系统——各种业务都植根于“大地”之上。

我们为Gaia确立的项目目标是:打造腾讯的自研资源管理平台,提供高并发任务调度和资源管理,实现集群资源共享,提升可伸缩性和可靠性,不仅可以为MR等离线业务提供服务,还可以支持实时计算,甚至在线service业务。

  图2. Applications on Gaia
图2. Applications on Gaia

Gaia的系统目标 Yarn的官方主页上说“Yarn as Cluster Operating System”,在这一点上,Gaia和Yarn完全一致,目标都是实现一个通用的资源管理和调度平台,作为集群操作系统服务于上层各类应用。系统目标如下:

1.可扩展性 更大规模的集群意味着可以支持更大规模的应用,更大的并发度以及对底层资源更好的共享。而将Hadoop1.0 中的JobTracker扩展到4000个节点规模的集群被证明是极端困难的。新一代计算平台应该可以平滑地扩展至数万节点以及并发的应用,这就需要在架构上对系统做根本的调整。

2.可维护性 Gaia系统本身需要维护,会经常的进行版本升级,以及进行bug fix,需要保证Gaia系统自身的升级与用户应用程序完全解耦。

3.支持多租户 Gaia需要支持在同一个集群中多个租户并存,同时支持在多个租户之间细粒度的共享节点。

4.位置感知 Locality的特性可以大大减少数据移动,减少计算等待的时间,并且可以节省带宽资源。因此,Gaia应该支持位置感知——将计算移动到数据所在的位置。

5.高集群使用率 不管是从成本,还是提升并发度等方面来说,Gaia都需要实现底层物理资源的高使用率。在Gaia中,我们可以通过资源共享、业务错峰、buffer共享、资源类型互补等多种方式来提升集群的资源使用率,进而节省成本。

6.安全和可审计的操作 Gaia应该以安全的并且可审计的方式使用集群资源。 我们试图避免使用特权用户(比如root)运行NodeManager,以此来解决这个问题。NodeManager可以代表用户执行很多操作,使用特权用户运行会暴露出很多容易遭攻击的地方。任务使用的目录和文件同样需要合适的权限。很多目录和文件是NodeManager创建的,但是会被任务使用。少数是由用户代码写入但是被守护进程使用或者访问。基于安全的考量,权限的设置需要非常严格,只能被用户或者NodeManager读/写。

用户可以向一个或更多的集群提交作业,但他必须在作业提交之前通过Kerberos或者授权机制进行认证。用户在作业提交之后可以中断连接,然后通过同一认证机制重新连接获得作业状态。

需要一个机制来控制谁能向一个指定的队列提交作业。只有在用户被授权时,作业才被允许提交到这些队列。为此,管理员在集群初始化之前设置了Queue ACL。管理员可以在运行时动态地改变队列的ACL,从而允许一个用户或者一个组访问它。被称为集群管理员和队列管理员的特定的用户和组,可以管理队列的ACL,也可以访问或者修改队列中的任何作业。

7.可靠性和可用性 共享集群提升了利用率和本地化,它也使对可靠性和可用性的担忧成为大家关注的焦点。ResourceManager的失效会引发的中断,不仅仅是丢失单独的一个工作流,而是会丢失集群中所有的运行作业,并且要求用户手动重新提交并恢复他们的工作流。运营一个大规模、多租户的Hadoop集群并非易事的。容错性是一个核心设计原则。

8.对编程模型多样性的支持 虽然MapReduce的支持范围广泛的用例,它并不适用于所有大型计算的理想模式。例如,很多机器学习程序需要在同一数据集上的多次迭代来收敛得到结果。如果将这个流程使用一系列的MapReduce实现,调度的开销会导致结果的显著延迟。类似地,与使用在可容错的大规模MapReduce作业中很重的多对多通信相比,很多图形算法是使用整体同步并行计算模型(BSP),在边之间传递消息,会获得更好的表现。这种不匹配成为用户工作效率的一个阻碍,但是Hadoop中这种以MapReduce为中心的设计不允许使用其他编程模型。

9.灵活的资源模型 除了与新兴框架需求不匹配之外,Hadoop1.0上带类型的slot也伤害了利用率。在单个节点上(以至整个集群)map和reduce的隔离防止了跨任务类型的死锁,但是它也造成了资源瓶颈。 用户为每一个提交的作业对map和reduce的重叠情况进行了配置。较晚启动reduce任务可以增加集群的吞吐量,而在作业的执行中,较早启动它们可以降低延迟。Map和reduce的slot数量是由集群管理员配置的固定值,因此闲置的map资源无法启动reduce任务,反之亦然。因为这两种类型的任务可能(并且通常是)在不同的速率下完成,没有配置是永远完美的。当任何一种类型的slot被用尽时,尽管另一种类型还有可用的slot,但是JobTracker被迫对作业初始化施加压力。单个节点上资源的非静态定义使调度更加复杂,但是它也使得调度器可以更好的管理集群。 因此新的计算平台应该支持各个节点的动态资源配置以及灵活的资源模型。

Gaia系统架构 1. Hadoop 1.0架构 Hadoop1.0的架构中,主要有两个组成部分,分别是JobTracker和TaskTracker。 JobTracker负责worker节点(TaskTracker)的资源管理,跟踪资源使用率,管理作业的生命周期,如调度作业的各个任务,跟踪进度,以及为任务提供容灾服务。

TaskTracker的职责比较简单——根据JobTracker的命令启动/清除任务,并且周期性地向JobTracker提供任务的状态信息。

图3. Hadoop1.0 v.s. 2.0架构
图3. Hadoop1.0 v.s. 2.0架构

2.Yarn的项目背景 Apache Hadoop MapReduce是当下最流行的开源MapReduce模型,但是2.0重写代码的勇气来自于哪里?是否真的有必要全部重构。本节主要讲下Yarn的背景。 按照我个人的理解,把Yarn的项目背景总结为下面两个主要方面:

解决Hadoop 1.0中已知的太多问题 首先承认,Hadoop 1.0是一个非常优秀非常成功的开源系统,但也逐渐的暴露了太多的问题,这里主要说明几个与资源管理调度相关的问题。

1)可靠性 作为底层系统,可靠性至为重要,但是Jobtracker确是hadoop中的单点,对生产环境中的业务是一个致命伤,这也是很多公司对hadoop做的第一个改造。 2)可扩展性 云计算常常伴随的是大数据,随着业务规模的扩大,hadoop集群的可扩展性问题越来越凸显,而在原来的架构下,hadoop 1.0的单cluster集群上限的官方数字是3000(yahoo),但是实际中已经有很多公司需要达到万台规模。 3)兼容性 Hadoop 1.0的兼容性经常被用户诟病,不同版本的Hadoop的不兼容,严重影响了用户的升级积极性。 4)资源使用率 Hadoop1.0以slot管理资源,而不是按照作业的使用资源需求,造成了很大的资源浪费,在资源使用率上是一大损失。

支持非Mapreduce的计算框架 3. Yarn架构 YARN的基本思想是将JobTracker的两大主要职能:资源管理、作业的调度/监控拆分为两个独立的进程:一个全局的ResourceManager和与每个application对应的ApplicationMaster(AM)。ResourceManager和每个节点上的NodeManager(NM)组成了全新的通用操作系统,以分布式的方式管理应用程序。

ResourceManager拥有为系统中所有应用的资源分配的决定权。对应于每个application的ApplicationMaster是框架相关的,负责与ResourceManager协商资源,以及与NodeManager协同工作来执行和监控各个任务。

ResourceManager有一个可插拔的调度器组件——scheduler,负责为运行中的各种应用分配资源,分配时会受到容量,队列及其他因素的制约。Scheduler是一个纯粹的调度器,不负责application的监控和状态跟踪,也不保证在application失败或者硬件失败的情况下对task的重启。Scheduler基于application的资源需求来执行其调度功能,使用了叫做资源 container的抽象概念,其中包括了多种资源维度,如内存,CPU,磁盘,以及网络。

NodeManager是与每台机器对应的slave进程,负责启动application的container,监控它们的资源使用情况(CPU,内存,磁盘和网络),并且报告给ResourceManager。

每个application的ApplicationMaster负责与Scheduler协商合适的container,跟踪application的状态,以及监控它们的进度。从系统的角度讲,ApplicationMaster也是以一个普通container的身份运行。

 图4. Yarn架构
图4. Yarn架构

Gaia对Yarn的扩展 1. 自研高性能调度器sfair Yarn调度器主要分为三个阶段:

1)选择一个队列:递归的对子队列进行排序,找到第一个可以assign的队列,从而找到叶子队列;

2)选择一个app:对本队列的所有app进行排序,然后遍历这些app,找到可以assign的那个app;

3)执行matchmaking。

图5. scheduler
图5. scheduler

Gaia今年内的目标是,支持单cluster 8800节点的规模,而Yarn原生的调度器显然不满足要求,为此,我们开发了自研的调度器sfair(scalable fair scheduler),主要着力于提升可扩展性。在开发sfair调度器的过程中,我们通过减少sort次数、优化comparator、控制多线程的同步,以及仔细的profiling,找到关键路径。目前已经上线,并且大幅度的提升了调度吞吐,支持毫秒级的下发。同时,优化了作业优先级和抢占的策略,使调度更加公平。

具体的优化手段及内容,将在后续文章中详细介绍。

2. 更高要求的HA 目前,Yarn上的主流应用还是离线的MapReduce居多,也就是Yarn的第一个目标,兼容旧的Hadoop 1.0中的主要应用。而在腾讯的场景下,业务种类更加多样,规模也更大,尤其是我们要支持实时计算、service服务等类型的应用,对作为底层系统的Gaia能够提供的HA机制要求显然就要更高。

根据作业执行的各个环节,Gaia需要以下三个方面的HA: 1)NM HA; 2)RM HA; 3)AM HA 其中,NM的lost是Yarn可以自动发现和处理的。但是我们仍然可以进一步优化,比如在升级NM的时候,可以采用ISSU的机制,保证NM重启的过程中,上层的container不受到影响。

对于RM HA,社区的最新版本已经做了一部分工作,但是还远远不够,我们希望做到RM的fail对用户应用程序完全无感知。对于AM类似,2.2版本,Yarn的一个AM fail时,整个AppAttempt都会失败,所有对应的container将会被回收,代价非常高的。我们结合设计最新的版本思路,正在开发AM retain的特性,期待和上层应用结合,一起解决这个问题。

 图6. Gaia HA需求
图6. Gaia HA需求

3. 资源管理 即使是最新的社区版本,也仅仅实现了cpu和memory的管理。Gaia在资源管理方面,积累了较多的经验。我们的计划是,一方面优化现有的资源管理机制,一方面增加资源管理维度。

现有版本的YARN通过Cgroups对CPU资源进行分配,通过启动监控线程对内存进行监控。通过Cgroups可以保证container使用的最小CPU占用率,可以满足我们的需要。而对内存的监控有如下问题: (1)监控线程定时运行,不能达到实时监控的目的,很可能出现OOM现象而未检测到或造成严重后果。 (2)目前监控机制属于hardlimit,当系统有充足资源时杀掉超出使用内存的container并不是很合理的解决方式。 (3)无法充分利用整机资源,也就是说,container如果没有用到资源声明的资源需求,这部分内存资源就浪费掉了,不能share给其他所需要的container。

为此,我们引入了EMC(Elastic Memory Control)弹性内存管理机制,解决了上述问题,具体机制也请期待我们后续的文章。 在资源管理维度方面,我们正在开发Network IO控制,后续还将引入disk IO、disk space的控制。建立起一个全方位的资源管控网,使各种物理资源全部在Gaia的统一掌控下。

4. 丰富Gaia用户api Yarn已经提供了很多基本的用户api,但是在实际应用中,我们发现,还远远不足,比如MR的开发同事就已经发现了某些场景下,MR内部的抢占无法很好的实施。对于service 作业,对灰度升级的支持也不是很好,有些甚至不必“劳烦”底层Gaia的调度,现在还不得不走调度的overhead。为此,我们会增加Reload/Update Container等接口。

5. 建立“on Gaia”生态圈 Gaia要支持storm、spark,甚至是腾讯的一些其他的service服务进程,并且spark、storm等应用都会上一定的规模,社区的xxx on yarn,有很多还属于“玩具”性质,无法满足业务生产环境的运营需求,为此,Gaia将会配合应用的需求,深入了解各种应用,与数据平台部的同事们一道,建立和完善Gaia应用生态圈。反过来,这些应用发现的很多问题,对Gaia的各种需求,也会反作用于底层系统,帮助底层的Gaia更加完善。

6. 多维运营 除了开发,对集群管理系统的运营也极其重要。我们扩充了很多metric,并且增加了多维度的报表,诊断系统、以及细化告警、辅助debug等方面,这里要特别感谢运维同事。将我们的系统真正运转起来。不但有对系统的监控和运营,在应用级别也有各种监控,常常可以发现很多系统级监控无法发现的问题,也可以提前帮助业务发现并端决问题。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2015-07-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯大数据 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
进击大数据系列(五):Hadoop 统一资源管理和调度平台 YARN
Apache Yarn(Yet Another Resource Negotiator的缩写)是hadoop集群资源管理器系统,Yarn从hadoop 2引入,最初是为了改善MapReduce的实现,但是它具有通用性,同样执行其他分布式计算模式。
民工哥
2023/08/22
1.3K0
进击大数据系列(五):Hadoop 统一资源管理和调度平台 YARN
Yarn资源调度过程详细
在MapReduce1.0中,我们都知道也存在和HDFS一样的单点故障问题,主要是JobTracker既负责资源管理,又负责任务分配。
Tim在路上
2020/08/05
1.6K0
hadoop集群老的资源管理Mrv1与Yarn资源管理器的工作流程和对比
2、JobTracker负担重,既要负责资源管理,又要进行作业调度;当需处理太多任务时,会造成过多的资源消耗。
全栈程序员站长
2022/08/09
1K0
hadoop集群老的资源管理Mrv1与Yarn资源管理器的工作流程和对比
大数据干货系列(三)-Hadoop2.0总结
本文共计810字,预计阅读时长五分钟 Hadoop2.0总结 一、本质 Hadoop2.0,相比于Hadoop1.0,最明显的区别是YARN系统和HDFS2.0的新特性 二、Yarn解决了什么问题 1.降低运维成本和数据共享成本 2.减小了JobTracker(也就是现在的RM)的负担 3.使得多种计算框架可以运行在一个集群中 4.资源表示成内存量,解决了之前的map slot/reduce slot分开造成集群资源闲置的情况 三、HDFS2.0解决了什么问题 1.NameNode HA解决了Hadoo
企鹅号小编
2018/02/05
7540
大数据干货系列(三)-Hadoop2.0总结
资源管理与调度系统YARN
YARN作为一个通用的资源管理系统,目标是将短作业和长服务混合部署到一个集群中,并为他们提供统一的资源管理和调度功能,概括起来主要解决以下两个问题:1.提高集群资源利用率,2.服务自动化部署。
凹谷
2020/04/11
1.3K0
深入浅出学大数据(五)Hadoop再探讨High Availability(HA)集群搭建及YARN原理介绍
此系列主要为我的学弟学妹们所创作,在某些方面可能偏基础。如果读者感觉较为简单,还望见谅!如果文中出现错误,欢迎指正~ 本文主要介绍了Hadoop再探讨High Availability(HA)及YARN原理介绍,除此之外还有High Availability(HA)集群搭建的具体搭建过程。
不温卜火
2021/11/24
1.4K0
深入浅出学大数据(五)Hadoop再探讨High Availability(HA)集群搭建及YARN原理介绍
Hadoop MapReduce新一代架构MRv2
MapReduce在hadoop-0.23中经历了彻底的改变,现在我们称之为MapReduce 2.0(MRv2)或者YARN。
smartsi
2019/08/07
7120
浅谈yarn的任务管理与资源管理
YARN(Yet Another Resource Negotiator)是Hadoop 2.x的一个计算框架,旨在解决Hadoop 1.x中的资源管理和任务调度问题。它的主要目的是将MR1 JobTracker 的两个主要功能(资源管理和作业调度/监控)分离,以便更好地支持多种应用程序,而不是仅支持MapReduce。
没有故事的陈师傅
2023/12/19
1K0
浅谈yarn的任务管理与资源管理
从Hadoop1.0到Hadoop2.0架构的优化和发展探索详解
Hadoop1.0即第一代Hadoop,由分布式存储系统HDFS和分布式计算框架MapReduce组成,其中HDFS由一个NameNode和多个DateNode组成,MapReduce由一个JobTracker和多个TaskTracker组成。
fanstuck
2024/11/05
2.7K2
从Hadoop1.0到Hadoop2.0架构的优化和发展探索详解
大数据入门:Hadoop Yarn组件基础解析
在Hadoop框架当中,Yarn组件是在Hadoop2.0之后的版本开始引入,主要是为了解决资源管理和调度的相关问题,是在大数据平台的实际运用当中,根据实际需求而引入的解决方案。今天的大数据入门分享,我们就来对Hadoop Yarn组件做个简单的基础解析。
成都加米谷大数据
2020/11/26
1.1K0
大数据入门:Hadoop Yarn组件基础解析
Hadoop基础教程-第5章 YARN:资源调度平台(5.1 YARN介绍)
YARN的全称是Yet Another Resource Negotiator,意为另一种资源调度者。 从Apache Hadoop 2.0开始, Hadoop包含 YARN。
程裕强
2022/05/06
5980
Hadoop基础教程-第5章 YARN:资源调度平台(5.1 YARN介绍)
分布式资源调度框架YARN
如图所示,1.x的架构也采用的是主从结构:即master-slaves架构,一个JobTracker带多个TaskTracker
超哥的杂货铺
2019/12/18
1.3K0
分布式资源调度框架YARN
Hadoop - YARN Introduce
ResourceManager(RM)是一个全局的资源管理器,负责整个系统的资源管理和分配,主要包括两个组件,即调度器(Scheduler)和应用程序管理器(Applications Manager)。
mantou
2019/08/20
7510
Hadoop - YARN Introduce
【Hadoop研究】YARN:下一代 Hadoop计算平台
Apache Hadoop 是最流行的大数据处理工具之一。它多年来被许多公司成功部署在生产中。尽管 Hadoop 被视为可靠的、可扩展的、富有成本效益的解决方案,但大型开发人员社区仍在不断改进它。最终,2.0 版提供了多项革命性功能,其中包括 Yet Another Resource Negotiator (YARN)、HDFS Federation 和一个高度可用的 NameNode,它使得 Hadoop 集群更加高效、强大和可靠。在本文中,将对 YARN 与 Hadoop 中的分布式处理层的以前版本进行
陆勤_数据人网
2018/02/27
1.2K0
【Hadoop研究】YARN:下一代 Hadoop计算平台
京东万台规模Hadoop集群 | 分布式资源管理与作业调度
吴怡燃, 京东大数据平台高级技术专家,擅长大数据平台的资源管理与调度系统的开发与建设。目前专注于以万台分布式调度系统及深度学习平台的开发与建设。
京东技术
2018/07/30
1.6K0
京东万台规模Hadoop集群 | 分布式资源管理与作业调度
Yarn框架深入理解【Yarn集群配置】
我们都知道Hadoop诞生的目标是为了支持十几台机器的搜索服务,但是随着数据的增加,数据的可用性也是一个待解决的问题。但是Hadoop框架的自身问题限制了集群的发展。
Java架构师必看
2021/05/14
3.2K0
Yarn框架深入理解【Yarn集群配置】
大数据面试杀招——Hadoop高频考点,正在刷新你的认知!
上一篇文章为大家总结了一些关于Hive的热门考点,得到了一些朋友的肯定与转发,菌菌就觉得花时间去做这些知识整合是非常有价值,有意义的一件事。本篇文章,让我们有幸一起来阅读一下,该怎么准备Hadoop的内容,才有机会在面试过程占据上风。
大数据梦想家
2021/01/27
7470
大数据面试杀招——Hadoop高频考点,正在刷新你的认知!
大数据知识总结(三):Hadoop之Yarn重点架构原理
Apache Hadoop Yarn(Yet Another Reasource Negotiator,另一种资源协调者)是Hadoop2.x版本后使用的资源管理器,可以为上层应用提供统一的资源管理平台。
Lansonli
2025/05/24
1110
MapReduce
· 资源与计算强耦合,其他计算框架需要重复实现资源管理,例如如果用spark也要进行调用,不知道哪个是被MapReduce调用的
李才哥
2021/03/04
9010
MapReduce
Hadoop Yarn初探
前言 经过多年的发展形成了Hadoop1.X生态系统,其结构如下图所示: 其mapReduce的结构如下: 从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路:
用户1665735
2018/06/20
1.2K0
推荐阅读
相关推荐
进击大数据系列(五):Hadoop 统一资源管理和调度平台 YARN
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档