yarn生产详解（资源管理+调度器）

详解（资源管理+调度器）"/>

yarn生产详解（资源管理+调度器）

YARN （主从） 资源+作业调度管理

Yarn：一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享方面带来了巨大的好处。

ResourceManager（RM）：主要接收客户端任务请求，接收和监控NM的资源情况汇报，负责资源的分配与调度，启动和监控ApplicationMaster（AM）

            ApplicationManager（作业）：应用程序管理，他负责系统中所有的job，包括job的提交与调度器协商资源来启动ApplicationMaster（AM）和监控AM的运行状态，并且失败的时候能够重新启动它，更新分配一个新的Container容器的进度或者状态，除了资源它不管，它就负责job

            Scheduler（调度器）： 分配计算资源给应用程序的策略

yarn的内置调度器：

1.FIFO调度器，先进先出，适合任务量不多的低负载集群

谁先提交，谁先完成。1和2都提交，2要等1跑完了，才能运行。

2.计算调度 capacity scheduler

给不同队列（用户或用户组）分配一个预期最小容量，在每个队列内部用层次化的FIFO来调度多个应用程序。

适用于集群，引入了队列的概念，先占下一个队列的位置。1先提交，2后提交，但两个任务可以同时运行，互不干扰。

3. 公平调度 fair scheduler

针对不同的应用(可以是针对不同的用户或用户组)，每个应用属于一个队列，主旨是让每个应用分配的资源大体相当。（也可以自己设置权重）。若是只有一个应用，那集群所有的资源都是它的。使用情况：共享大集群、队列之间有较大差别。（生产使用）

task任务完成后会释放资源，job1资源释放后，job2马上会使用释放后的资源，job2小任务完成资源后，1可以接着使用2释放的资源，不会造成资源浪费。

capacity调度器的启用：
在ResourceManager节点上的yarn-site.xml设置
Property===>yarn.resourcemanager.scheduler.class
Value=====>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

capacity调度器的配置:
在目录$HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml

修改完成后，需要执行下面的命令：

$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues    使功能动态生效。

NodeManager：主要是节点上的资源和作业管理器，启动container运行task计算，上报资源、container情况给RM和处理情况给AM，整个集群有多个。

ApplicationMaster：负责我们作业的监控并跟踪应用执行状态来重启失败任务的，主要是对单个Application的task管理和调度，向RM进行资源的申请，向NM发出launchContainer指令，接收NM的task处理状态信息。一个job只有一个主程序。

Container：是yarn中资源的抽象，它封装了某个节点上一定量的资源（cpu和内存两类资源）

Memory：
yarn.nodemanager.resource.memory-mb：64*0.8G=50G  （如果内存是64G，Yarn只能用到内存的80%也就是50G）
yarn.scheduler.minimum-allocation-mb: 1G
yarn.scheduler.maximum-allocation-mb: 1G   50/1=50（并行度） 数量是多了，并行度大了  
一个作业200 MapTask 4轮才能结束，速度快了  作业可能挂了
yarn.scheduler.maximum-allocation-mb: 16G (生产设16G)   50/16=3（并行度） 数量是少了，并行度小了  
一个作业200 MapTask 70轮才能结束，速度慢了  作业时间长 稳定不会挂

工作中一个job可以指定 yarn.scheduler.maximum-allocation-mb的值，但一般不指定。

Container是Yarn对计算机计算资源的抽象，它其实就是一组CPU和内存资源，所有的应用都会运行在Container中。

ApplicationMaster是对运行在Yarn中某个应用的抽象，它其实就是某个类型应用的实例，ApplicationMaster是应用级别的，它的主要功能就是向ResourceManager（全局的）申请计算资源（Containers）并且和NodeManager交互来执行和监控具体的task。

Scheduler是ResourceManager专门进行资源管理的一个组件，负责分配NodeManager上的Container资源，NodeManager也会不断发送自己Container使用情况给ResourceManager。

ResourceManager和NodeManager两个进程主要负责系统管理方面的任务。ResourceManager有一个Scheduler，负责各个集群中应用的资源分配。对于每种类型的每个应用，都会对应一个ApplicationMaster实例，ApplicationMaster通过和ResourceManager沟通获得Container资源来运行具体的job，并跟踪这个job的运行状态、监控运行进度。
 

【若泽大数据实战】 使用YARN跑一个jar包

1）创建输入文件夹

2）把需要字数统计的文件放入input文件夹

3）执行字数统计

【面试题】

