1.Yarn的概述
1.1.解释Yarn的定义和基本概念
Hadoop YARN(Yet Another Resource Negotiator)是 Hadoop 2.x 版本引入的一种资源管理器,用于管理和调度大数据集群中的资源,是 Hadoop 集群的核心组件之一。YARN 的设计目标是提高 Hadoop 的资源利用率、灵活性和可伸缩性,使其能够处理更加复杂和多样化的工作负载。
1.2.概述 YARN 的起源和发展历程
**起源:**在 Hadoop 1.x 版本中,资源管理和作业调度功能都由 JobTracker 负责,这种集中式的架构存在一些缺点,如扩展性差、单点故障等。因此,Google 发布的 MapReduce 论文以及大数据领域的发展需要促使了 Hadoop 社区寻求一种更灵活、更可扩展的资源管理框架。
**发展历程:** 2012 年,Hadoop 2.x 版本正式发布,其中包含了 YARN 的实现。YARN 的引入为 Hadoop 提供了一个全新的资源管理和作业调度框架,使得 Hadoop 集群可以同时运行多个计算框架(如 MapReduce、Spark、Flink 等),并能够更灵活地处理不同类型的工作负载。
2.Yarn架构解析
2.1.详细介绍Yarn的体系结构和组件
YARN 的基本思想是将资源管理和作业调度/监控的功能拆分为单独的守护进程。这个想法是拥有一个全局 ResourceManager (RM) 和每个应用程序的 ApplicationMaster (AM)。应用程序可以是单个作业,也可以是作业的 DAG。
ResourceManager 和 NodeManager 构成了数据计算框架。ResourceManager 是在系统中的所有应用程序之间仲裁资源的最终权威机构。NodeManager 是负责容器的每机框架代理,监视其资源使用情况(cpu、内存、磁盘、网络),并将其报告给 ResourceManager/Scheduler。
实际上,每个应用程序的 ApplicationMaster 是一个特定于框架的库,其任务是从 ResourceManager 协商资源,并与 NodeManager 合作来执行和监视任务。
2.2.解析ResourceManager、NodeManager、ApplicationMaster 等关键组件的作用和职责
2.2.1.ResourceManager
ResourceManager有两个主要组件:Scheduler和ApplicationsManager。
2.2.1.1.Scheduler(调度程序):
** Scheduler复制将资源分配给各种正在运行的应用程序,这些应用程序受到熟悉的容量,队列等限制.调度程序是纯调度程序**,因为它不对应用程序的状态执行监视或跟踪。此外,它不保证由于应用程序故障或硬件故障而重新启动失败的任务。调度程序根据应用程序的资源需求执行其调度功能;它基于资源容器的抽象概念,其中包含内存、CPU、磁盘、网络等元素。
Scheduler有一个可插拔策略,该策略负责在各种队列、应用程序等之间划分集群资源。当前的调度程序(如 CapacityScheduler 和 FairScheduler)将是插件的一些示例。
2.2.1.2.ApplicationsManager:
** **负责接收作业提交,协商第一个容器以执行特定应用程序的ApplicationsMaster,并在失败时重新启动ApplicationsMaster容器。
2.2.2.NodeManager
NodeManager是每个节点上的代理,负责管理容器的生命周期,监控每个容器的资源使用情况(如cpu,内存,磁盘,网络),并将这些信息报告给ResoutceManager。同时他还负责容器的启动,监视和终止。
2.2.3.ApplicationMaster
每个应用程序都有一个独立的ApplicationMaster,负责与ResourceManager协商资源分配,并与NodeManager合作执行和监控任务。ApplicationMaster还负责管理任务的执行和容错处理。
2.2.4.容器(Container)
容器是Yarn中的资源分配单元,每个容器包含一定量的资源(如内存,CPU等),用于运行应用程序的任务。Yarn根据资源需求和集群状态动态分配和管理容器。
3.作业调度
3.1.描述Yarn的作业调度流程
3.1.1.作业提交
客户端通过工具或者API将作业提交给Yarn的ResourceManager。提交作业时,客户端提供详细的作业详细,如作业配置(包括作业类型、优先级、资源需求等)、数据输入输出路径、执行程序等。
RM为每个新提交的作业生成一个唯一的作业ID(JOB ID),用于标识该作业。此时作业状态为**NEW**;RM保存作业的详细信息和配置。作业状态更新为**SUBMIT**,表示作业已提交等待资源分配。
3.1.2.分配资源
RM将作业信息提供给Scheduler(调度器),调度器检查客户端的权限,并检查作业所属的队列(默认时default queue)是否足够的资源。根据调度策略,调度器决定如何分配资源。创建的调度器包括CapacityScheduler、FairScheduler 等。作业状态更新为**ACCEPT**,表示作业已被接受。
RM分配第一个容器,启动作业的AM。AM是负责管理和协调该作业的特定进程,处理作业的任务调度、监控和故障处理。
3.1.3.任务调度和资源分配
AM根据作业的需求和任务的并行度,向RM请求要更多的资源容器。资源请求包含所需的资源数量,位置配好(数据本地性)等。RM的scheduler基于集群资源使用情况,调度策略(如容量,优先级,数据本地性)等。
AM和RM协作将任务(如MapReduce中map或reduce任务)分配到已分配的容器执行。容器内的任务执行程序(如Yarn的TaskExecutor)启动并运行任务。作业状态为**RUNNING**。
3.1.4.任务监控和容错处理
ApplicationMaster 监控每个任务的执行状态,包括任务的启动、运行、成功或失败等。NodeManager 也监控容器的资源使用情况,并将信息汇报给 ResourceManager。如果任务或容器失败,ApplicationMaster 负责重新调度失败的任务,重新请求资源并启动新的容器。ResourceManager 和 NodeManager 协作确保资源的有效使用和故障隔离。
3.1.5.任务完成
当所有任务成功完成后,ApplicationMaster 向 ResourceManager 汇报作业的完成状态。ApplicationMaster 清理所有的资源和临时数据。如果JOB定期完成则JOB状态为**FINISHED**.如果运行过程中出现故障,JOB状态为**FAILED**.如果客户端KILL作业,此时JOB状态为**KILLED**.
4.资源管理
4.1.解释Yarn如何管理集群中的计算资源和内存资源
配置项设置说明yarn.scheduler.minimum-allocation-mb1024该配置表示每个容器的最小分配。因为RM是使用scheduler来进行资源调度的,如果请求的资源小于1G,也会设置为1G。这表示,如果我们请求一个256M的container,也会分配1G。yarn.scheduler.maximum-allocation-mb8192最大分配的内存,如果比这个内存高,就会抛出InvalidResourceRequestException异常。这里也就意味着,最大请求的内存不要超过8G。上述截图显示是4G,是因为我在yarn-site.xml中配置了最大分配4G。yarn.scheduler.minimum-allocation-vcores1同内存的最小分配yarn.scheduler.maximum-allocation-vcores4同内存的最大分配
4.2.讨论资源的分配策略和调度算法
4.2.1.资源分配策略
Yarn采用容器(Container)作为资源分配的基本单位。每个容器由一定量的内容、cpu和其他资源组成。资源分配策略的主要目标是优化资源的利用率、提高作业的吞吐量,并提供公平的资源分配。
Yarn使用容器来隔离不同作业和用户的资源使用,确保资源分配的公平性和隔离性。每个容器独立分配内存和CPU等资源,避免资源竞争导致的干扰。
ApplicationMaster代表作业向ResourceManager提交资源请求,包含所需的资源数量、位置偏好等信息。ResourceManager基于这些请求,结合调度策略,为作业分配资源。
4.2.2.调度算法
4.2.2.1.容器调度器CapacityScheduler
CapacityScheduler,它是hadoop的可插拔调度程序,它允许多租户安全地共享大型集群,以便在分配的容量约束下及时为其应用程序分配资源,同时最大限度地提高集群的吞吐量和利用率。其中心思想是hadoop集群中的可用资源在多个组织之间共享,各个组织也可以访问其他人未使用的任何多余容量。这以具有成本效益的方式组织提供了弹性。
跨组织共享集群需要对多租户的强大支持,因为每个组织都必须保证容器和安全措施,以确报共享集群不受单个流氓应用程序、用户或其集合的影响。容量调度提供了一组严格的限制,以确保单个应用程序、用户或队列不会消耗集群中不成比例的资源。容器调度器提供的主要抽象是队列,它们通常由管理员设置,同时支持分层队列,以确保在允许其他队列使用空闲资源之前,在组织的子队列之间共享资源,从而实现让一个组织的应用程序之间共享空闲资源的特性。
我理解如下:
假设此时有4个作业其中以下是需要的资源分布:
作业A:资源1,资源3 作业B:资源2,资源4
作业C:资源3,资源5 作业D:资源4,资源6
可以看出来A和C同时需要资源3,而作业B和D同时需要资源4
1.客户提交作业A,B,C,D到RM。RM将这些作业分配到不同队列中(假设所有作业在同一队列,或根据分配到不同的队列)。
2.当作业A和C同时需要资源3时,容量调度器会根据其调度策略(如 FIFO 或权重等)来决定哪个作业优先获得资源3。假设现在作业A的优先级高于作业C,调度器可能会在资源3可用时优先分配给作业A。
3.此时的资源检查和分配如下:
作业A:需要资源1和资源3。假设资源1是可用的,因此作业A开始运行,同时资源3也被分配给它。
作业B:需要资源2和资源4。资源2和资源4都是可用的,因此作业B也可以开始运行。
作业C:需要资源3和资源5。然而,此时资源3已经被作业A占用,因此作业C需要等待资源3变得可用。
作业D:需要资源4和资源6,但资源4此时被作业B占用,因此作业D也需要等待。
4.当作业A和B完成其使用资源3和4的任务后,它会释放资源3。此时,容量调度器可以将资源3分配给作业C,资源4分配给作业D,使作业CD开始运行。
4.2.2.2.公平调度器FairScheduler
公平调度是一种将资源分配给应用程序的方法,这样,随着时间的流逝,所有应用程序平均可获取获得相等的资源份额。Hadoop NetGen能够调度多种资源类型。默认情况下,公平调度程序仅基于内存来调度公平决策。可以使用Ghods等人开发的“主导资源公平性”概念将其配置为与内存和CPU一起调度。当有一个应用程序运行时,该应用程序将使用整个集群。提交其他应用程序时,会将释放的资源分配给新应用程序,这样每个应用程序最终都获得大致相同数量的资源。与构成应用程序队列的默认hadiio调度程序不同,这可让短时间的应用程序在合理的时间内完成,而不会饿死长寿命的应用程序。这也是在多个用户之间共享集群的一种合理方法。最后,公平共享也可以与应用程序优先级一起使用-优先级用作权重,以确定每个应用程序应该获得的总资源的比例。
调度程序将应用程序进一步组织到“队列”中,并在这些队列之间公平地共享资源。默认情况下,所有用户共享一个名为“默认”的队列。如果应用明确在容器资源请求中列出了队列,则该请求将提交到该队列。也可以通过配置根据请求中包含的用户名分配队列。在每个队列中,使用调度策略在运行的应用程序之间共享资源。默认设置是基于内存的公平共享,但是也可以配置具有优势资源公平性的FIFO和多资源。队列可以按层次结构排列以划分资源,并可以配置权重以按特定比例共享集群。
除提供公平共享外,公平调度程序还允许将保证的最小份额分配给队列,这对于确保某些用户,组或生产应用程序始终获得足够的资源很有用。当队列包含应用程序时,它至少获得其最小份额,但是当队列不需要其完全保证的份额时,多余的份额将在其他正在运行的应用程序之间分配。这样,当这些队列不包含应用程序时,调度程序就可以保证队列的容量,同时可以有效地利用资源。
Fair Scheduler默认情况下允许所有应用程序运行,但是也可以通过配置文件限制每个用户和每个队列中正在运行的应用程序的数量。当用户必须一次提交数百个应用程序时,这很有用;或者,如果一次运行太多应用程序会导致创建过多的中间数据或进行过多的上下文切换,则通常可以提高性能。限制应用程序不会导致任何后续提交的应用程序失败,而只会在调度程序的队列中等待,直到某些用户的早期应用程序完成为止。
我理解如下:
一样的例子
作业A:资源1,资源3 作业B:资源2,资源4
作业C:资源3,资源5 作业D:资源4,资源6
1.客户端将作业A、B、C、D提交RM。RM根据配置将这些作业分配到不同池中。假设作业都在同一个池,或者根据配置到不同的池。
2.资源分配流程
作业A:需要资源1和资源3。FairScheduler会尝试均匀地分配资源。如果资源1和资源3可用,作业A开始运行。
作业B:需要资源2和资源4。同样,如果资源2和资源4可用,作业B开始运行。
作业C:需要资源3和资源5。如果资源3已经被作业A占用,而资源5可用,作业C会使用资源5,同时等待资源3的释放。
作业D:需要资源4和资源6。如果资源4已经被作业B占用,而资源6可用,作业D会使用资源6,同时等待资源4的释放。
3.如果某个作业需要更多资源而其他作业有剩余资源,FairScheduler 会动态调整资源分配。例如,如果作业 A 和 B 没有完全使用分配给他们的资源,可以将这些资源临时分配给作业 C 和 D。在资源紧张的情况下,FairScheduler可以实施资源抢占,即高优先级或紧急的作业可以抢占低优先级作业的资源。
4.当作业A完成其任务后,资源1和资源3被释放。FairScheduler会立即将资源3分配给作业C,使作业C能够继续运行。同样,作业B完成后释放的资源2和资源4会被分配给其他需要的作业,如作业D。
5.Yarn与其他资源管理框架的比较
5.1.Yarn
最适合大数据处理任务,特别是在已经使用 Hadoop 生态系统的环境中。其成熟性和稳定性使得它成为传统数据处理的首选。
5.2.Mesos
非常灵活的资源管理框架,适合需要在同一集群上运行多种框架和工作负载的场景。它的两级调度机制提供了更高的资源利用率。
5.3.Kubernetes
是容器化和云原生应用的首选,特别适合需要高度自动化和灵活性的环境。它广泛的社区支持和生态系统使得它能够快速适应各种需求。
版权归原作者 sheansavage 所有, 如有侵权,请联系我们删除。