Yarn 资源管理

最新推荐文章于 2024-01-20 11:37:31 发布
最新推荐文章于 2024-01-20 11:37:31 发布
阅读量4.7k 收藏 4
点赞数
分类专栏： HDP 平台的运用 文章标签： yarn
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013850277/article/details/78472685
版权
  • 环境说明：HDP2.5 + Ambari 在linux centos6上搭建的集群

一、Yarn 资源管理简述：

yarn默认提供了两种调度规则，capacity scheduler和fair scheduler。
现在使用比较多的是capacity scheduler。具体的实现原理和调度源码可以google一下capacity scheduler。
Capacity调度器说的通俗点，可以理解成一个个的资源队列。这个资源队列是用户自己去分配的。

二、具体的配置详情说明

  • 1、yarn 内存资源分配设置的参数（由于笔者用的Ambari所以可通过界面配置，Yarn–>configk中对应的Scheduler）
yarn.scheduler.capacity.root.queues=default,keyun_user,yunhong_user
yarn.scheduler.capacity.root.default.capacity=30
yarn.scheduler.capacity.root.keyun_user.capacity=40
yarn.scheduler.capacity.root.yunhong_user.capacity=30
yarn.scheduler.capacity.root.keyun_user.acl_submit_applications=keyun_user
yarn.scheduler.capacity.root.yunhong_user.acl_submit_applications=yunhong_user
yarn.scheduler.capacity.queue-mappings=u:hive:keyun_user,u:hbase:yunhong_user

上述参数说明：

yarn.scheduler.capacity.root.queues=default,keyun_user,yunhong_user 
创建三个队列，分别为default,keyun_user,yunhong_user 

yarn.scheduler.capacity.root.default.capacity=30
yarn.scheduler.capacity.root.keyun_user.capacity=40
yarn.scheduler.capacity.root.yunhong_user.capacity=30

队列所占资源使用率分别为30%,40%,30%。 
虽然有了这样的资源分配，但是并不是说提交任务到keyun_user里面， 
它就只能使用40%的资源，即使剩下的60%都空闲着。
它也是能够实现（通过配置）,只要资源实在空闲状态，那么keyun_user就可以使用100%的资源。 
但是一旦其它队列提交了任务，keyun_user就需要在释放资源后，把资源还给其它队列，直到达到预设的配比值。 
粗粒度上资源是按照上面的方式进行，在每个队列的内部，还是按照FIFO的原则来分配资源的。
 yarn.scheduler.capacity.root.keyun_user.acl_submit_applications=keyun_user
yarn.scheduler.capacity.root.yunhong_user.acl_submit_applications=yunhong_user

表示哪些user/group可以往keyun_user或yunhong_user里面提作业
yarn.scheduler.capacity.queue-mappings=u:hive:keyun_user,u:hbase:yunhong_user

设定user/group和queue的映射关系，格式为[u|g]:[name]:[queue_name][,next mapping]*，
如上说明hive这个组件任务自动提交到keyun_user这个队列;
（目前发现这个配置只到hadoop中所对方的各个组件的级别，后期再研究如何到该平台的用户级别的控制）

  • 2、刷新Yarn 对应的配置
    这里写图片描述

    这一步在对yarn配置文件进行重新修改后，刷新配置文件可能会出错，
    那么可以先将配置文件还原回最先原的，重启然后再进行修改，刷新。。。

  • 3、重启需要重启的组件
    笔者这里根据提示对需要重启的进行重启后依然报错，因而笔者将所有组件都停了再重新启动，事实证明这招还挺不错的。

  • 4、验证如下图所示
    通过web 视图验证
    这里写图片描述

以hbase用户执行，因为笔者采用了kerberos的认证机制，因而需要先kinit 进入系统先

[root@hdp36 ~]# kinit -kt /etc/security/keytabs/hbase.service.keytab hbase/hdp36.gzdata.org.cn@org.cn

命令（不指定提交的队列）：

hadoop jar /usr/hdp/2.5.3.0-37/hadoop-mapreduce/hadoop-mapreduce-examples-2.7.3.2.5.3.0-37.jar randomtextwriter -D mapreduce.randomtextwriter.totalbytes=1000000000 /tmp/YCB/Wordcount/Input

若输出目录已存在：

hdfs dfs -rm -r /tmp/YCB/Wordcount/Input

这里写图片描述

结果说明：不指定队列则默认提交至default队列。

往keyun_user

