一、YARN(分布式资源管理器)
一)YARN的整体架构
Yarn 是 Hadoop2.x 版本提出的一种全新的资源管理架构,此架构不仅支持 MapReduce 计算,还方便管理,比如 HBase、Spark、Storm、Tez/Impala 等应用。这种新的架构设计能够使各种类型的计算引擎运行在 Hadoop 上面,并通过 Yarn 从系统层面进行统一的管理。也就是说,通过 Yarn 资源管理器,各种应用就可以互不干扰地运行在同一个 Hadoop 系统中了,来共享整个集群资源。
Yarn 的架构设计基于主从(Master-Slave)模式,主要由 ResourceManager(RM)和NodeManager(NM)两大部分组成。除此之外,还有 ApplicationMaster(AM)、Application Manager、Scheduler 及 Container 等组件辅助实现所有功能。
二)YARN知识点讲解
1、为什么会出现YARN
Hadoop1.0的主要问题
- 计算资源和计算模型的管理调度耦合
- 集群规模受以及调度管理能力限制
- 只有单一计算模型MR
2.0时代的解决问题(基于YARN)
- 管理资源和计算模型解耦合
- 二级调度
- 对更多计算模型的支持
YARN上的计算模型
MRv1与MRv2架构
2、什么是YARN
YARN是一代MapReduce,即MRv2。是在第一代MapReduce基础上演变而来的,主要是为了解决原始Hadoop扩展性查,不支持多计算框架而提出的。
YARN是下一代Hadoop计算平台,是一个通用的运行框架,用户可以编写自己计算框架,在该运行环境中运行。
用于自己编写的框架作为客户端的一个lib,在运行提交作业时打包即可。
- YARN=Yet Another Resource Negotiator:前身是MRv1的集群管理器
- MRv2最基本的设计思想是将Job Tracker的两个主要功能,即资源管理和作业调度/监控分成两个独立的进程。全局的ResourceManager(RM)和与每个应用相关的ApplicationMaster(AM)
- 这里的“应用”指一个单独的MapReduce作业。RM和与NodeManager(NM,每个节点一个)共同组成整个数据计算管理框架
3、YARN的核心组件
Yarn 中有两大组件,即 ResourceManager(RM)和 NodeManager(NM),其中 ResourceManager 由 ApplicationManager 和 Scheduler 组成。当用户提交 job 或 application 到 Yarn 上时,还会出现一个 ApplicationMaster 组件,此组件是应用程序级别的,用来管理运行在 Yarn 上的应用程序。这些 job 或 application 最终是在一个或多个 Container 中运行,而 Container 的资源则是通过 NodeManager 来分配。
1)ResourceManager(RM)
RM 是一个全局的资源管理器,集群里只有一个。它负责整个 Hadoop 系统的资源管理和分配,包括处理客户端请求、启动监控 ApplicationMaster、监控 NodeManager、资源的分配与调度等。它主要由两个组件构成,即调度器(Scheduler)和应用程序管理器 (ApplicationsManager,AsM)
资源管理:包括应用程序管理和机器资源管理
Scheduler 是一个集群资源调度器,根据集群的容量、队列等限制条件,将集群中的资源分配给各个正在运行的应用程序,以保障整个集群高效、合理地使用资源。
Scheduler 主要有两种,即 Capacity Scheduler 和 Fair Scheduler。第一个是基于容量的资源调度,而第二个是基于公平的资源调度
ApplicationsManager 负责管理整个集群中所有的应用程序,包括应用程序的提交、与调度器协商资源、启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。它的主要功能总结如下:
- 负责接收用户提交的任务请求,为应用分配第一个 Container,此 Container 用来运行 ApplicationMaster;
- 负责监控 ApplicationMaster 的状态,如果发现 ApplicationMaster 失败,会自动重启 ApplicationMaster 运行的 Container。
Container 是最底层的计算单元,所有应用程序都是在 Container 中执行计算任务的。
- ResourceManager负责对各个NodeManager(NM)上的资源进行统一管理和调度。它由两个组件构成
- (1)调度器(scheduler):根据容量、队列等限制条件,将系统资源分配给正在运行的应用程序。
- (2)应用程序管理器(applicationManager,AsM):负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动;applicationManager(AM)、监控AM运行状态并在失败的时候重启
2)ApplicationMaster
当用户提交一个分析任务时,ApplicationMaster 进程首先启动。接着,它向 ResourceManager 申请资源并和 NodeManager 协同工作来运行此任务;同时,它还会跟踪监视任务的执行状态。当遇到失败的任务时自动重启它;当任务执行完成后,ApplicationMaster 会关闭自己并释放自己的容器。
ApplicationMaster 执行过程是按照如下顺序进行的:
(1)ApplicationMaster 切分数据,对任务进行分片;
(2)ApplicationMaster 向 ResourceManager 申请资源,然后把申请下来的资源交给 NodeManager;
(3)监控任务的运行,并对错误任务进行重启;
(4)通过 NodeManager 监视任务的执行和资源使用情况。
- 管理application
- 代理App向RM申请/释放计算资源,以及与NM交互
- 管理App内部的container
- container生命周期管理
- container Failover处理
- container状态监控
3)NodeManager
NodeManager 进程运行在集群中的多个计算节点上,与 HDFS 分布式文件系统中 Datande 的角色类似,每个计算节点都运行一个 NodeManager 服务。
NodeManager 负责每个节点上资源(CPU 和内存)的使用,它主要实现如下功能:
- 接收并处理来自 ApplicationMaster 的 Container 启动、停止等请求;
- NodeManager 管理着本节点上 Container 的使用(Container 的分配、启动、停止等操作);
- NodeManager 定时向 ResourceManager 汇报本节点上的资源使用情况以及各个 Container 的运行状态(CPU 和内存等资源)。
注意:NodeManager只负责管理自身的container,不会关注container中运行的任务
4)container
container是Yarn资源管理器中最底层的计算单元,是执行计算任务的基本单位。比如Map task、reduce task都在container中执行
一个节点根据资源的不同,可以运行多个container,一个container就是一组分配的系统资源。现阶段container的系统资源只包含CPU和内存两种,未来可能增加次磁盘、网络等资源。
在 Yarn 中,ApplicationMaster 会跟 ResourceManager 申请系统资源,而 ResourceManager 只会告诉 ApplicationMaster 哪些 Containers 可以用。若要使用这些资源,ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。任何一个 job 或 application 最终都是在一个或多个 Container 中完成分析计算任务的。
4、YARN的特性
- 资源双层调度
- 容错性:各个组件均有考虑容错性
- 扩展性:可扩展到上万个节点
4、YARN的容错性
- ResourceManager
- 存在单点故障
- 基于zookeeper的HA
- NodeManager
- 失败后,RM将失败的任务告诉对应的AM
- AM决定如何处理失败的任务
- ApplicationMaster
- 失败后,由RM负责重启
- AM需处理内部任务的容错问题
- RMAppsMaster会保存已经运行完成的task
三)YARN配置(手撕Hadoop)
hadoop的程序根目录:/app/3rd/hadoop-3.3.1
1、配置文件——yarn-site.xml
文件位置:${HADOOP_HOME}//etc/hadoop/yarn-site.xml
内容主要分类:
- 通信地址类
- 目录类
- 资源类
- 安全类
- 节点健康状态监控类
1、YARN配置文件参数——通信地址类
2、YARN配置文件参数——目录类
3、YARN配置文件参数——资源类
4、YARN配置文件参数——安全类
5、YARN配置文件参数——节点健康状态监控类
2、修改配置文件
1、配置core-site.xml
添加如下的内容
core-site.xml
2、配置yarn-site.xml
yarn-site.xml
3、配置mapred-site.xml
mapred-site.xml
4、配置slaves
将各个datanode的主机IP填入,若配置了hosts文件,可以直接填写主机名
最后将前述各个文件都拷贝到slave机器上
四)YARN的调度
- 双层调度
- ResourceManager将资源分配给ApplicationMaster
- ApplicationMaster将资源分配给各个Task
- 基于资源预留的调度策略
- 当资源不够时,会给Task预留,直到资源满足
- 异步的分配
- 可调度资源
- CPU:yarn.nodemanager.resource.cpu-vcores
- 内存:yarn.nodemanager.resource.memory-mb和yarn.nodemanager.vmem-pmem-ratio
- 调度算法:Dominant Resource Fairness
- 资源管理器
- FIFO
- Capacity Scheduler
- Fair Scheduler
- 也可以自己实现
- YARN支持调度语义
- 请求某个节点上的特定资源量
- 请求某个机架上的特定资源量
- 将某些节点加入(或移除)黑名单,不再为自己分配这些节点上的资源
- 请求归还某些资源
- 不支持的调度语义
- 请求任意节点上的特定资源量
- 请求任意机架上的特定资源量
- 请求一组或几组符合某种特质的的资源
- 超细粒度资源,比如CPU性能要求、绑定CPU等
- 动态调整container资源,允许你根据需要动态调整container资源量
YARN Capacity Scheduler
- 设置yarn.resourcemanager.scheduler.class = CapacityScheduler
- yarn rmadmin -refreshQueues
- 树形结构:叶子(leaf)队列和父(parent)队列,由管理员指定容量
- 设定调度队列树形结构capacity.xml
- yarn的调度配置
- yarn.scheduler.capacity.root.queue = eda, crm
- yarn.scheduler.capacity.eda.queue = dpi, serv_bus
- yarn.scheduler.capacity.crm.queue = eda, oip
- 父队列用于组织层级之间的管理,他们可以包含更多的父队列和叶子队列,他们自己不会直接接受应用的提交
- 叶子队列是居于父队列之下并接受应用。叶子队列不会包含其他子队列,因此不会有任务配置属性以.queues结尾
- 顶层的父队列root不属于任何组织,它代表了集群自身
五)YARN部署
六)YARN的操作命令
1、yarn命令概述
使用语法:
2、命令详解
application
applicationattempt
classpath
container
jar
logs
node
queue
daemonlog
nodemanager
proxyserver
resourcemanager
rmadmin
scmadmin
sharedcachemanager
timelineserver
七)YARN的资源管理
在YARN中,资源管理由RescoueceManager和NodeManager共同完成,其中,Resourcemanager中的调度器负责资源分配,而NodeManager则负责资源的供给和隔离。
ResourceManager将某个Nodemanager上资源分配给任务(这就是所谓的资源调度)后,NodeManager需按照要求为任务提供相应的资源,甚至保证这些资源应具有独占性,为任务运行提供基础保证,这就是所谓的资源隔离。
图解:容器是内存和vcore的抽象概念。容器运行在nm节点
基于以上考虑,YARN允许用户配置每、个节点上可用的物理内存资源,注意,这里是“可用的”,因为一个节点上的内存会被若干个服务共享,比如一部分给YARN,一部分给HDFS,一部分给HBase等,YARN配置的只是自己可以使用的,配置参数如下:
(1)yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总量,默认是8192MB,注意,如果你的节点内存资源不够8G,则需要调减小这个值,而YARN不会智能的探测节点的物理内存总量。
yarn.nodemanager.resource.detect-hardware-capabilities 为true并且yarn.nodemanager.resource.memory-mb 为-1,那么
yarn.nodemanager.resource.memory-mb是自动计算,如果不是则yarn.nodemanager.resource.memory-mb=8G(默认)
(2)yarn.scheduler.minimum-allocation-mb
单个任务可申请的最少内存,默认时1024M,如果一个任务申请的物理内存量少于该值,则该对应的值减少位这个数
(3)yarn.scheduler.maximum-allocation-mb
单个任务可申请的最大内存,默认时8192M
(4)yarn.nodemanager.pmem-check-enabled true
是否启动一个线程检查每个任务正在使用的物理内存量,如果任务超出分配值,直接将他杀掉,默认是True
(5)yarn.nodemanager.vmem-check-enabled true
是否启动一个线程检查每个任务正在使用的虚拟内存量,如果任务超出分配值,直接将他杀掉,默认是True
(6)yarn.nodemanager.vmem-pmem-ratio 2.1
任务每使用1M的物理内存,最多可使用的虚拟内存量
目前的CPU被划分成虚拟CPU(CPU virtual Core),这里的虚拟CPU是YARN自己引入的概念,初衷是,考虑到不同节点的CPU性能可能不同,每个CPU具有的计算能力也是不一样的,比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍,这时候,你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业的时候,可以指定每个任务需要的虚拟CPU个数。在YARN中,CPU相关配置参数如下:
(7)yarn.nodemanager.resource.cpu-vcores 12
表示该节点上YARN可使用的虚拟CPU个数,默认是8,目前推荐将该值设置位与物理CPU核数数目相同。如果物理CPU核数不够8,则需要调小这个值,而YARN不 会智能的探测物理CPU总数。
(8) yarn.scheduler.minimum-allocation-vcores 1
单个任务可申请的最小CPU个数,默认是1,如果一个任务申请的CPU个数小于该数,则将该数改为这个数。
(9)yarn.scheduler.maximum-allocation-vcores 4
单个任务可申请的最大CPU个数,默认是4
container: 容器个数的判别标准有两个维度
一个是物理内存,一个是CPU
memory 16c~4c
vcores 12c~3c
yarn的在调优时候要综合考虑CPU和内存的分配,尽量保证不要空出多余的资源,假如container总内存30,container最小2G,总vcore8 container 最小1c
那么我们内存可以启动最多15个container,cpu最多启动8个container,最终可以启动8个container,会有相当多的内存没有用到。所以生产上的调优配置需要综合考量内存和 CPU的配比。
八)YARN的调度管理器
简单对比下三种调度器:
- FIFO - Allocates resources based on arrival time. 在当前强调多租户和资源利用率的大环境下,几乎已经没有集群采用 fifo调度器了;
- Fair - Allocates resources to weighted pools, with fair sharing within each pool. When configuring the scheduling policy of a pool, Domain Resource Fairness (DRF) is a type of fair scheduler;Cloudera 在 cdh 中推荐使用的即是该 Fair 调度器。(不过在 cloudera 的 cdp中,目前官方推荐且唯一支持的却是 capacity 调度器)
- Capacity - Allocates resources to pools, with FIFO scheduling within each pool. hadoop yarn 默认配置的调度器即是该 Capacity调度器 ;星环的 Tdh 中默认配置的也是该 capacity scheduler.
2、可以看到,Fair 和 Capacity 调度器的核心理念是类似的:
- 两个调度器都是把整个集群资源划分到若干个资源池 pool 中,而应用是提交到具体的资源池中并从中申请资源的,两个调取器都是基于这种机制,来做资源的隔离进而满足各种 sla 需求;
- 两个调度器的 pool 都是支持层次 即 Hierarchical 的;
- 两个调度器,都支持多租户;
- 两个调度器,都支持提交应用时指定具体的资源池;
- 当应用没有指定具体的资源池时,两个调度器都可以根据配置的规则,根据应用提交者的身份,决定实际使用的是哪个;
- 两个调度器,都支持根据应用提交者的身份,动态创建资源池;
3、两个调度器的对比如下:
- 两个调度器的核心区别,在于提交到一个具体的资源池中的所有任务,是采用 fair 公平调度还是 fifo 先进先出的调度;
- fair 公平调度器,综合考量了提交到 pool 中的各种大小任务的差异,能避免因长时间运行的大任务占用了大量集群资源,造成小任务长时间得不到资源无法执行,影响用户体验;
- Capacity 调度器,初看似乎没有像 fair 公平调取器那样,综合考量提交到 pool 中的任务大小的差异,但细想之下,管理员可以对大小任务/批流任务创建不同的 pool,由任务提交者根据任务的特点,提交到不同的 pool 中,一样能达到和 fair 调度器一样的效果和用户体验;
- Capacity 调度器,配置更为简单,可能是因为这种原因,cloudera 的 cdp 中目前推荐且唯一支持的是 Capacity 调度器;
由于当前大部分客户使用的都是 cloudera 的 cdh 集群推荐的 Fair 调度器,所以这里我们重点看下该公平调度器。