hadoop之yarn调度
序言
在大数据的生态中，hdfs解决了海量数据的存储问题，mapreduce解决了海量数据的计算问题，而在任务的执行和资源统一管理层面，则是使用yarn进行统一调度。
yarn：yet another resouce negotiator，另外一种资源调度器。
yarn
1 为什么会有yarn
hadoop经历了两个大的架构，在1.X版本中，核心只有hdfs和MapReduce，这个里面MapReduce既承担了海量数据的计算问题，而且需要负责相关的任务调度，资源分配，监控恢复任务，成为一个性能瓶颈，在2.X架构中，将MapReduce进行了一个分拆，MapReduce仅仅负责计算问题，而抽取出来的yarn，则作为资源的分配，调度，任务的生命周期管理。
2 yarn架构图（官方文档截取）
Resource Manager：简称RM，资源管理器，负责管理应用程序application的全局计算资源的分配，接收来自客户端的请求，和Node Manager进行通信，检查节点的健康状态，启动调度Application Master。
Application Master：简称AM，管理应用程序的调度和协调，每个应用程序一个，也可以叫做MRAppMaster。
Application：一个MapReduce作业或者是DAG的多个jobs。
NodeManager：运行在每个节点中，简称为NM，节点管理器，主要和RM进行通信，并和ApplicationMaster一起执行和监控任务，监控container容器的资源使用情况。
Container：表示分配的一组包括CPU，内存，网络，磁盘资源的容器。
在RM中，包含两个主要的组件，一个是schedule调度组件，一个是applicationsmanager应用程序管理组件。
3 高可用架构
搭建集群的时候，总是需要高可用架构的，对于RM来说，主要是HA的形式，一个状态是Active，一个状态是Standby，对于NM来说，主要分布式节点，一般的部署方式是对于HDFS的数据节点DataNode，那么就可以部署为Node Manager节点。
在查看RM状态的时候，可以使用如下的命令：
//查看RM的状态，是主还是备
[root@KEL2 logs]# yarn rmadmin -getServiceState rm1
active
[root@KEL2 logs]# yarn rmadmin -getServiceState rm2
standby
//查看Node Manager的节点
[root@KEL2 logs]# yarn node -list
Total Nodes:3
Node-Id Node-State Node-Http-Address Number-of-Running-Containers
KEL2:40768 RUNNING KEL2:8042 0
KEL1:36635 RUNNING KEL1:8042 0
KEL:33262 RUNNING KEL:8042 0
//查看当前正在运行的应用程序
[root@KEL2 logs]# yarn application -list
Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):0
Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL
//查看当前尝试运行的应用程序
[root@KEL2 logs]# yarn applicationattempt -list
Missing argument for options
usage: applicationattempt
-help Displays help for all commands.
-list <Application ID> List application attempts for
aplication.
-status <Application Attempt ID> Prints the status of the application
attempt.
//查看某个尝试运行的应用程序的容器列表
[root@KEL2 logs]# yarn container -list
Missing argument for options
usage: container
-help Displays help for all commands.
-list <Application Attempt ID> List containers for application attempt.
-status <Container ID> Prints the status of the container.分别查看RM和NodeManager的监听端口：
[root@KEL2 logs]# jps
2292 QuorumPeerMain
2660 NodeManager
8676 ResourceManager
8807 Jps
2425 JournalNode
2348 DataNode
//查看ResourceManager的监听端口
[root@KEL2 logs]# netstat -tnlp|grep 8676
tcp6 0 0 192.168.1.199:8088 :::* LISTEN 8676/java
tcp6 0 0 192.168.1.199:8033 :::* LISTEN 8676/java
//查看NodeManager的监听端口
[root@KEL2 logs]# netstat -tnlp|grep 2660
tcp6 0 0 :::8040 :::* LISTEN 2660/java
tcp6 0 0 :::8042 :::* LISTEN 2660/java
tcp6 0 0 :::13562 :::* LISTEN 2660/java
tcp6 0 0 :::40768 :::* LISTEN 2660/java
//主机状态为备
[root@KEL2 logs]# yarn rmadmin -getServiceState rm1
standby
-----查看主机-----
[root@KEL1 hadoop]# jps
8192 Jps
2292 QuorumPeerMain
2455 DataNode
2535 JournalNode
2648 DFSZKFailoverController
6648 NameNode
2783 NodeManager
7759 ResourceManager
[root@KEL1 hadoop]# netstat -ntlp|grep 7759
tcp6 0 0 192.168.1.99:8088 :::* LISTEN 7759/java
tcp6 0 0 192.168.1.99:8030 :::* LISTEN 7759/java
tcp6 0 0 192.168.1.99:8031 :::* LISTEN 7759/java
tcp6 0 0 192.168.1.99:8032 :::* LISTEN 7759/java
tcp6 0 0 192.168.1.99:8033 :::* LISTEN 7759/java
[root@KEL1 hadoop]# netstat -tnlp|grep 2783
tcp6 0 0 :::8040 :::* LISTEN 2783/java
tcp6 0 0 :::8042 :::* LISTEN 2783/java
tcp6 0 0 :::13562 :::* LISTEN 2783/java
tcp6 0 0 :::36635 :::* LISTEN 2783/java
[root@KEL1 hadoop]# yarn rmadmin -getServiceState rm2
active
//可以看到standby的resourcemanager节点上的监听端口很少。HA高可用架构如下所示：
RM的自动切换和HDFS中的自动切换不同，HDFS的NM需要依赖于ZKFC守护进程来进行切换，而在RM中则内嵌了一个基于zookeeper的ActiveStandbyElector，可以自动确定哪个RM是Active，在这个过程发生的时候，RM都是无日志显示的，只有zk的检测的日志：
2021-02-14 05:17:05,122 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:3001:NIOServerCnxn@376] - Unable to read additional data from client sessionid 0x1000002802a0002, likely client has closed socket
2021-02-14 05:17:05,123 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:3001:NIOServerCnxn@1040] - Closed socket connection for client /192.168.1.99:44263 which had sessionid 0x1000002802a0002当RM挂了之后，客户端的任务都会不断的轮询所有的RM节点，直到有RM节点活跃，那么会再次执行所有的job。
当所有RM挂了之后，重新启动RM，这个时候RM会加载内部状态，从上一个活动状态中断的地方继续运行，对于先前提交的应用程序，则会进行新的尝试，在HA集群中使用ZKMSstore来进行持久化存储，这个可以解决潜在的脑裂情况。
3 任务重试测试
手动启动一个应用程序，也就是启动一个mapreduce job：
手动杀掉启动的mapreduce application master：
会看到重新启动一个进行重试任务，从而9569进程启动。
在nodemanager节点上，也会看到YarnChild，其实也就是所说的container资源，这个里面会运行相关的map task和reduce task。
这些信息也可以在web界面看到：
从应用程序找到应用程序ID
进入可以看到进行了两次任务，一次是失败的，一次是成功的，失败就是kill mrmaster的那次。
进入可以看到使用的容器数量。
在运行的过程中，也可以看到相关的资源及分配情况。
界面上也能看到相关node的信息：
注意：
在启动yarn集群的时候，必须在resourcemanager上启动，否则resource manager无法启动。standby节点的resource manager需要单独启动。
//ha模式下的yarn-site.xml配置文件
<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.log-aggregation-enable</name>
<value>true</value>
</property>
<property>
<name>yarn.log-aggregation.retain-seconds</name>
<value>604800</value>
</property>
<property>
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm1</name>
<value>KEL2</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm2</name>
<value>KEL1</value>
</property>
<property>
<name>yarn.resourcemanager.webapp.address.rm1</name>
<value>KEL2:8088</value>
</property>
<property>
<name>yarn.resourcemanager.webapp.address.rm2</name>
<value>KEL1:8088</value>
</property>
<property>
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
</property>
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>yrc</value>
</property>
<!-- Site specific YARN configuration properties -->
<property>
<name>yarn.resourcemanager.zk-address</name>
<value>KEL:3001,KEL:4001,KEL2:5001</value>
</property>
</configuration>