hadoop jar /usr/hdp/2.5.3.0-37/hadoop-mapreduce/hadoop-mapreduce-examples-2.7.3.2.5.3.0-37.jar randomtextwriter -D mapreduce.randomtextwriter.totalbytes=1000000000 -D mapreduce.job.queuename=keyun_user /tmp/YCB/Wordcount/Input2

这里写图片描述

  • 结果说明：指定队列则默认提交至指定队列队列，如果该队列被占用且其他资源也正在执行则需要等待。

通过Ambari 的hive_view提交任务，走mr (不走mr则不会被监控到)，以admin用户执行

SELECT count(id) FROM t_hbase100;

这里写图片描述

  • 结果说明：该脚本是通过admin用户登录进入Ambari，然后再通过Ambari对应的Hive_view附件运行的sql。由于Hive_view运用的是Hive组件，且yarn.scheduler.capacity.queue-mappings=u:hive:keyun_user,u:hbase:yunhong_user的配置说明hive这个组件任务自动提交到keyun_user这个队列。

Hive_view 运行视图如下所示：

这里写图片描述

超过设定值：

SELECT count(id) FROM t_hbase100;

执行的过程中，发现对应的队列超过了设定的值

这里写图片描述

  • 结果说明：虽然有了这样的资源分配，但是并不是说提交任务到keyun_user里面，它就只能使用40%的资源，即使剩下的60%都空闲着。它也是能够实现（通过配置），只要资源实在空闲状态，那么keyun_user就可以使用100%的资源。

附：测试过程中的一些简单测试详情如下：

1、hadoop jar xxx.jar 提交任务

[root@hdp39 ~]# hadoop jar /usr/hdp/2.5.3.0-37/hadoop-mapreduce/hadoop-mapreduce-examples-2.7.3.2.5.3.0-37.jar randomtextwriter -D mapreduce.randomtextwriter.totalbytes=1000000000 /tmp/YCB/Wordcount/Input

  • 通过字节换算这个大概是10G大小：totalbytes=10000000000
    这里写图片描述

  • 当然如果你集群内存比较小，可以适当修改这个输出值的大小，笔者在自己机器输出1G，执行时间20秒左右且发现使用的内存太小，为了方便观察，所以选择10G的输出

  • 通过Yarn web Ui 观察最高可达到83%

这里写图片描述

  • 也可通过Ambari 监控界面取得内存的使用率，如下图所示：

这里写图片描述

若目录已存在则删除存在的目录

[root@hdp39 ~]# hdfs dfs -rm -r /tmp/YCB/Wordcount/Input

如果想停止任务可见如下

1、查看所有job任务

[root@hdp39 ~]# hadoop job -list
DEPRECATED: Use of this script to execute mapred command is deprecated.
Instead use the mapred command for it.

17/09/30 09:29:52 INFO impl.TimelineClientImpl: Timeline service address: http://hdp40:8188/ws/v1/timeline/
17/09/30 09:29:52 INFO client.RMProxy: Connecting to ResourceManager at hdp40/10.194.186.40:8050
17/09/30 09:29:53 INFO client.AHSProxy: Connecting to Application History server at hdp40/10.194.186.40:10200
Total jobs:2
                  JobId      State           StartTime      UserName           Queue      Priority       UsedContainers  RsvdContainers  UsedMem         RsvdMem         NeededMem         AM info
 job_1506582742279_0002    RUNNING       1506734118925          hive         default        NORMAL                   12               0   23552M              0M            23552M      http://hdp40:8088/proxy/application_1506582742279_0002/
 job_1506582742279_0003       PREP       1506734552285          hive         default        NORMAL                    0               0       0M              0M                0M      http://hdp40:8088/proxy/application_1506582742279_0003/

 job_1506582742279_0013       PREP       1506737018883         hbase         default        NORMAL                  N/A             N/A      N/A             N/A               N/A             N/A
  • 注：在整个集群中所有的任务都会归集到hdp40（ResourceManager安装在Hdp40）,本集群是集成了Kerberos，因而在登录服务器所用的验证keytab对应的用户则是后面提交任务的用户人；如验证的keytab为hbase用户，那么后面执行hadoop jar任务的也将是hbase用户] 
kinit -kt /etc/security/keytabs/hbase.service.keytab hbase/hdp42

 job_1506582742279_0013       PREP       1506737018883         hbase         default        NORMAL                  N/A             N/A      N/A             N/A               N/A             N/A

2、删除指定的job任务

