-
【Hadoop】学习笔记（八）
四、MapReduce
4.1、Yarn概述
4.1.1、Yarn
Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。
Yarn 是 Yet Another Resource Negotiator（另一种资源协调者）的缩写。
Yarn 是一个通用的资源管理系统 和调度平台，可以为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
虽然 Yarn 属于Hadoop的一部分，但是Yarn不仅仅能运行 MapReduce，还可以运行 Tez、HBase、Spark、Flink等等程序，理论上支持各种计算程序。Yarn不关心你做的什么，只负责管理资源（内存 和 CPU）。
4.1.2、Yarn架构
Yarn由 ResourceManager、NodeManager、ApplicationMaster 和 Container 等组件构成。
4.2、Yarn工作机制
4.2.1、Yarn工作机制
4.2.2、调度器和调度算法
调度器（Resource Scheduler）是属于ResourceManager内部的一个组件，当有多个 job 提交过来的时候，使用调度器进行调度。
在理想情况下，应用程序提出的请求都将立即得到Yarn批准。但在实际中，资源是有限的，并且繁忙的在群集上。Yarn调度程序的工作是根据一些定义的策略为应用程序分配资源。
在Yarn中，负责给应用程序分配资源的就是Scheduler，它是ResourceMananger的核心组件之一。
Scheduler完全专用于调度作业，它无法跟踪应用程序的状态。一般而言，调度并没有一个“最佳”策略，而是要根据实际情况进行调整，所以Yarn提供了多种调度器和可配置的策略供选择。
Hadoop作业调度器主要有三种：先进先出调度器（FIFO）、容量调度器（Capacity Scheduler）、公平调度器（Fair Scheduler）。
Apache的Hadoop 3.x 默认的资源调度器是 Capacity Scheduler。CDH 的yarn默认使用的是 Fair Scheduler。
可以通过配置文件配置：
yarn-site.xml<property> <description>The class to use as the resource scheduler.description> <name>yarn.resourcemanager.scheduler.classname> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacitySchedulervalue> property>- 1
- 2
- 3
- 4
- 5
- 6
4.2.2.1、先进先出调度器（FIFO）
FIFO调度器（First In First Out）：单队列，根据提交作业的先后顺序，先来先服务。调度工作不考虑优先级和范围，适用于负载较低的小规模集群。当使用大型共享集群时，它的效率较低且会导致一些问题。
FIFO Scheduler拥有一个控制全局的队列queue，默认queue名称为default，该调度器会获取当前集群上所有的资源信息作用与这个全局的queue。
优点：无需配置，先到先得，易于执行。
缺点：任务的优先级不会变高，因此高优先级的作业也需要等待，不适合共享集群。
FIFO是 Hadoop 1.x 中的 JobTracker 原有的调度器实现，在Yarn中保留了下来。实际生产中用到大数据的场景都是高并发的，所以一般不会采用这种调度器。
4.2.2.2、容量调度器（Capacity Scheduler）
Capacity Scheduler 是 Yahoo 开发的多用户调度器，是Apache版的 Hadoop 3.x 的默认调度策略。
该策略允许多个组织共享整个集群资源，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。
Capacity可以理解成一个个的资源队列，这个资源队列是用户自己去分配的。队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出（FIFO）策略。
Capacity Scheduler调度器以队列为单位划分资源。简单点说，就是一个个队列有独立的资源，队列的结构和资源是可以进行配置的。
优点：
- 层次化的队列设计（Hierarchical Queues）：层次化的管理，可以更容易、更合理分配和限制资源的使用
- 容量保证（Capacity Guarantees）：每个队列上都可以设置一个资源的占比，保证每个队列都不会占用整个集群的资源
- 安全（Security）：每个队列有严格的访问控制。用户只能向自己的队列里提交任务，而且不能修改或访问其他队列的任务
- 弹性分配（Elasticity）：空闲的资源可以被分配给任何队列；当多个队列出现争用的时候，则按照权重比例进行平衡
特点：
- 多队列：每个队列可配置一定的资源量，每个队列可配置一定的资源量，每个队列采用FIFO调度策略。
虽然每个队列采用的是FIFO，但是如果前一个job占用的资源较少，第二个job也可以同步执行。例如 queueA中设置了8G内存，job11只消耗2G内存，那么job12就可以同步执行 - 容量保证：管理员可以为每个队列设置资源最低保证、使用上限
- 灵活性：如果一个队列中的资源有剩余，可以暂时共享给其他需要资源的队列，而一旦该队列有新的应用程序提交，则其他队列借调的资源会归还给该队列
- 多租户：支持多用户共享集群和多应用程序同时运行。为了防止同一个用户的作业独占队列中的资源，该调度器会对同一个用户提交的作业所占的资源量进行限定。
4.2.2.3、公平调度器（Fair Scheduler）
Fair Scheduler，公平调度器，是 Facebook 开发的多用户调度器。 提供了Yarn应用程序 公平地共享大型集群中资源 的另一种形式。使所有应用在平均情况下随着时间的流式可以获得相等的资源份额。
Fair Scheduler设计目标是为所有的应用分配公平的资源（对公平的定义通过参数来设置）。
公平调度可以在多个丢列建工作，允许资源共享和抢占。
优点：
- 分层队列：队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群
- 基于用户或组的队列映射：可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列，则在该队列中提交任务
- 资源抢占：根据应用的配置，抢占和分配资源可以是友好的或者强制的。默认不启用资源抢占
- 保证最小配额：可以设置队列最小资源，允许将保证的最小份额分配给队列，保证用户可以启动任务。当队列不能满足最小资源时，可以从其他队列抢占。当队列资源使用不完时，可以给其他队列使用。这对于确保某些用户、组或者生产应用使用获得足够的资源
- 允许资源共享：即当一个应用运行时，如果其他队列没有任务执行，则可以使用其他队列。当其他队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源
- 默认不限制每个队列和用户可以同时运行应用的数量：可以配置来限制队列和用户并行执行的应用数量。限制并行执行应用数量不会导致任务提交失败，超出的应用会在队列中等待。
公平调度器的默认配置下：如果目前一个队列中有4个job正在运行，此时来了第5个job，这5个job共同平分整个队列的资源。
与容量调度器相同点：
- 多队列：支持多队列多作业
- 容量保证：管理员可以为每个队列设置资源最低保证、资源使用上限
- 灵活性：如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，而一旦该队列有新的应用程序提交，则其他队列借调的资源会归还给该队列
- 多租户：支持多用户共享集群和多应用程序同时运行；为了防止同一个用户的作业独占队列中的资源，该调度器会对同一个用户提交的作业所占资源量进行限定
公平调度器与容量调度器的核心调度策略不同：
- 容量调度器：优先选择 资源利用率低 的队列
- 公平调度器：优先选择对资源的 缺额 比例大的
公平调度器与容量调度器支持的单独设置资源分配方式不同：
- 容量调度器：FIFO、DRF
- 公平调度器：FIFO、FAIR、DRF
缺额产生的原因：
如果目前一个队列中有4个job正在运行，此时来了第5个job。理想情况下，如果使用公平调度器，第5个job进来之后马上就和前4个job平分整个队列的资源。
但是实际情况中，job5进来之后，只能先得到一点点资源，等待一段时间让其他job释放出一些资源出来。此时，第5个job应该分配的资源和实际得到的资源之间的差额就是缺额。
公平调度器设计目标是：在时间尺度上，所有作业获得公平的资源。调度器会 优先为缺额大的作业分配资源 。
公平调度器的资源分配策略：- FIFO策略：公平调度器每个队列资源分配策略如果选择FIFO的话，此时就相当于是容量调度器
- Fair策略（默认）
- DRF策略
Fair策略：
Fair策略是一种基于最大最小公平算法实现的资源多路复用方式，默认情况下，每个队列内部采用该方式分配资源。这意味着，如果一个队列中有两个应用程序同时运行，则每个应用程序可得到 1/2 的资源；如果三个应用程序同时运行，则每个应用程序可以得到 1/3 的资源。
具体的资源分配流程和容量调度器一致：先选择队列，再选择作业，再选择容器。这三步的每一步都是按照公平策略分配资源。（银行家算法）实际最小资源份额：mindshare = Min(资源需求量, 配置的最小资源)
是否饥饿：isNeedy = 资源使用量 < mindshare
资源分配比：minShareRatio = 资源使用量 / Max(mindshare, 1)
资源使用权重比：useToWeightRatio = 资源使用量 / 权重
DRF策略：（Dominant Resource Fairness）
其他的调度器分配资源时都是单一标准，例如只考虑内存（Yarn默认情况），但是很多时候我们的资源分配要同时兼顾CPU、内存、网络带宽等资源，很难衡量两个应用应该分配的资源比例。
假设集群中的应用A需要2个CPU、300GB内存，应用B需要6个CPU、100G内存，那么意味着应用A是内存主导的，应用B是CPU主导的。针对这种情况，可以选择DFR策略对不同应用进行不同资源的同一个比例限制。4.3、Yarn常用命令
Yarn状态的查询，除了可以在 http://hadoop103:8088（ResourceManager）页面查看外，还可以通过命令操作。
4.3.1、yarn application 查看任务
列出所有的 Application：
# 和浏览器页面看到的All Applications列表相同 yarn application -list- 1
- 2
根据 Application 状态过滤：
# yarn application -list -appStatesyarn application -list -appStates FINISHED - 1
- 2
Kill 掉 Application：
# yarn application -killyarn application -kill application_1653269087987_0001 - 1
- 2
4.3.2、yarn logs 查看日志
查询 Application 日志：
# yarn logs -applicationIdyarn logs -applicationId application_1653269087987_0001 - 1
- 2
查询 Container 日志：
# yarn logs -applicationId-containerId yarn logs -applicationId application_1653269087987_0001 -containerId container_1653269087987_0001_01_000001- 1
- 2
4.3.3、yarn applicationattempt 查看尝试运行的任务
即任务运行过程中的状态。可以获取到任务的AppAttemptID、AppMaster的ContainerID。
列出所有 Application 尝试的列表：
# yarn applicationattempt -listyarn applicationattempt -list application_1653269087987_0001 - 1
- 2
打印 ApplicationAttempt状态：
# yarn applicationattempt -statusyarn applicationattempt -status appattempt_1653269087987_0001_000001 - 1
- 2
4.3.4、yarn container 查看容器
只有在任务运行过程中才能看到的状态，任务运行完成后无法查看Container
列出所有 Container：# yarn container -list- 1
打印Container状态：
# yarn container -status- 1
4.3.5、yarn node 查看节点状态
yarn node -list -all- 1
4.3.6、yarn rmadmin 更新配置
加载队列配置：（重新读了配置文件，可以不停机的情况下重新加载配置参数）
yarn rmadmin -refreshQueues- 1
4.3.7、yarn queue 查看队列
打印队列信息：
# yarn queue -status# 容量调度器、公平调度器都有一个default队列，可以查看该队列信息。也可以根据实际情况增加队列 yarn queue -status default - 1
- 2
- 3
在浏览器页面也可以查看调度器的队列状态：Scheduler -> Application Queues -> 要查看的队列名称
4.4、Yarn生产环境核心配置参数
4.4.1、ResourceManager相关配置
yarn.resourcemanager.scheduler.class：配置调度器，Apache版默认容量调度器，CDH版默认公平调度器yarn.resourcemanager.scheduler.client.thread-count：ResourceManager处理调度器请求的线程数量，默认50
4.4.2、NodeManager相关配置
CPU配置：
yarn.nodemanager.resource.detect-hardware-capabilities：是否让yarn自己检测硬件进行配置，默认falseyarn.nodemanager.resource.count-logical-processors-as-cores：是否将虚拟核数当做cpu核数，默认falseyarn.nodemanager.resource.pcores-vcores-multiplier：虚拟核数和物理核数乘数，默认值1。例如：4核8线程，该参数就应该设置为2yarn.nodemaager.resource.cpu-vcores：NodeManager使用的cpu核数，默认8个
内存配置：
yarn.nodemanager.resource.memory-mb：NodeManager使用内存，默认8G。和system-reserved-memory-mb只需要配置其中一个yarn.nodemanager.resource.system-reserved-memory-mb：NodeManager为系统保留多少内存。和memory-mb只需要配置其中一个yarn.nodemanager.pmem-check-enabled：是否开启物理内存检查限制Container，默认打开。检查到超过限制时作业将被kill停止。yarn.nodemanager.vmem-check-enabled：是否开启虚拟内存检查限制Container，默认打开yarn.nodemanager.vmem-pmem-ration：虚拟内存物理内存比例，默认2.1 \
4.4.3、Container相关配置
内存配置：
yarn.scheduler.minimum-allocation-mb：容器最小内存，默认1Gyarn.scheduler.maximum-allocation-mb：容器最大内存，默认8G
CPU配置：yarn.scheduler.minimum-allocation-vcores：容器最小CPU核数，默认1个yarn.scheduler.maximum-allocation-vcores：容器最大CPU核数，默认4个
4.5、配置案例
4.5.1、Yarn配置
例如：从 1G 数据中，统计每个单词出现次数。
服务器：3台，每台4G内存，每台4核4线程的CPU
分析：
1G / 128M（切片大小） = 8 个MapTask；
统计单词个数，可以输出到一个结果文件，即 1 个ReduceTask；
统计单词个数只需要一个MapReduce任务，所以 MRAppMaster 1个；
共计需要 8 + 1 + 1 = 10 个Container。
平均每个 NodeManager 需要运行 ： 10个 / 3 台 = 3 个任务（4 / 3 / 3）修改yarn-site.xml配置：
<property> <description>The class to use as the resource scheduler.description> <name>yarn.resourcemanager.scheduler.classname> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacitySchedulervalue> property> <property> <description>Number of threads to handle scheduler interface.description> <name>yarn.resourcemanager.scheduler.client.thread-countname> <value>8value> property> <property> <description>Enable auto-detection of node capabilities such as memory and CPU.description> <name>yarn.nodemanager.resource.detect-hardware-capabilitiesname> <value>falsevalue> property> <property> <description>Flag to determine if logical processors(such as hyperthreads) should be counted as cores. Only applicable on Linux when yarn.nodemanager.resource.cpu-vcores is set to -1 and yarn.nodemanager.resource.detect-hardware-capabilities is true. description> <name>yarn.nodemanager.resource.count-logical-processors-as-coresname> <value>falsevalue> property> <property> <description>Multiplier to determine how to convert phyiscal cores to vcores. This value is used if yarn.nodemanager.resource.cpu-vcores is set to -1(which implies auto-calculate vcores) and yarn.nodemanager.resource.detect-hardware-capabilities is set to true. The number of vcores will be calculated as number of CPUs * multiplier. description> <name>yarn.nodemanager.resource.pcores-vcores-multipliername> <value>1.0value> property> <property> <description>Amount of physical memory, in MB, that can be allocated for containers. If set to -1 and yarn.nodemanager.resource.detect-hardware-capabilities is true, it is automatically calculated(in case of Windows and Linux). In other cases, the default is 8192MB. description> <name>yarn.nodemanager.resource.memory-mbname> <value>4096value> property> <property> <description>Number of vcores that can be allocated for containers. This is used by the RM scheduler when allocating resources for containers. This is not used to limit the number of CPUs used by YARN containers. If it is set to -1 and yarn.nodemanager.resource.detect-hardware-capabilities is true, it is automatically determined from the hardware in case of Windows and Linux. In other cases, number of vcores is 8 by default.description> <name>yarn.nodemanager.resource.cpu-vcoresname> <value>4value> property> <property> <description>The minimum allocation for every container request at the RM in MBs. Memory requests lower than this will be set to the value of this property. Additionally, a node manager that is configured to have less memory than this value will be shut down by the resource manager.description> <name>yarn.scheduler.minimum-allocation-mbname> <value>1024value> property> <property> <description>The maximum allocation for every container request at the RM in MBs. Memory requests higher than this will throw an InvalidResourceRequestException.description> <name>yarn.scheduler.maximum-allocation-mbname> <value>2048value> property> <property> <description>The minimum allocation for every container request at the RM in terms of virtual CPU cores. Requests lower than this will be set to the value of this property. Additionally, a node manager that is configured to have fewer virtual cores than this value will be shut down by the resource manager.description> <name>yarn.scheduler.minimum-allocation-vcoresname> <value>1value> property> <property> <description>The maximum allocation for every container request at the RM in terms of virtual CPU cores. Requests higher than this will throw an InvalidResourceRequestException.description> <name>yarn.scheduler.maximum-allocation-vcoresname> <value>2value> property> <property> <description>Whether virtual memory limits will be enforced for containers.description> <name>yarn.nodemanager.vmem-check-enabledname> <value>falsevalue> property> <property> <description>Ratio between virtual memory to physical memory when setting memory limits for containers. Container allocations are expressed in terms of physical memory, and virtual memory usage is allowed to exceed this allocation by this ratio. description> <name>yarn.nodemanager.vmem-pmem-rationame> <value>2.1value> property>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
4.5.2、容量调度器多队列提交案例
容量调度器一般在中小型公司中使用。
4.5.2.1、多队列配置
生产环境配置调度器多队列：
- 调度器默认只有1个default队列，不能满足生产要求
- 可以按照框架区分多队列，例如创建：hive队列、spark队列、flink队列等，每个框架的任务放入指定的队列（企业里面很少使用这中方式）
- 可以按照业务模块区分多队列，例如创建：登录模块队列、购物车队列、下单队列、部门1队列、部门2队列等
创建多队列的优势：
- 防止程序中出现递归死循环等代码，把所有的资源全部耗尽
- 实现任务的 降级 使用，特殊时期可以保证重要的任务队列资源充足
例如：default队列占总内存 40% ，最大资源容量占总资源 60%（即不够的时候最多可以向其他队列借到60%）；hive队列占总内存60%，最大资源容量占总资源 80%（即不够的时候最多可以向其他队列借到80%）。配置队列的优先级。
配置多队列的容量调度器，在 $HADOOP_HOME/etc/hadoop/capacity-scheduler.xml配置文件中配置。
在 capacity-scheduler.xml中修改配置：
<property> <name>yarn.scheduler.capacity.root.queuesname> <value>default,hivevalue> <description> The queues at the this level (root is the root queue). description> property> <property> <name>yarn.scheduler.capacity.root.default.capacityname> <value>40value> <description>Default queue target capacity.description> property> <property> <name>yarn.scheduler.capacity.root.hive.capacityname> <value>40value> <description>Default queue target capacity.description> property> <property> <name>yarn.scheduler.capacity.root.default.user-limit-factorname> <value>1value> <description> Default queue user limit a percentage from 0.0 to 1.0. description> property> <property> <name>yarn.scheduler.capacity.root.default.user-limit-factorname> <value>1value> <description> Default queue user limit a percentage from 0.0 to 1.0. description> property> <property> <name>yarn.scheduler.capacity.root.default.maximum-capacityname> <value>60value> <description> The maximum capacity of the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.hive.maximum-capacityname> <value>80value> <description> The maximum capacity of the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.statename> <value>RUNNINGvalue> <description> The state of the default queue. State can be one of RUNNING or STOPPED. description> property> <property> <name>yarn.scheduler.capacity.root.hive.statename> <value>RUNNINGvalue> <description> The state of the default queue. State can be one of RUNNING or STOPPED. description> property> <property> <name>yarn.scheduler.capacity.root.default.acl_submit_applicationsname> <value>*value> <description> The ACL of who can submit jobs to the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.hive.acl_submit_applicationsname> <value>*value> <description> The ACL of who can submit jobs to the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.acl_administer_queuename> <value>*value> <description> The ACL of who can administer jobs on the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.hive.acl_administer_queuename> <value>*value> <description> The ACL of who can administer jobs on the default queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.acl_application_max_priorityname> <value>*value> <description> The ACL of who can submit applications with configured priority. For e.g, [user={name} group={name} max_priority={priority} default_priority={priority}] description> property> <property> <name>yarn.scheduler.capacity.root.hive.acl_application_max_priorityname> <value>*value> <description> The ACL of who can submit applications with configured priority. For e.g, [user={name} group={name} max_priority={priority} default_priority={priority}] description> property> <property> <name>yarn.scheduler.capacity.root.default.maximum-application-lifetime name> <value>-1value> <description> Maximum lifetime of an application which is submitted to a queue in seconds. Any value less than or equal to zero will be considered as disabled. This will be a hard time limit for all applications in this queue. If positive value is configured then any application submitted to this queue will be killed after exceeds the configured lifetime. User can also specify lifetime per application basis in application submission context. But user lifetime will be overridden if it exceeds queue maximum lifetime. It is point-in-time configuration. Note : Configuring too low value will result in killing application sooner. This feature is applicable only for leaf queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.maximum-application-lifetime name> <value>-1value> <description> Maximum lifetime of an application which is submitted to a queue in seconds. Any value less than or equal to zero will be considered as disabled. This will be a hard time limit for all applications in this queue. If positive value is configured then any application submitted to this queue will be killed after exceeds the configured lifetime. User can also specify lifetime per application basis in application submission context. But user lifetime will be overridden if it exceeds queue maximum lifetime. It is point-in-time configuration. Note : Configuring too low value will result in killing application sooner. This feature is applicable only for leaf queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.default-application-lifetime name> <value>-1value> <description> Default lifetime of an application which is submitted to a queue in seconds. Any value less than or equal to zero will be considered as disabled. If the user has not submitted application with lifetime value then this value will be taken. It is point-in-time configuration. Note : Default lifetime can't exceed maximum lifetime. This feature is applicable only for leaf queue. description> property> <property> <name>yarn.scheduler.capacity.root.default.default-application-lifetime name> <value>-1value> <description> Default lifetime of an application which is submitted to a queue in seconds. Any value less than or equal to zero will be considered as disabled. If the user has not submitted application with lifetime value then this value will be taken. It is point-in-time configuration. Note : Default lifetime can't exceed maximum lifetime. This feature is applicable only for leaf queue. description> property>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
启动wordcount程序，指定提交的队列：
# 指定提交到hive队列 # -D 运行时改变参数值 hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.3.jar wordcount -D mapreduce.job.queuename=hive /input /output- 1
- 2
- 3
如果运行的是自己编写的 java 程序，也可以通过configuration对象指定提交的队列：
// 指定提交到hive队列 configuration.set("mapreduce.job.queuename", "hive");- 1
- 2
4.5.2.1、任务优先级配置
容量调度器支持任务优先级的配置，在资源紧张时，优先级高的任务将优先获取资源。
默认情况下，Yarn将所有任务的优先级限制为0，若想使用任务的优先级功能，必须开放该限制。
修改yarn-site.xml，增加参数：
<property> <name>yarn.cluster.max-application-priorityname> <value>5value> property>- 1
- 2
- 3
- 4
- 5
- 6
当集群中资源不足出现排队时，可以通过调整任务的优先级达到优先执行的目的：
# 在任务启动时就指定任务的优先级 hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.3.jar wordcount -D mapreduce.job.priority=5 /input /output # 也可以通过命令修改正在执行的任务的优先级 yarn application -appID <app_id> -updatePriority 5- 1
- 2
- 3
- 4
- 5
4.5.3、公平调度器案例
需求：除了默认的default队列，再创建两个队列，分别是 test 和 tengyer（用户所属组）。希望实现以下效果：若用户提交任务时指定队列，则任务提交到指定队列运行；若未指定队列，test用户提交的任务到 root.group.test 队列运行，tengyer用户提交的任务到 root.group.tengyer队列运行（group为用户所属组）。
公平调度器的配置涉及两个文件：一个是 yarn-site.xml，一个是公平调度器队列分配文件 fair-scheduler.xml（文件名可自定义）。
公平调度器在中大型公司中被广泛使用。
修改yarn-site.xml，进行以下配置：
<property> <name>yarn.resourcemanager.scheduler.classname> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairSchedulervalue> property> <property> <name>yarn.scheduler.fair.allocation.filename> <value>/opt/module/hadoop-3.2.3/etc/hadoop/fair-scheduler.xmlvalue> property> <property> <name>yarn.scheduler.fair.preemptionname> <value>falsevalue> property>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
配置 fair-scheduler.xml：
<allocations> <queueMaxAMShareDefault>0.5queueMaxAMShareDefault> <queueMaxResourcesDefault>4096mb,4vcoresqueueMaxResourcesDefault> <queue name="test"> <minResources>2048mb,2vcoresminResources> <maxResources>4096mb,4vcoresmaxResources> <maxRunningApps>4maxRunningApps> <maxAMShare>0.5maxAMShare> <weight>1.0weight> <schedulingPolicy>fairschedulingPolicy> queue> <queue name="tengyer" type="parent"> <minResources>2048mb,2vcoresminResources> <maxResources>4096mb,4vcoresmaxResources> <maxRunningApps>4maxRunningApps> <weight>1.0weight> <schedulingPolicy>fairschedulingPolicy> queue> <queuePlacementPolicy> <rule name="specified" create="false" /> <rule name="nestedUserQueue" create="true"> <rule name="primaryGroup" create="false" /> rule> <rule name="reject" /> queuePlacementPolicy> allocations>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
根据配置的分配策略，如果指定了队列，那么会到指定的队列中执行。但是如果指定的队列不存在，则不允许创建队列。
hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.3.jar wordcount -D mapreduce.job.queuename=root.test /input /output- 1
根据前面配置的策略，如果不指定队列，则提交到对应用户名称的队列，即root.tengyer.tengyer队列（root.用户组.用户名）：
-
相关阅读:
【Java校招面试】实战面经（十）
【算法leetcode】2331. 计算布尔二叉树的值（多语言实现）
专业韩语论文翻译，论文中译韩哪里比较专业？
Servlet运行原理_API详解_请求响应构造进阶之路(Servlet_2)
【Java程序员面试专栏 算法思维】五 高频面试算法题：贪心算法
前端小技巧: 拍平数组的6种常见方法
23、Flink TaskManager 内存调优
Linux：非常实用的Linux命令
uniapp:在HBuilderX里使用夜神模拟器
第三十九回：Snackbar Widget
- 原文地址：https://blog.csdn.net/lushixuan12345/article/details/126696488