请问RM节点上有Container容器的这种说法吗？

答：这种说法是错误的，Container容器只运行在 Node Manager上面。

在AM中，job已经被分成一系列的task，并且是为每个task来startContainer。为什么NM上要存一个application的数据结构呢？
答：在YARN看来，他所维护的所有应用程序叫appliction，但是到了计算框架这一层，各自有各自的名字，mapreduce叫job，storm叫topology等等，YARN是资源管理系统，不仅仅运行mapreduce，还有其他应用程序，mapreduce只是一种计算应用。但是yarn内部设有应用程序到计算框架应用程序的映射关系（通常是id的映射），你这里所说的应用程序，job属于不同层面的概念，切莫混淆，要记住，YARN是资源管理系统，可看做云操作系统，其他的东西，比如mapreduce，只是跑在yarn上的application，但是，mapreduce是应用层的东西，它可以有自己的属于，比如job task，但是yarn专业一层是不知道或者说看不到的。

“YARN是资源管理系统，运行在它之上的所有应用程序叫application，例如mapreduce就是运行在YARN上的一个application。在mapreduce内部产生了job、task等等对象”。但是还是有一点疑问：对于Yarn来说，对于每一个运行程序application（例如mapreduce）只维护一个内部application对象么？
比如在Yarn上运行了一个mapreduce（它是跑在yarn上的application这里我能理解），例如当mapreduce中的某个job与NM发生交互时，YARN只能知道是mapreduce这个application再与它进行交互，而无法得知是这个application中的某一个对象再与之进行交互么？这样的话，例如当不同的job(一个application中可以有很多job)与NM进行交互时，Yarn怎样去区别当前job。或者Yarn在维护的那个application数据结构中能够表示该application的哪部分正在运行？

答：YARN不需要知道是job还是其他东西与它交互，在他看来，只有application，YARN为这些applicaiton提供了两类接口，一个是申请资源，具体申请到资源后，applicaiton用来干啥，跑map task还是跑MPI task，YARN不管，二是运行container的命令（container里面包的是task或者其他application内部要跑的东西），一般是一个shell命令，用于启动container（即启动task）。YARN看不到application什么时候运行完，他还有几个task没跑，这些只有applicaiton自己知道，当application运行结束后，会告诉YARN，YARN再将他所有信息抹掉。

是否只有负责启动ApplicationMaster的NodeManager才会维护一个Application对象？其他的NodeManager是否是根据ApplicationMaster发起的请求来启动属于这个Application的其他Container，这些NodeManager不需要维护Application的状态机？

答：都需要维护，通过Application状态机可将节点上属于这个App的所有Container聚集在一起，当需要特殊操作，比如杀死Application时，可以将对应的所有Container销毁。
另外，需要注意，一个应用程序的ApplicationMaster所在的节点也可以运行它的container，这都是随机的。

Container的节点随机性？

答：Container的节点随机性，我的理解是Container运行的节点是由分配资源时集群中哪些节点正好是空闲的来决定的，ResourceManager在为ApplicationMaster分配所需的Container的时候,完全有可能出现ApplicationMaster的本地节点上出现了空闲资源，这样，如果分配成功之后，ApplicationMaster就和所属的Container运行在一个节点上了。
 

Memory 资源的调度和隔离：

基于以上考虑，YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若
干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下：
（1） yarn.nodemanager.resource.memory- - mb
表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而
YARN不会智能的探测节点的物理内存总量。
（2） yarn.nodemanager.vmem- - pmem- - ratio
任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。
（3）  yarn.nodemanager.pmem- - check- - enabled
是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
（4）  yarn.nodemanager.vmem- - check- - enabled
是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
（5） yarn.scheduler.minimum- - allocation- - mb
单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。
（6） yarn.scheduler.maximum- - allocation- - mb
单个任务可申请的最多物理内存量，默认是8192（MB）。
      默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。

CPU资源的调度和隔离：

目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，

初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物
理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个
虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU
相关配置参数如下：
（1） yarn.nodemanager.resource.cpu- - vcores
表示该节点上YARN可使用的虚拟CPU个数，默认是4，注意，目前推荐将该值设值为与物理CPU核数
数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物
理CPU总数。
（2）  yarn.scheduler.minimum- - allocation- - vcores
单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应
的值改为这个数。
（3） yarn.scheduler.maximum- - allocation- - vcores
单个任务可申请的最多虚拟CPU个数，默认是32。
默认情况下，YARN是不会对CPU资源进行调度的，你需要配置相应的资源调度器。