[root@hdp39 ~]# hadoop job -kill job_1506582742279_0002 
DEPRECATED: Use of this script to execute mapred command is deprecated.
Instead use the mapred command for it.

17/09/30 09:31:03 INFO impl.TimelineClientImpl: Timeline service address: http://hdp40:8188/ws/v1/timeline/
17/09/30 09:31:03 INFO client.RMProxy: Connecting to ResourceManager at hdp40/10.194.186.40:8050
17/09/30 09:31:03 INFO client.AHSProxy: Connecting to Application History server at hdp40/10.194.186.40:10200
Killed job job_1506582742279_0002

执行过程如下：

[root@hdp39 ~]# hadoop jar /usr/hdp/2.5.3.0-37/hadoop-mapreduce/hadoop-mapreduce-examples-2.7.3.2.5.3.0-37.jar randomtextwriter -D mapreduce.randomtextwriter.totalbytes=10000000000 /tmp/YCB/Wordcount/Input
17/09/30 09:50:17 INFO impl.TimelineClientImpl: Timeline service address: http://hdp40:8188/ws/v1/timeline/
17/09/30 09:50:17 INFO client.RMProxy: Connecting to ResourceManager at hdp40/10.194.186.40:8050
17/09/30 09:50:18 INFO client.AHSProxy: Connecting to Application History server at hdp40/10.194.186.40:10200
Running 9 maps.
Job started: Sat Sep 30 09:50:19 CST 2017
17/09/30 09:50:19 INFO impl.TimelineClientImpl: Timeline service address: http://hdp40:8188/ws/v1/timeline/
17/09/30 09:50:19 INFO client.RMProxy: Connecting to ResourceManager at hdp40/10.194.186.40:8050
17/09/30 09:50:19 INFO client.AHSProxy: Connecting to Application History server at hdp40/10.194.186.40:10200
17/09/30 09:50:19 INFO hdfs.DFSClient: Created HDFS_DELEGATION_TOKEN token 895 for hive on 10.194.186.39:8020
17/09/30 09:50:19 INFO security.TokenCache: Got dt for hdfs://hdp39:8020; Kind: HDFS_DELEGATION_TOKEN, Service: 10.194.186.39:8020, Ident: (HDFS_DELEGATION_TOKEN token 895 for hive)
17/09/30 09:50:20 INFO mapreduce.JobSubmitter: number of splits:9
17/09/30 09:50:20 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1506582742279_0010
17/09/30 09:50:20 INFO mapreduce.JobSubmitter: Kind: HDFS_DELEGATION_TOKEN, Service: 10.194.186.39:8020, Ident: (HDFS_DELEGATION_TOKEN token 895 for hive)
17/09/30 09:50:21 INFO impl.YarnClientImpl: Submitted application application_1506582742279_0010
17/09/30 09:50:21 INFO mapreduce.Job: The url to track the job: http://hdp40:8088/proxy/application_1506582742279_0010/
17/09/30 09:50:21 INFO mapreduce.Job: Running job: job_1506582742279_0010
17/09/30 09:50:30 INFO mapreduce.Job: Job job_1506582742279_0010 running in uber mode : false
17/09/30 09:50:30 INFO mapreduce.Job:  map 0% reduce 0%
17/09/30 09:52:53 INFO mapreduce.Job:  map 11% reduce 0%
17/09/30 09:53:09 INFO mapreduce.Job:  map 33% reduce 0%
17/09/30 09:53:15 INFO mapreduce.Job:  map 44% reduce 0%
17/09/30 09:53:16 INFO mapreduce.Job:  map 56% reduce 0%
17/09/30 09:53:22 INFO mapreduce.Job:  map 67% reduce 0%
17/09/30 09:53:35 INFO mapreduce.Job:  map 78% reduce 0%
17/09/30 09:53:59 INFO mapreduce.Job:  map 89% reduce 0%
17/09/30 09:54:36 INFO mapreduce.Job:  map 100% reduce 0%
17/09/30 09:54:39 INFO mapreduce.Job: Job job_1506582742279_0010 completed successfully
17/09/30 09:54:39 INFO mapreduce.Job: Counters: 32
        File System Counters
                FILE: Number of bytes read=0
                FILE: Number of bytes written=1324305
                FILE: Number of read operations=0
                FILE: Number of large read operations=0
                FILE: Number of write operations=0
                HDFS: Number of bytes read=1080
                HDFS: Number of bytes written=9920096052
                HDFS: Number of read operations=36
                HDFS: Number of large read operations=0
                HDFS: Number of write operations=18
        Job Counters 
                Launched map tasks=9
                Other local map tasks=9
                Total time spent by all maps in occupied slots (ms)=3196786
                Total time spent by all reduces in occupied slots (ms)=0
                Total time spent by all map tasks (ms)=1598393
                Total vcore-milliseconds taken by all map tasks=1598393
                Total megabyte-milliseconds taken by all map tasks=2455131648
        Map-Reduce Framework
                Map input records=9
                Map output records=14746901
                Input split bytes=1080
                Spilled Records=0
                Failed Shuffles=0
                Merged Map outputs=0
                GC time elapsed (ms)=5540
                CPU time spent (ms)=258730
                Physical memory (bytes) snapshot=2548002816
                Virtual memory (bytes) snapshot=29189140480
                Total committed heap usage (bytes)=1590165504
        org.apache.hadoop.examples.RandomTextWriter$Counters
                BYTES_WRITTEN=9663678901
                RECORDS_WRITTEN=14746901
        File Input Format Counters 
                Bytes Read=0
        File Output Format Counters 
                Bytes Written=9920096052
