
1,yarn top: 类似linux里的top命令,查看正在运行的程序资源使用情况
2, yarn queue -status 队列名 :查看指定queue使用情况
3,yarn application -list -appStates ALL,NEW,NEW_SAVING,SUBMITTED,ACCEPTED,RUNNING,FINISHED,FAILED,KILLED
yarn application -list -appTypes [SUBMITTED, ACCEPTED, RUNNING] : 查看app状态
yarn application -movetoqueue application_name -queue 队列名 :移动app到对应的队列
yarn application -kill application_name : kill掉app
yarn application -status application_name :查看app状态
4,yarn applicationattempt -list application_name : 查看app尝试信息
5,yarn classpath --glob : 打印类路径
6,yarn container -list appattempt_name : 打印正在执行任务的容器信息
yarn container -status container_name : 打印当前容器信息
7,yarn jar [mainClass] args : 提交任务到yarn
8,yarn logs -applicationId application_name: 查看app运行日志
9,yarn node -all -list : 查看所有节点信息
10,yarn daemonlog -getlevel n0:8088 rgapachehadoopyarnserverresourcemanagerrmappRMAppImpl : 查看守护进程日志级别
11,yarn resourcemanager [-format-state-store] : RMStateStore的格式化 如果过去的应用程序不再需要,则清理RMStateStore
12, Usage: yarn rmadmin
-refreshQueues 重载队列的ACL,状态和调度器特定的属性,ResourceManager将重载mapred-queues配置文件
-refreshNodes 动态刷新dfshosts和dfshostsexclude配置,无需重启NameNode。
dfshosts:列出了允许连入NameNode的datanode清单(IP或者机器名)
dfshostsexclude:列出了禁止连入NameNode的datanode清单(IP或者机器名)
重新读取hosts和exclude文件,更新允许连到Namenode的或那些需要退出或入编的Datanode的集合。
-refreshUserToGroupsMappings 刷新用户到组的映射。
-refreshSuperUserGroupsConfiguration 刷新用户组的配置
-refreshAdminAcls 刷新ResourceManager的ACL管理
-refreshServiceAclResourceManager 重载服务级别的授权文件。
-getGroups [username] 获取指定用户所属的组。
-transitionToActive [–forceactive] [–forcemanual] 尝试将目标服务转为 Active 状态。如果使用了–forceactive选项,不需要核对非Active节点。如果采用了自动故障转移,这个命令不能使用。虽然你可以重写–forcemanual选项,你需要谨慎。
-transitionToStandby [–forcemanual] 将服务转为 Standby 状态 如果采用了自动故障转移,这个命令不能使用。虽然你可以重写–forcemanual选项,你需要谨慎。
-failover [–forceactive] 启动从serviceId1 到 serviceId2的故障转移。如果使用了-forceactive选项,即使服务没有准备,也会尝试故障转移到目标服务。如果采用了自动故障转移,这个命令不能使用。
-getServiceState 返回服务的状态。(注:ResourceManager不是HA的时候,时不能运行该命令的)
-checkHealth 请求服务器执行健康检查,如果检查失败,RMAdmin将用一个非零标示退出。(注:ResourceManager不是HA的时候,时不能运行该命令的)
-help [cmd]显示指定命令的帮助,如果没有指定,则显示命令的帮助。
==========================================
yarn application
1、-list 列出所有 application 信息
示例:yarn application -list
2、-appStates <States> 跟 -list 一起使用,用来筛选不同状态的 application,多个用","分隔;
所有状态:ALL,NEW,NEW_SAVING,SUBMITTED,ACCEPTED,RUNNING,FINISHED,FAILED,KILLED
示例:yarn application -list -appStates RUNNING
3、-appTypes <Types> 跟 -list 一起使用,用来筛选不同类型的 application,多个用","分隔;
如 MAPREDUCE
示例:yarn application -list -appTypes MAPREDUCE
4、-kill <Application ID> 杀死一个 application,需要指定一个 Application ID
示例:yarn application -kill application_name
5、-status <Application ID> 列出 某个application 的状态
示例:yarn application -status application_name
6、-movetoqueue <Application ID> 移动 application 到其他的 queue,不能单独使用
7、-queue <Queue Name> 与 movetoqueue 命令一起使用,指定移动到哪个 queue
示例:yarn application -movetoqueue application_name -queue other
前言:
上节课我们讲了 MR job的提交YARN的工作流程 与 YARN的架构,本次课程详细讲讲YARN,多多总结。
YARN(主从) 资源 + 作业调度管理
YARN:是一种新的 Hadoop资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
ResourceManager(RM):主要接收客户端任务请求,接收和监控NodeManager(NM)的资源情况汇报,负责资源的分配与调度,启动和监控ApplicationMaster(AM)。
ApplicationManager(作业):应用程序管理,它是负责系统中所有的job,包括job的提交与调度器协商资源来启动ApplicationMaster(AM)和监控(AM)运行状态,并且失败的时候能够重新启动它,更新分配给一个新的Container容器的进度或者状态,除了资源它不管,它就负责job
Scheduler(调度器):更具容量队列的限制条件将我们系统中的资源分配给正在运用的一个应用程序先进先出调度器 :一个作业运行完了,另一个才能运行
yarn的内置调度器:
1FIFO先进先出,一个的简单调度器,适合低负载集群。(适合任务数量不多的情况下使用)
2Capacity调度器,给不同队列(即用户或用户组)分配一个预期最小容量,在每个队列内部用层次化的FIFO来调度多个应用程序。(适用于有很多小的任务跑,需要占很多队列,不使用队列,会造成资源的浪费)
3Fair公平调度器,针对不同的应用(也可以为用户或用户组),每个应用属于一个队列,主旨是让每个应用分配的资源大体相当。(当然可以设置权重),若是只有一个应用,那集群所有资源都是他的。 适用情况:共享大集群、队列之间有较大差别。(生产使用)
capacity调度器的启用:
在ResourceManager节点上的yarn-sitexml设置
Property===>yarnresourcemanagerschedulerclass
Value=====>orgapachehadoopyarnserverresourcemanagerschedulercapacityCapacityScheduler
capacity调度器的配置:
在目录$HADOOP_HOME/hadoop/etc/hadoop/capacity-schedulerxml
修改完成后,需要执行下面的命令:
$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues 使功能动态生效。
NodeManager:主要是节点上的资源和作业管理器,启动Container运行task计算,上报资源、container情况给RM和任务处理情况给AM,整个集群有多个。
ApplicationMaster: 它是负责我们作业的监控并跟踪应用执行状态来重启失败任务的,主要是单个Application(Job)的task管理和调度,向RM进行资源的申请,向NM发出launchContainer指令,接收NM的task处理状态信息。一个job只有一个主程序。
Container: 是YARN中资源的抽象,它封装了某个节点上一定量的资源(CPU和内存两类资源)。
Memory:
yarnnodemanagerresourcememory-mb:6408G=50G (如果内存是64G,Yarn只能用到内存的80%也就是50G)
yarnschedulerminimum-allocation-mb: 1G
yarnschedulermaximum-allocation-mb: 1G 50/1=50(并行度) 数量是多了,并行度大了
一个作业200 MapTask 4轮才能结束,速度快了 作业可能挂了
yarnschedulermaximum-allocation-mb: 16G (生产设16G) 50/16=3(并行度) 数量是少了,并行度小了
一个作业200 MapTask 70轮才能结束,速度慢了 作业时间长 稳定不会挂
工作中一个job可以指定 yarnschedulermaximum-allocation-mb的值,但一般不指定。
若泽大数据实战使用YARN跑一个jar包
先启动Yarn
进入hadoop的bin目录 在hdfs上创建一个新文件夹
创建一个testlog文件
将当前目录中的某个testlog文件复制到hdfs中(注意要确保当前目录中有该文件)
查看hdfs中是否有我们刚复制进去的文件
进入share的上层目录,提交单词统计任务,实验环境下我们的提交差不多在15秒左右
生产环境中,应该是30~50之间,调优可以压到10秒之内
登录网页查看相关信息:>
在MapReduce10中,我们都知道也存在和HDFS一样的单点故障问题,主要是JobTracker既负责资源管理,又负责任务分配。
Yarn中可以添加多种计算框架,Hadoop,Spark,MapReduce,不同的计算框架在处理不同的任务时,资源利用率可能处于互补阶段,有利于提高整个集群的资源利用率。
同时Yarn提供了一种共享集群的模式,随着数据量的暴增,跨集群间的数据移动,需要花费更长的时间,且硬件成本会增大,共享集群模式可以让多种框架共享数据和硬件资源。
整个的调度流程为:
整个集群只有一个,负责集群资源的统一管理和调度
整个集群存在多个,负责单节点资源管理与使用
处理来自ResourceManager的命令
处理来自ApplicationMaster的命令
每一个应用有一个,负责应用程序的管理
数据切分,申请资源,任务监控,任务容错
对任务环境的抽象
ResourceManager存在单点故障,基于Zookeeper实现HA,通常任务失败后,RM将失败的任务告诉AM,RM负责任务的重启,AM来决定如何处理失败的任务。RMAppMaster会保存已经运行完成的Task,重启后无需重新运行。
Yarn采用的双层调度框架,RM将资源分配给AM,AM再将资源进一步分配给Task,资源不够时会为TASK预留,直到资源充足。在Hadoop10中我们分配资源通过slot实现,但是在Yarn中,直接分配资源。
资源调度器有:FIFO,Fair scheduler,Capacity scheduler
Yarn支持CPU和内存两种资源隔离,内存时决定生死的资源,CPU时影响快满的资源,内存隔离采用的是基于线程监控和基于Cgroup的方案。
Tez俗称DAG计算,多个计算作业之间存在依赖关系,并形成一个依赖关系的有向图。
Tez是运行在Yarn上的DAG,动态的生成计算的关系流。
如上图左所示的Top K问题,第一个Mapreduce实现wordcount的功能,第二个Mapreduce只用使用Reduce实现排序的问题,但是在Mapreduce中必须创建两个MapReduce任务,但是在Tez优化后,可以直接再第一个reduce后,不进行输出,直接输出到第二个reduce中,优化了Mapreduce
上图中右为一个HiveQL实现的MapReduce,mapreduce为其创建了4个mapreduce任务,使用Tez可以只使用一个Mapreduce任务。
Tez on Yarn和,mapreduce on Yarn上的作业的流程基本一样。
产生一个Mapreduce任务就提交,影响任务的效率,Tez的优化策略是创建一个ApplicationMaster的缓存池,作业提交到AMppplserver中,预先启动若干ApplicationMaster形成AM缓冲池。
同时ApplicationMaster启动的时候也可以预先启动几个container,做为容器的缓冲池。
此外ApplicationMaster运行完成后,不会马上注销其下的container,而是将其预先分配给正要运行的任务。
Tez的好处就是避免产生较多的Mapreduce任务,产生不必要的网络和磁盘IO
Strom是实时处理永不停止的任务,像流水一样不断的处理任务。
Strom非常类似与MapReduce10的架构,如上图所示。
但是其任务的调度的流程与Mapreduce的不一样。
主要的区别是Strom client可以直接 *** 作 Strom ApplicationMaster
spark克服了MapReduce在迭代式计算和交互式计算方面的不足。
spark中引入了RDD,可以并行计算的数据集合,能够被缓存到能存和硬盘中。
spark on Yarn 和MapReduce on Yarn 基本上类似
MR运行需要进行任务管理和资源管理调度,Yarn只是负责资源管理调度。Mapreduce只是运行在Yarn上的应用。
MapReduce20包括Yarn 和MRMapreduce,所以说Yarn是从MapReudce中独立出来的一个模块。但是现在Yarn已经成为多种计算框架的资源管理器。
MapReduce10是可以直接运行的linux系统上的,因为其自带了JobTracker服务和TaskTracker服务,它们可以自己进行资源管理与任务的分配。
MapReduce20中mapreduce是只有任务管理,所以其必须运行在Yarn上进行资源的调度。
我们在windows开发机上使用spark的local模式读取远程hadoop集群中的hdfs上的数据,这样的目的是方便快速调试,而不用每写一行代码或者一个方法,一个类文件都需要打包成jar上传到linux上,再扔到正式的集群上进行测试,像功能性验证直接使用local模式来快速调测是非常方便的,当然功能测试之后,我们还需要打包成jar仍到集群上进行其他的验证比如jar包的依赖问题,这个在local模式是没法测的,还有集群运行的调优参数,这些都可以在正式仍到集群时验证。
一个样例代码如下:
def main(args: Array[String]): Unit = { //指定local模式
val conf = new SparkConf()setMaster("local[2]")setAppName("read kp data to kafka") val sc= new SparkContext(conf) //支持通配符路径,支持压缩文件读取
val rrd=sctextFile("hdfs://192168104:8020/data/log/{20170227,20170228}/tomcat-log") //提到到集群模式时,去掉uri地址,如果有双namenode,可以自动容灾
//val rrd=sctextFile("/data/log/{20170227,20170228}/tomcat-log")
//统计数量
println(rrdcount()) //停止spark
scstop()
}
如何在spark中遍历数据时获取文件路径:
val path:String="hdfs://192168104:8020/data/userlog/{20170226}/kp"
val text= scnewAPIHadoopFile[LongWritable,Text,TextInputFormat](path)
val linesWithFileNames = textasInstanceOf[NewHadoopRDD[LongWritable, Text]]
mapPartitionsWithInputSplit((inputSplit, iterator) => {
val file = inputSplitasInstanceOf[FileSplit] iteratormap(tup => (filegetPath, tup_2)) // 返回的K=全路径 V=每一行的值
}
)
linesWithFileNamesforeach(println)
如果遍历压缩文件时想要获取文件名,就使用newAPIHadoopFile,此外在本地调试下通过之后,提交到集群运行的时候,一定要把uri去掉,本地加上是想让它远程读取方便调试使用,如果正式运行去掉uri在双namenode的时候可以自动兼容,不去反而成一个隐患了。
最后我们可以通过spark on yarn模式提交任务,一个例子如下:
jars=`echo /home/search/x_spark_job/libs/jar | sed 's/ /,/g'`
bin/spark-submit --class KSearch --master yarn --jars $jars /home/search/x_spark_job/kp-100jar
这里用spark提交有另外一个优势,就是假如我开发的不是YARN应用,就是代码里没有使用SparkContext,而是一个普通的应用,就是读取mysql一个表的数据,写入另外一个mysql,这里跟MR没有关系,但是我依然可以用spark-sumbit提交,这时候是不会提交到YARN上的,但是程序会按普通程序运行,程序依赖的jar包,直接使用--jars传入就行,这一点非常方便,尤其是应用有多个依赖时,比如依赖es,hadoop,hbase,redis,fastjson,我打完包后的程序是瘦身的只有主体jar非常小,依赖的jar我可以不打到主体jar里面,在外部用的时候传入,方便共用并灵活性大大提高。
旧的MapReduce架构
、
在Hadoop20中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container 这样可以精简MapReduce, 使之专注于其擅长的数据处理任务, 将无需考虑资源调度 YARN会管理集群中所有机器的可用计算资源 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Container来给每个应用提供处理能力
在Hadoop集群中,平衡内存(RAM)、处理器(CPU核心)和磁盘的使用是至关重要的,合理规划以免某一项引起瓶颈制约。一般的建议是,一块磁盘和一个CPU核心上配置两个Container会达到集群利用率的最佳平衡,Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装
从可用的硬件资源角度看,要调整群集每个节点Yarn和MapReduce的内存配置到合适的数据,应注意以下几个重要的元素:
保留内存=保留系统内存+保留HBase内存(如果HBase是在同一个节点)
下面的计算是确定每个节点的Container允许的最大数量。
Container数量=min (2 CORES, 18 DISKS, (可用内存)/最低Container的大小)
最低Container的大小 这个值是依赖于可用的RAM数量——在较小的存储节点,最小的Container的大小也应较小。下面的表列出了推荐值:
最后计算的每个Container的内存大小是
每个Container的内存大小 = max(最小Container内存大小, (总可用内存) /Container数))
YARN 的核心就是将jobTracker的功能进行拆解,分成了资源管理和任务调度监控两个进程,一个全局的资源管理和每个作业的管理。ResourceManager和Nodemanager提供了计算资源的分配和管理,ApplicationMaster负责完成程序的运行YARN架构下形成了一个通用的资源管理平台和一个通用的应用计算平,避免了旧架构的单点问题和资源利用率问题,同时也让在其上运行的应用不再局限于MapReduce形式
理想情况下,我们应用对 Yarn 资源的请求应该立刻得到满足,但现实情况资源往往是
有限的,特别是在一个很繁忙的集群,一个应用资源的请求经常需要等待一段时间才能的到
相应的资源。在Yarn中,负责给应用分配资源的就是Scheduler。其实调度本身就是一个
难题,很难找到一个完美的策略可以解决所有的应用场景。为此Yarn提供了多种调度器
和可配置的策略供我们选择。在 Yarn 中有三种调度器可以选择:FIFO Scheduler ,Capacity Scheduler,Fair Scheduler。
Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的 Hadoop 资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处
mapreduce10回顾
1 client 负责把作业提交到集群
2 ResourceManager 负责集群资源的统一管理和调度,承担了 JobTracker 的角色,整个集群只有“一个”,总的来说,RM有以下作用:
3 NodeManager 管理YARN集群中的每个节点。整个集群可以有多个。负责单个节点上资源的管理和使用(具体点说是负责计算节点上container的启动、监控和管理,防止Application Master使用多于它申请到的计算资源)。NM有以下作用
4 ApplicationMaster 每个应用有一个,负责应用程序整个生命周期的管理 。
ApplicationMaster 负责协调来自 ResourceManager 的资源,并通过 NodeManager 监视容器的执行和资源使用(CPU、内存等的资源分配)。请注意,尽管目前的资源比较传统(CPU 核心、内存),但未来会带来支持的新资源类型(比如图形处理单元或专用处理设备)。AM有以下作用:
5 Container 是 YARN 中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。Container有以下作用:
剖析MapReduce作业运行机制
1、作业的提交
2、作业的初始化
3、任务的分配
4、任务的执行
5、进度和状态的更新
6、作业的完成
简单版工作流程
详细版工作流程
步骤1:用户向YARN中提交应用程序,其中包括ApplicationMaster程序、启动ApplicationMaster、用户程序等。
步骤2:ResourceManager为该应用程序分配第一个Container,并与对应的NodeManager通信,要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3:ApplicationMaster首先向ResourceManager注册,这样用户可以直接通过ResourceManager查看应用程序的运行状态,然后它将为各个任务申请资源,并监控他的运行状态,直到运行结束,即要重复步骤4-7。
步骤4:ApplicationMaster采用轮询的方式通过RPC协议找ResourceManager申请和领取资源。
步骤5:一旦Application申请到资源后,便与对应的NodeManager通信,要求启动任务。
步骤6:NodeManager为任务设置好运行环境,包括环境变量、JAR包、二进制程序等,然后将任务启动命令写到另一个脚本中,并通过运行该脚本启动任务。
步骤7:各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度,ApplicationMaster随时掌握各个任务的运行状态,从而可以再任务失败时重新启动任务。在应用程序运行过程中,用户可以随时通过RPC协议ApplicationMaster查询应用程序的当前运行状态。
步骤8:应用程序运行完成后,ApplicationMaster向ResourceManager注销并关闭自己。
1YARN的HA
2hdfs的HA
Namenode和resourcemanager的HA两点最大的不同:
1ZKFC是作为ResourceManager之中的一个进程,而Hadoop中则是一个外置的守护进程
hadoop10到hadoop20的变迁
MapReduce对任务执行的更多控制(暂时不明白)
1调度器基本作用
根据节点资源(slot、container)使用情况和作业的要求,将任务调度到各个节点上执行
2作业调度器考虑的因素
1、作业优先级。作业的优先级越高,它能够获取的资源(slot数目)也越多。Hadoop 提供了5种作业优先级,分别为 VERY_HIGH、HIGH、NORMAL、 LOW、VERY_LOW,通过mapreducejobpriority属性来设置,或者用JobClient的setJobPriority()方法来设置。
2、作业提交时间。顾名思义,作业提交的时间越早,就越先执行。
3、作业所在队列的资源限制。调度器可以分为多个队列,不同的产品线放到不同的队列里运行。不同的队列可以设置一个边缘限制,这样不同的队列有自己独立的资源,不会出现抢占和滥用资源的情况
3Hadoop的自带作业调度器
4如何配置使用调度器?
将其JAR文件放到Hadoop的类路(classpath)
然后设置mapredjobtrackertaskScheduler属性(yarnresourcemanagerschedulerclass)值为orgapachehadoopyarnserverresourcemanagerschedulercapacityCapacityScheduler
Application Master决定如何运行构成MapReduce作业的各个任务。如果作业很小,就选择在与它同一个JVM上运行任务
什么样的作业称为小作业(又叫Uber任务或小任务)?
默认情况下,小作业指小于10个mapper且只有一个reducer且输入大小小于HDFS块的任务。
涉及属性配置如下:
转至: >
hadoop-yarn的主节点resourceManager相当于yarn集群的中央管理器,负责整个集群资源的调度分配工作。那么当主节点down机期间,已发布的应用以及从节点nodeManager是否还可有条不紊的继续工作呢?resourceManager挂掉,又重启后,整个yarn集群又会发生什么样的变化。
>
以上就是关于yarn常用命令全部的内容,包括:yarn常用命令、YARN 生产详解、Yarn资源调度过程详细等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)