Yarn任务调度

圈重点

Spark on Yarn ：仅仅是将spark作为一个客户端而已

Application = diver（进程） + excutor（进程）是一个独立的进程集合

diver用于运行main方法，会创建一个，new 一个sparkContext或者sparkSession

excutor运行在一个Application 的worknode（yarn里面的container standalone里面的worker）上，可以执行task，也可以把数据取到内存或者磁盘上，存储数据

一个excutor可以运行多个task

一个task（工作单元）将会被发送到excutor去执行（里面包括jar）

job就是一个action（rdd.count，save，collect），一旦出现action操作就会有一个job，一个job由多个task组成

stage：一个job=多个task（多个task这个集合就叫做stage）

1job=N*task=M*stage

stage之间相互依赖，前面的依赖后面的，包括宽依赖，窄依赖（比如reduce stage依赖于map stage）

通常来讲Task的数量=Partition的数量，因为每一个 task 只是处理一个 partition 上的数据

stage的划分是以shuffle操作作为边界的。也就是说某个action导致了shuffle，就会划分出两个stage

Application	User program built on Spark. Consists of a driver program and executors on the cluster.
Application jar	A jar containing the user's Spark application. In some cases users will want to create an "uber jar" containing their application along with its dependencies. The user's jar should never include Hadoop or Spark libraries, however, these will be added at runtime.
Driver program	The process running the main() function of the application and creating the SparkContext
Cluster manager	An external service for acquiring resources on the cluster (e.g. standalone manager, Mesos, YARN)
Deploy mode	Distinguishes where the driver process runs. In "cluster" mode, the framework launches the driver inside of the cluster. In "client" mode, the submitter launches the driver outside of the cluster.
Worker node	Any node that can run application code in the cluster
Executor	A process launched for an application on a worker node, that runs tasks and keeps data in memory or disk storage across them. Each application has its own executors.
Task	A unit of work that will be sent to one executor
Job	A parallel computation consisting of multiple tasks that gets spawned in response to a Spark action (e.g. save, collect); you'll see this term used in the driver's logs.
Stage	Each job gets divided into smaller sets of tasks called stages that depend on each other (similar to the map and reduce stages in MapReduce); you'll see this term used in the driver's logs.

上图首先通过Diver的main方法创建sparkContext对象，并连接到ClusterManager去获取资源（包括连接模式yarn，mesos，localhost、standalone模式等），一旦连接上了，然后去申请excutor，然后通过sparkContext直接到excutor机器上启动excutor进程（task表示操作数据，cache表示存储数据），双向箭头表示通信，然后diver（sparkContext）发送Application代码和JARS包到每个task上去（所以我们最好提前把JARS包提交到hdfs上去，通过指定路径，减少网络传输带宽）

There are several useful things to note about this architecture:

1. Each application gets its own executor processes, which stay up for the duration of the whole application and run tasks in multiple threads. This has the benefit of isolating applications from each other, on both the scheduling side (each driver schedules its own tasks) and executor side (tasks from different applications run in different JVMs). However, it also means that data cannot be shared across different Spark applications (instances of SparkContext) without writing it to an external storage system.
2. Spark is agnostic to the underlying cluster manager. As long as it can acquire executor processes, and these communicate with each other, it is relatively easy to run it even on a cluster manager that also supports other applications (e.g. Mesos/YARN).
3. The driver program must listen for and accept incoming connections from its executors throughout its lifetime (e.g., see spark.driver.port in the network config section). As such, the driver program must be network addressable from the worker nodes.
4. Because the driver schedules tasks on the cluster, it should be run close to the worker nodes, preferably on the same local area network. If you’d like to send requests to the cluster remotely, it’s better to open an RPC to the driver and have it submit operations from nearby than to run a driver far away from the worker nodes.

有关此体系结构的几个有用的注意事项：