Job ended: Sat Sep 30 09:54:39 CST 2017
The job took 260 seconds.

参考文档如下：

利用yarn capacity scheduler在EMR集群上实现大集群的多租户的集群资源隔离和quota限制

Hadoop作业提交与停止命令

在屋顶听歌
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
分布式资源调度——YARN框架
03-01
本文来自于51cto，ApacheHadoopYARN（YetAnotherResourceNegotiator，另一种资源协调者）是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度.YARN是Hadoop2.x才有的，所以在介绍YARN之前，我们先看一下MapReduce1.x时所存在的问题：单点故障节点压力大不易扩展MapReduce1.x时的架构如下：分布式资源调度——YARN框架可以看到，1.x时也是Master/Slave这种主从结构，在集群上的表现就是一个JobTracker带多个TaskTracker。JobTracker：负责资源管
yarn1.22.4与1.22.5最新安装包windows
09-02
yarn1.22.4与1.22.5最新安装包windows
【YARN】了解 YARN 架构的基础知识
书山有路，学海无涯。记录成长，追逐梦想
01-20 1225
现在我已经让您了解了 YARN 的必要性，接下来让我向您介绍 Hadoop 2.0 的核心组件 YARN。 YARN 允许图形处理、交互式处理、流处理以及批处理等不同的数据处理方法来运行和处理存储在 HDFS 中的数据。因此，YARN 将 Hadoop 开放给 MapReduce 之外的其他类型的分布式应用程序。
YARN动态资源池配置
08-14
YARN动态资源池配置，YARN动态资源池配置，YARN动态资源池配置
05：YARN资源管理系统.zip
03-08
05：YARN资源管理系统
做了这么多年前端，将常见的报错bug总结出来贴给大家吧！
qq_54753561的博客
06-25 2857
做了这么多年前端，将常见的报错bug总结出来贴给大家吧！前端jsbug总结，vuebug，gitbug，webpackbug总结。
YARN动态资源池配置案例
张伟的专栏
05-26 4744
EDH作为统一的企业级数据中心，往往是一个多租户的应用环境。在该环境中，不同用户会同时使用集群资源。如何保证用户数据不被任意篡改？如何保证任务的权限控制 (例如用户A不能任性地取消用户B的任务)？如何确保用户资源使用不超过他们的配额？ 1. 开启HDFS权限检查 (默认是开启的) "Check HDFS Permissions"选中 2.
hadoop集群不用重启集群使配置生效及配置查询
weixin_30902675的博客
05-09 1099
1、修改配置生效 hadoop dfsadmin -refreshNodes 2、查看配置 hdfs:http://172.16.10.10:50070/conf yarn:http://172.16.10.10:8088/conf 转载于:https://www.cnblogs.com/stone1989/p/10840813.html...
yarn的队列
pdn的博客
01-18 4414
文章目录0. 起因1.查看...
【Hadoop】yarn-site.xml配置文件详解
热门推荐
康师傅没有眼泪
10-16 1万+
<-- 允许跨域访问的来源，如果有多个，用逗号(,)分隔 --> <property> <name>hadoop.http.cross-origin.allowed-origins</name> <value>*</value> </property><-- 与 DNS 侦听器应绑定到的网络接口关联的地址。 --> ...
Yarn【常用命令】
m0_64261982的博客
06-06 2004
Yarn常用命令
YARN监控管理与资源管理.pdf
最新发布
04-10
hadoop YARN监控管理与资源管理
[Angular 6] 初学angular，环境全部最新，[ ng serve ] 不能启动，卡在 95% 不动 => 解决方案...
weixin_30644369的博客
09-07 306
2018.9.7 问题描述： 通过ng serve命令启动angular应用时，卡在95%， ctrl+c 停掉后看到错误内容为找不到ng_modules下的angular模块下的package.json文件。 --- 之前在网上下过小demo，依赖包都很旧了，因为时间久远， 但是一切正常可以运行。（使用 cnpm 来复原的包） --- 初学angualr，所有相关的东...
yarn配置文件
weixin_38384296的博客
05-04 5193
yarn现在有两个比较大的版本：yarn1.0和yarn2.0。yarn1.0作为npm的替代方案，能够兼容使用.npmrc配置文件，并且.npmrc的优先级比.yarnrc的优先级更高。但在yarn2.0中，yarn不再支持.npmrc配置文件。 一、yarn1.0和npm yarn1.0和npm，除了以下几点，基本上是一致的（.npmrc配置文件）： 配置文件：yarn的配置文件名为.yarnrc，和npm一样，用户配置文件在~/.yarnrc，项目配置文件在项目根目录下； yarn设置缓存目录的ke
vue项目运行后不能自动打开浏览器问题
yb305
07-20 679
在跟目录下找到config文件下的index.js文件， 找到开发环境下的autoOpenBrowser改为true就可以了
npm run dev和npm run serve 均报错，解决办法
weixin_38345306的博客
06-03 816
已测试，有用 打开package.js文件夹，发现文件夹里的scripts有dev如下图： 原因分析：是因为vue init webpack my-project时，自己又建立一个文件夹,取不到对应的package.js中的dev. 解决方案：cd 项目名—>再执行npm run dev 参考： https://blog.csdn.net/dt1991524/article/details/82985570 ...
【yarn】yarn 命令行查看 资源状态
九师兄
01-11 1万+
这个命令句就可以 , 查看集群的资源情况 , 包括正在使用的情况.如何通过shell 命令或脚本查看剩余的 cpu核心数 和内存。本次是因为yarn界面现场不给开放一个任务总是说资源不足。
2、配置yarn
V_CHENY的博客
08-29 1348
配置yarn集群
yarn的安装及配置
jieshdad的博客
07-07 9216
编辑用户变量里的Path，将相应npm的路径（“C:\Users\用户名\AppData\Roaming\npm”）改为：“node_global的文件路径”这是 Node.js 模块缓存目录，用于存储通过 npm 或 Yarn 安装的模块的缓存文件。当你安装 Node.js 模块时，这些模块会首先被下载到。新建一个变量名为 “NODE_PATH”， 变量值为“node_modules\的目录”用于全局安装的 Node.js 模块的默认目录。标志安装 Node.js 模块时，这些模块将被安装到。
yarn资源管理器介绍
11-19
YARN（Yet Another Resource Negotiator）是Hadoop 2.0中引入的新的资源管理器，它的主要作用是管理集群中的资源和调度任务。YARN由ResourceManager、NodeManager、ApplicationMaster和Container四个核心组件构成。 - ResourceManager：是整个集群的资源管理器，负责协调集群中所有应用程序的资源分配和任务调度。ResourceManager内部包含一个Scheduler（调度器），用于调度各个应用程序的任务。 - NodeManager：是每个节点上的资源管理器，负责启动和监视容器（Container）的资源使用情况，并向ResourceManager及其Scheduler报告使用情况。 - ApplicationMaster：是每个应用程序的管理器，负责与ResourceManager协商资源，并与NodeManager一起执行和监视任务。 - Container：是集群上的可使用资源，包含CPU、内存、磁盘、网络等。 YARN的资源管理方式是基于队列的，即将集群中的资源划分为多个队列，每个队列有独立的资源，队列的结构和资源是可以进行配置的。在YARN中，有一个叫做Capacity Scheduler的调度器，它以队列为单位划分资源。例如，default队列占30%资源，analyst和dev分别占40%和30%资源；且analyst和dev各有两个子队列，子队列在父队列的基础上再分配资源。 总之，YARN是一个高效的资源管理器，可以帮助用户更好地管理集群中的资源和任务，提高集群的利用率和性能。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值