1. 每个应用程序都有它自己的执行程序进程，这些进程在整个应用程序期间保持运行并在多个线程中运行任务。这有利于在调度端（每个驱动程序调度它自己的任务）和执行端（来自不同应用程序的任务运行在不同的JVM中）相互隔离应用程序。但是，这也意味着数据不能在不同的Spark应用程序（SparkContext的实例）之间共享，而无需将其写入外部存储系统。（简言之：apllication及excutor彼此之间都是独立的，是不可以共享数据的，但是如果借助第三方分布式文件系统是可以实现excutor间的数据共享的：比如说Alluxio）
2. Spark对底层集群管理器不可知。只要它可以获得执行程序进程，并且它们相互通信，即使在也支持其他应用程序的集群管理程序（例如，Mesos / YARN）上运行它相对比较容易。（简言之：spark不关心底层代码）
3. 驱动程序必须在其整个生命周期内监听并接受来自执行程序的传入连接（例如，请参阅网络配置部分中的spark.driver.port）。因此，驱动程序必须能够从工作节点进行网络寻址。（简言之：在整个生命周期diver应用程序和excutor能相互同心就行）
4. 由于驱动程序在群集上安排任务，因此它应该靠近工作人员节点运行，最好在同一局域网上运行。如果您想远程向集群发送请求，最好打开一个RPC给驱动程序，让它从附近提交操作，而不是远离工作节点运行驱动程序。（简言之：spark需要提交code和jars，我们上传到hdfs上)

Spark on YARN:Driver 运行在哪里

        cluster: drive run in ApplicationMaster

        client：提交Spark程序的本地机器

yarn对于自己运行时作业的资源分配模式有Capacity Scheduler和Fair Scheduler两种。

在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中，ResourceManager中的调度器负责 资源的分配，而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务（这就是所 谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的 资源隔离。

基于以上考虑，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）。

Capacity Scheduler

Capacity Scheduler支持以下特性：

(1) 计算能力保证。支持多个队列，某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源，且所有提交到队列中的作业共享该队列中的资源。

(2) 灵活性。空闲资源会被分配给那些未达到资源使用上限的队列，当某个未达到资源的队列需要资源时，一旦出现空闲资源资源，便会分配给他们。

(3) 支持优先级。队列支持作业优先级调度（默认是FIFO）

(4) 多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源。

(5) 基于资源的调度。 支持资源密集型作业，允许作业使用的资源量高于默认值，进而可容纳不同资源需求的作业。不过，当前仅支持内存资源的调度。


想要配置能力调度模式首先我们需要将yarn-site.xml文件中设置yarn.resourcemanager.scheduler.class属性为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.CapacityScheduler


1. 资源分配相关参数

（1） capacity：队列的资源容量（百分比）。 当系统非常繁忙时，应保证每个队列的容量得到满足，而如果每个队列应用程序较少，可将剩余资源共享给其他队列。注意，所有队列的容量之和应小于100。

（2） maximum-capacity：队列的资源使用上限（百分比）。由于存在资源共享，因此一个队列使用的资源量可能超过其容量，而最多使用资源量可通过该参数限制。

m minimum-user-limit-percent：每个用户最低资源保障（百分比）。任何时刻，一个队列中每个用户可使用的资源量均有一定的限制。当一个队列中同时运行多个用户的应用程序时中，每个用户的使用资源量在一个最小值和最大值之间浮动，其中，最小值取决于正在运行的应用程序数目，而最大值则由minimum-user-limit-percent决定。比如，假设minimum-user-limit-percent为25。当两个用户向该队列提交应用程序时，每个用户可使用资源量不能超过50%，如果三个用户提交应用程序，则每个用户可使用资源量不能超多33%，如果四个或者更多用户提交应用程序，则每个用户可用资源量不能超过25%。

（3） user-limit-factor：每个用户最多可使用的资源量（百分比）。比如，假设该值为30，则任何时刻，每个用户使用的资源量不能超过该队列容量的30%。

2. 限制应用程序数目相关参数

（1） maximum-applications ：集群或者队列中同时处于等待和运行状态的应用程序数目上限，这是一个强限制，一旦集群中应用程序数目超过该上限，后续提交的应用程序将被拒绝，默认值为 10000。所有队列的数目上限可通过参数yarn.scheduler.capacity.maximum-applications设置（可看做默认 值），而单个队列可通过参数yarn.scheduler.capacity.<queue-path>.maximum- applications设置适合自己的值。

（2） maximum-am-resource-percent：集群中用于运行应用程序 ApplicationMaster的资源比例上限，该参数通常用于限制处于活动状态的应用程序数目。该参数类型为浮点型，默认是0.1，表示10%。所 有队列的ApplicationMaster资源比例上限可通过参数yarn.scheduler.capacity. maximum-am-resource-percent设置（可看做默认值），而单个队列可通过参数 yarn.scheduler.capacity.<queue-path>. maximum-am-resource-percent设置适合自己的值。

3. 队列访问和权限控制参数

（1） state ：队列状态可以为STOPPED或者 RUNNING，如果一个队列处于STOPPED状态，用户不可以将应用程序提交到该队列或者它的子队列中，类似的，如果ROOT队列处于STOPPED 状态，用户不可以向集群中提交应用程序，但正在运行的应用程序仍可以正常运行结束，以便队列可以优雅地退出。

（2） acl_submit_applications：限定哪些Linux用户/用户组可向给定队列中提交应用程序。需要注意的是，该属性具有继承性，即如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（3） acl_administer_queue：为队列指定一个管理员，该管理员可控制该队列的所有应用程序，比如杀死任意一个应用程序等。同样，该属性具有继承性，如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。

Fair Scheduler

公平调度器按资源池（pool）来组织作业，并把资源公平的分到这些资源池里。默认情况下，每一个用户拥有一个独立的资源池，以使每个用户都能获得 一份等同的集群资源而不管他们提交了多少作业。按用户的 Unix 群组或作业配置（jobconf）属性来设置作业的资源池也是可以的。在每一个资源池内，会使用公平共享（fair sharing）的方法在运行作业之间共享容量（capacity）。用户也可以给予资源池相应的权重，以不按比例的方式共享集群。

除了提供公平共享方法外，公平调度器允许赋给资源池保证（guaranteed）最小共享资源，这个用在确保特定用户、群组或生产应用程序总能获取 到足够的资源时是很有用的。当一个资源池包含作业时，它至少能获取到它的最小共享资源，但是当资源池不完全需要它所拥有的保证共享资源时，额外的部分会在 其它资源池间进行切分。

要想配置公平调度模式首先我们需要将yarn-site.xml文件中设置yarn.resourcemanager.scheduler.class属性为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler


Fair Scheduler允许用户将队列信息专门放到一个配置文件（默认是fair-scheduler.xml），对于每个队列，管理员可配置以下几个选项：

（1） minResources ：最少资源保证量，设置格式为“X mb, Y vcores”，当一个队列的最少资源保证量未满足时，它将优先于其他同级队列获得资源，对于不同的调度策略（后面会详细介绍），最少资源保证量的含义不 同，对于fair策略，则只考虑内存资源，即如果一个队列使用的内存资源超过了它的最少资源量，则认为它已得到了满足；对于drf策略，则考虑主资源使用 的资源量，即如果一个队列的主资源量超过它的最少资源量，则认为它已得到了满足。

（2） maxResources：最多可以使用的资源量，fair scheduler会保证每个队列使用的资源量不会超过该队列的最多可使用资源量。

（3） maxRunningApps：最多同时运行的应用程序数目。通过限制该数目，可防止超量Map Task同时运行时产生的中间输出结果撑爆磁盘。

（4） minSharePreemptionTimeout：最小共享量抢占时间。如果一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源。

（5） schedulingMode/schedulingPolicy：队列采用的调度模式，可以是fifo、fair或者drf。

（6） aclSubmitApps：可向队列中提交应用程序的Linux用户或用户组列表，默认情况下为“*”，表示任何用户均可以向该队列提交应用程序。需要注意的是，该属性具有继承性，即子队列的列表会继承父队列的列表。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（7） aclAdministerApps：该队列的管理员列表。一个队列的管理员可管理该队列中的资源和应用程序，比如可杀死任意应用程序。

管理员也可为单个用户添加maxRunningJobs属性限制其最多同时运行的应用程序数目。此外，管理员也可通过以下参数设置以上属性的默认值：

（1） userMaxJobsDefault：用户的maxRunningJobs属性的默认值。

（2） defaultMinSharePreemptionTimeout ：队列的minSharePreemptionTimeout属性的默认值。

（3） defaultPoolSchedulingMode：队列的schedulingMode属性的默认值。

（4） fairSharePreemptionTimeout：公平共享量抢占时间。如果一个资源池在该时间内使用资源量一直低于公平共享量的一半，则开始抢占资源。

From https://blog.csdn.net/lw_ghy/article/details/51828513