Oozie任务调度阻塞及内存优化方法

莫叫石榴姐

已于 2022-04-19 13:45:14 修改

阅读量4.1k

点赞数 9

分类专栏：任务调度引擎 Oozie yarn 文章标签： oozie集成大数据 hadoop

于 2020-06-10 16:35:19 首次发布

本文链接：https://blog.csdn.net/godlovedaniel/article/details/106094675

版权

yarn 同时被 3 个专栏收录

5 篇文章 1 订阅

订阅专栏

Oozie

4 篇文章 0 订阅

订阅专栏

任务调度引擎

3 篇文章 0 订阅

订阅专栏

目录

0 引言

1 Oozie的任务调度原理

1.1 Oozie总体架构

1.2 Oozie的执行模型（Action原理）

0 引言

Oozie在执行过程中如果有多个fork产生并行任务的时候，这时会占用很多内存，如果机器的内存不够则会产生调度阻塞。或者是同时提交了多个Oozie任务，也会产生调度阻塞。本文针对上述问题，首先分析研究了Oozie的工作原理及Yarn的运行机制，并基于这两种机制原理的基础上，定位问题所在，实现了上述问题的优化，给出了具体的解决方案，最后对结果进行了验证。

1 Oozie的任务调度原理

1.1 Oozie总体架构

Oozie的总体架构图如下图所示：

由架构图可以看出Oozie主要包含以下几个部分：

（1）Oozie的客户端：可以通过命令行进行提交任务，任务提交的入口，主要进行一些命令行的操作，包括启动一个任务、运行任务、终止任务、恢复任务等操作。Oozie提供了RESTful API接口来接受用户的提交请求(提交工作流作业)。其实，在命令行使用oozie -job xxx命令提交作业，本质上也是发HTTP请求向OozieServer提交作业。

（2）Oozie Server服务器：Oozie Server服务器提供了对应的执行引擎，包括了工作流执行引擎、协调器引擎、bundle引擎。Oozie Server只负责查询这些Action的执行状态和结果，从而降低了Oozie Server的负载。具体的作业不是在Oozie Server中执行， Oozie Server只对workflow负责，而不是对action负责，workflow中的action是在具体集群中某个节点中运行的。真正的作业是交给yarn去执行，yarn将具体的action分配给具有充足资源的节点，让该节点去运行。

（3）元数据库：定义了action执行的一些状态信息，一般存放在Mysql数据库中

（4）hadoop:Oozie是依赖于HDFS进行调度的，际作业的具体执行是由Hadoop执行的，因而Oozie的作业必须放到hadoop集群上。Oozie通过回调和轮询的方式从hadoop集群中获取作业执行结果的。其中，回调是为了降低开销，轮询是为了保证可靠性。用户在HDFS上部署好作业(MR作业)，然后向Oozie提交Workflow，Oozie以异步方式将作业(MR作业)提交给Hadoop。这也是为什么当调用Oozie 的RESTful接口提交作业之后能立即返回一个jobId的原因，用户程序不必等待作业执行完成（因为有些大作业可能会执行很久(几个小时甚至几天)）。Oozie在后台以异步方式，再将workflow对应的Action提交给hadoop执行。（这点可类比kafka，Hbase等，kafka发送端发送数据的时候也是这种异步的策略）

1.2 Oozie的执行模型（Action原理）

oozie的执行模型原理图如下图所示：

（1） Oozie提供了RESTful API接口来接受用户的提交请求(提交工作流作业)。当用户在客户端命令行使用oozie -job xxx命令提交作业，本质上也是发HTTP请求向OozieServer提交作业。

（2）OozieServer收到提交的作业命令后，由工作流引擎负责workflow的执行以及状态的转换。比如，从一个Action执行到下一个Action，或者workflow状态由Suspend变成KILLED。Oozie以异步方式将作业(MR作业)提交给Hadoop。

注：这也是为什么当调用Oozie 的RESTful接口提交作业之后能立即返回一个jobId的原因，用户程序不必等待作业执

行完成（因为有些大作业可能会执行很久(几个小时甚至几天)）。Oozie在后台以异步方式，再将workflow对应的

Action提交给hadoop执行

（3） Oozie通过 launcher job 运行某个具体的Action。launcher job是一个 map-only的MR作业，该作业在集群中的执行也是分布式的。这里的launcher需要向yarn集群申请AM运行，同时真正的任务运行也需要先申请AM。

launcher的作用：

1）监控和运行具体的action
2) 一个action对应一个launcher作业（一个action对应一个job，一个job启动一个oozie-launcher）
3）Launcher job 负责调用对应任务的资源，调用对应的 CLI API 启动 Hadoop、Hive 或者 Pig 作业等等。Launcher job启动的仅是Map的mr作业，这个 Map 作业知道其所对应的工作流中某一个 Action 应该执行的操作，然后实际上执行 Action 操作的 Hadoop 作业将会被启动，你可以认为这些随后启动的作业是 Launcher 作业的子作业。
4）Oozie launcher任务的本质就是启动任务所需要的客户端，如hive任务，启动hive客户端，用于提交任务。
5）除了MR Action外，launcher作业的生命周期和具体任务的生命周期一致。（这点可以在yarn上进行观察）

由launcher任务监控运行具体任务的优势：减少了Oozie Server服务器的压力，使Oozie Server服务器稳定运行。

整个过程源码简单分析如下：

Oozie执行Action时，即ActionExecutor（最主要的子类是JavaActionExecutor，hive、spark等action都是这个类的子类），JavaActionExecutor首先会提交一个LauncherMapper（map任务）到yarn，其中会执行LauncherMain（具体的action是其子类，比如JavaMain、SparkMain等），spark任务会执行SparkMain，在SparkMain中会调用org.apache.spark.deploy.SparkSubmit来提交任务。其实诉我的map任务就是识别你是什么样的任务（hive,shell,spark等），并通过该任务来启动任务所需要的环境来提交任务。提供了提交任务的接口（如hive任务，启动hive客户端或beeline等）。

2 Yarn的资源调度原理

2.1 Yarn的相关定义

Yarn 是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统，而各类运算程序则相当于运行于操作系统之上的应用程序。

YARN 主要由 ResourceManager、NodeManager、ApplicationMaster 和 Container 等组件构成。

具体各个组件之间的含义如下图所示：

2.2 Yarn的运行机制

YARN 的运行机制如下图所示：

yarn的工作原理：

工作机制详解
（0）Mr 程序提交到客户端所在的节点。
（1）Yarnrunner 向 Resourcemanager 申请一个 Application。
（2）rm将该应用程序的资源路径返回给 yarnrunner。
（3）该程序将运行所需资源提交到 HDFS 上。
（4）程序资源提交完毕后，申请运行 mrAppMaster。
（5）RM 将用户的请求初始化成一个 task。
（6）其中一个 NodeManager 领取到 task 任务。
（7）该 NodeManager 创建容器 Container，并产生 MRAppmaster。
（8）Container 从 HDFS 上拷贝资源到本地。
（9）MRAppmaster 向 RM 申请运行 maptask 资源。
（10）RM 将运行 maptask 任务分配给另外两个 NodeManager，另两个 NodeManager 分
别领取任务并创建容器。
（11）MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个 NodeManager
分别启动 maptask，maptask 对数据分区排序。
（12）MrAppMaster 等待所有 maptask 运行完毕后，向 RM 申请容器，运行 reduce task。
（13）reduce task 向 maptask 获取相应分区的数据。
（14）程序运行完毕后，MR 会向 RM 申请注销自己。

以mr作业提交的资源调度进一步说明如下：

（1）作业提交

第 0 步：client 调用 job.waitForCompletion 方法，向整个集群提交 MapReduce 作业。
第 1 步：client 向 RM 申请一个作业 id。
第 2 步：RM 给 client 返回该 job 资源的提交路径和作业 id。
第 3 步：client 提交 jar 包、切片信息和配置文件到指定的资源提交路径。
第 4 步：client 提交完资源后，向 RM 申请运行 MrAppMaster。

（2）作业初始化

第 5 步：当 RM 收到 client 的请求后，将该 job 添加到容量调度器中。
第 6 步：某一个空闲的 NM 领取到该 job。
第 7 步：该 NM 创建 Container，并产生 MRAppmaster。
第 8 步：下载 client 提交的资源到本地。

（3）任务分配

第 9 步：MrAppMaster 向 RM 申请运行多个 maptask 任务资源。
第 10 步：RM 将运行 maptask 任务分配给另外两个 NodeManager，另两个 NodeManager分别领取任务并创建容器。

（4）任务运行

第 11 步：MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个NodeManager 分别启动 maptask，maptask 对数据分区排序。
第12步：MrAppMaster等待所有maptask运行完毕后，向RM申请容器，运行reduce task。
第 13 步：reduce task 向 maptask 获取相应分区的数据。
第 14 步：程序运行完毕后，MR 会向 RM 申请注销自己。

（5）进度和状态更新

YARN 中的任务将其进度和状态(包括 counter)返回给应用管理器, 客户端每秒(通过

mapreduce.client.progressmonitor.pollinterval 设置)向应用管理器请求进度更新, 展示给用户。

（6）作业完成
除了向应用管理器请求作业进度外, 客户端每 5 分钟都会通过调用 waitForCompletion()来检查作业是否完成。时间间隔可以通过 mapreduce.client.completion.pollinterval 来设置。作业完成之后, 应用管理器和 container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

小结： YARN只负责程序运行所需要资源的分配回收等调度任务，和MapReduce程序没有什么耦合。所以许许多多的其他的程序也可以在YARN上运行，比如说Spark，Storm等。yarn并不清楚用户提交的程序的运行机制，yarn只提供运算资源的调度（用户程序向yarn申请资源，yarn就负责分配资源），yarn中的主管角色叫ResourceManager，yarn中具体提供运算资源的角色叫NodeManager，这样一来，yarn其实就与运行的用户程序完全解耦，就意味着yarn上可以运行各种类型的分布式运算程序（mapreduce只是其中的一种），比如mapreduce、storm程序，spark程序等，所以，spark、storm等运算框架都可以整合在yarn上运行，只要他们各自的框架中有符合yarn规范的资源请求机制即可，这样Yarn就成为一个通用的资源调度平台，从此，企业中以前存在的各种运算集群都可以整合在一个物理集群上，提高资源利用率，方便数据共享。

2.3 Yarn的资源调度原理

目前，Hadoop作业调度器主要有三种：FIFO、Capacity Scheduler和Fair Scheduler。Hadoop2.7.2默认的资源调度器是Capacity Scheduler。

具体设置详见：yarn-default.xml文件

<property>
    <description>The class to use as the resource scheduler.</description>
    <name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

1．先进先出调度器（FIFO）

2．容量调度器（Capacity Scheduler）

3．公平调度器（Fair Scheduler）

2.4 Yarn资源管理器参数调优详解

调优的本质是针对container来讲的，因为任务是在Container中运行的，往往是对容器中的核数、内存等进行配置

CPU资源的调度

在yarn中，一个物理core等价于两个vcore，这个在CDH版本的hadoop中有一个参数控制（不要轻易调）
（1）yarn.nodemanager.resource.cpu-vcores
    可为Container分配的容器数量，这个参数在Resource Scheduler为Container分配资源时可以用到。
如果它的值被设置为-1，且参数yarn.nodemanager.resource.detect-hardware-capabilities的值为
true,则不限制yarn使用CPU的数量，也可以设置为8
（2）yarn.nodemanager.resource.detect-hardware-capabilities
    是否自动检测节点的CPU和内存默认为false
（3）yarn.scheduler.minimum-allocation-vcores
    为每个Container分配的最少的vcore,小于这个参数设定的值则会抛出异常默认为1
（4）yarn.scheduler.maximum-allocation-vcores
    为每个Container分配的最多的vcore,大于这个参数设定的值则会抛出异常默认为4(生产调)

Memory资源的调优

（1） NM占用机器的内存大小，单位MB 可设置为50*1024 （生产可根据自己配置调）

yarn.nodemanager.resource.memory-mb

（2）Container包含的最小内存,单位MB 可设置1024（生产可根据自己配置调）

yarn.scheduler.minimum-allocation-mb

（3）Container包含的最大内存,单位MB 可设置8192（生产调）

yarn.scheduler.maximum-allocation-mb

随着任务的运行，计算越来越大，任务消耗的资源越来越多，Container包含的内存也应该逐渐增加，在yarn中有一个参数可以设置每次内存加大的额度(yarn.scheduler.maximum-allocation-mb)，当内存达到参数设置的最大内存还不够时，任务会被yarn杀掉.

（4） Container内存不够用时一次性加多少内存单位MB 可设置2048

yarn.scheduler.increment-allocation-mb

（5）容器是否会执行物理内存限制默认为True
执行物理内存限制时，当Container达到最大物理内存限制时，该参数为True时,会杀死任务

yarn.nodemanager.pmem-check-enabled

（6）容器是否会执行虚拟内存限制默认为True
执行虚拟限制时，当Container达到最大物理虚拟限制时，该参数为True时,会杀死任务

yarn.nodemanager.vmem-check-enabled

（7） 使用虚拟内存和物理内存的比值默认为2.1

yarn.nodemanager.vmem-pmem-ratio

虚拟内存调优

vm.swappiness 的值介于0到100之间
swappiness=0的时候表示最大限度使用物理内存，然后才是swap空间。
swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。
linux的基本默认设置为60。
当任务处于高度计算时，不允许慢，允许挂掉后通过各种形式重启任务,这时候将使用虚拟内存的积极性调低 vm.swappiness 的值可设置较大。当任务在一般计算时，可以慢，不允许挂，这时候将使用虚拟内存的积极性调高。

生产上一般允许慢不允许挂，然后vm.swappiness设置为10。

[root@bigdata3 ~]# cat /proc/sys/vm/swappiness
60
也就是说，你的内存在使用到100-60=40%的时候，就开始会使用虚拟内存。
 
临时调整（重启失效）：
    [root@bigdata3 ~]# sysctl vm.swappiness=10
    vm.swappiness = 10
    [root@timeserver ~]# cat /proc/sys/vm/swappiness
    10
 
永久调整，先完成临时调整，再执行以下操作：
    [root@bigdata3 ~]# vi /etc/sysctl.conf
    # Controls the maximum number of shared memory segments, in pages
    在“kernel.shmall = 4294967296”后加上
    “vm.swappiness=10”
 
    [root@bigdata3 ~]# sysctl -p
    vm.swappiness = 10

在Ambarri平台中可以通过可视化方式对上述参数进行设置。如下图所示：

3 排查与优化方法

3.1 问题原因描述

Oozie在执行过程中如果有多个fork产生并行任务的时候，这时会占用很多内存，如果机器的内存不够则会产生调度阻塞。或者是同时提交了多个Oozie任务，也会产生调度阻塞。由上面Oozie原理分析可以知道，导致Oozie比较占内存的原因是Oozie启动一个任务时会先启动Oozie launcher任务，该任务占内存比较多，Oozie launcher的声明周期是数据任务开始之前到结束，资源不会释放，如果此时数据任务得不到充足的资源就会一直等待有资源过来来执行数据任务，这样就导致了相互等待的过程，造成了死锁现象，导致整个集群陷入阻塞。

3.2 优化方案

（1）Oozie launcher单个占用资源较大会使用2个container，2core，如果一个container默认占2G的话，2个container则占4G

（2）优化方案

减小oozie launcher的资源占用
限制Oozie并发数量
Yarn中设置不同的队列，将Oozie launcher单独作为一个队列，任务作为一个队列。
采用公平调度器。
降低Yarn中Container最小内存限制。

合并HiveQL脚本。

可以将某些步骤合并到同一个HiveQL脚本中，这会降低Oozie轮询YARN的开销。Oozie会向YARN询问一个查询是

否结束，如果是就启动另一个Oozie launcher，然后该Oozie launcher启动另一个Hive会话。当然，对于出现

查询出错的情况，这种合并做法的控制粒度较粗，可能在重新启动动作前需要做一些手工清理的工作。

3.3 Yarn资源队列设置

（1）在Ambarri平台中进行队列配置

（2）设置 yarn.resourcemanager.scheduler.class

org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

（3） Capacity Scheduler，定义ooize、default两个队列，分别占30%及70%。配置内容如下：

capacity-scheduler=null
yarn.scheduler.capacity.default.minimum-user-limit-percent=100
yarn.scheduler.capacity.maximum-am-resource-percent=0.4
yarn.scheduler.capacity.maximum-applications=10000
yarn.scheduler.capacity.node-locality-delay=40
yarn.scheduler.capacity.root.accessible-node-labels=*
yarn.scheduler.capacity.root.acl_administer_queue=*
yarn.scheduler.capacity.root.capacity=100
yarn.scheduler.capacity.root.default.acl_administer_jobs=*
yarn.scheduler.capacity.root.default.acl_submit_applications=*
yarn.scheduler.capacity.root.default.capacity=70
yarn.scheduler.capacity.root.default.maximum-capacity=70
yarn.scheduler.capacity.root.default.state=RUNNING
yarn.scheduler.capacity.root.default.user-limit-factor=1
yarn.scheduler.capacity.root.queues=default,oozie   
yarn.scheduler.capacity.root.oozie.acl_administer_jobs=*
yarn.scheduler.capacity.root.oozie.acl_submit_applications=*
yarn.scheduler.capacity.root.oozie.capacity=30
yarn.scheduler.capacity.root.oozie.maximum-capacity=30
yarn.scheduler.capacity.root.oozie.state=RUNNING
yarn.scheduler.capacity.root.oozie.user-limit-factor=1

（4）配置完后保存并重启Yarn即可生效

3.4 Oozie的调度配置

（1）输入脚本input.sh

#!/bin/sh
chmod 777 -R /tmp
echo var1=test1
echo var2=test2

（2）输出脚本output.sh

#!/bin/sh	

echo $1
echo $2
echo $1 >>/tmp/$1.log  2>&1 ;
echo $2 >>/tmp/$2.log  2>&1 ;

（3）workflow编写

在workflow中配置以下两个参数，用来降低Oozie launcher内存占用

oozie.launcher.mapreduce.map.memory.mb 512 --减少给“hive2等”oozie.launcher作业分配的资源

oozie.launcher.yarn.app.mapreduce.am.resource.mb  512 --减少oozie.launcher使用AppMaster资源的总内存大小。

如果是在oozie.site.xml中配置则是全局作用，在Oozie Workflow中配置则是该任务生效，一般建议在Workflow中配置（比较麻烦）

<!--
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  "License"); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
  测试oozie利用capture-output公共传参，这样可以在第一个脚本中定义hive,过车参数，扳动参数
-->
<workflow-app xmlns="uri:oozie:workflow:0.4" name="get_var">
    <start to="get_var"/>
    <action name="get_var">
        <shell xmlns="uri:oozie:shell-action:0.2">
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <configuration>
                <property>
                    <name>mapred.job.queue.name</name>
                    <value>${queueName}</value>
                </property>
		<property>
                    <name>oozie.launcher.mapred.job.queue.name</name>
                    <value>${launcherName}</value>
                </property>
		<property>
                    <name>oozie.launcher.mapreduce.map.memory.mb</name>
                    <value>512</value>
                </property>
		<property>
                    <name>oozie.launcher.yarn.app.mapreduce.am.resource.mb</name>
                    <value>512</value>
                </property>
            </configuration>
            <exec>input.sh</exec>
	    <file>input.sh</file>
	    <capture-output/> 
        </shell>
        <ok to="use_var"/>
        <error to="fail"/>
    </action>
	<action name="use_var">
        <shell xmlns="uri:oozie:shell-action:0.2">
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <configuration>
                <property>
                    <name>mapred.job.queue.name</name>
                    <value>${queueName}</value>
                </property>
		<property>
                    <name>oozie.launcher.mapred.job.queue.name</name>
                    <value>${launcherName}</value>
                </property>
		<property>
                    <name>oozie.launcher.mapreduce.map.memory.mb</name>
                    <value>512</value>
                </property>
		<property>
                    <name>oozie.launcher.yarn.app.mapreduce.am.resource.mb</name>
                    <value>512</value>
                </property>
            </configuration>
            <exec>output.sh</exec>
	    <argument>${wf:actionData('get_var')['var1']}</argument>
	    <argument>${wf:actionData('get_var')['var2']}</argument>
	    <file>output.sh</file>
        </shell>
        <ok to="end"/>
        <error to="fail"/>
    </action>
    <kill name="fail">
        <message>Shell action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]</message>
    </kill>
    <end name="end"/>
</workflow-app>

（4） job.propertites

nameNode=hdfs://iotcluster:8020
jobTracker=iotcluster:8050
queueName=default
launcherName=oozie
worksRoot=phmworks/apps/shell/TEST_OOZIE/TEST_PARA
user.name=oozie

oozie.wf.application.path=${nameNode}/user/${user.name}/${worksRoot}/workflow.xml

（5）Yarn中容器最小内存限制设置

上述中设置了Oozie launcher启动过程中需要的参数，降低为512M，由于Yarn中容器最小内存限制为1G，此时便会产生冲突，导致了配置参数不会生效，因而需要设置Yarn容器的最小限制。可以对如下参数进行设置，配置为512M

yarn.scheduler.minimum-allocation-mb

或者在自己所在的平台上进行配置，由于我司采用Ambarri平台，因而可配置，如下图所示：

重启服务后参数生效。

3.5 实验结果

实验结果如下：可以看到Oozie launcher在oozie队列中，由原来的4G现在降为1G，任务运行的速度也明显得到提升。

4 小结

针对实际功能工作中Oozie占用内存较大及调度阻塞问题，本文首先分析研究了Oozie的工作原理及Yarn的运行机制，并基于这两种机制原理的基础上，定位问题所在，实现了上述问题的优化，给出了具体的解决方案，并对结果进行了验证。

参考链接：

Hadoop的资源调器-----Yarn的优化_Mr_249的博客-CSDN博客

yarn资源调优的几个参数_阿顾同学的博客-CSDN博客_yarn参数调优

oozie调度阻塞问题_graphnj的博客-CSDN博客

oozie集群阻塞_向阳飞行的博客-CSDN博客

欢迎关注石榴姐公众号"我的SQL呀"，关注我不迷路

莫叫石榴姐

关注

9
点赞
踩
23

收藏

觉得还不错? 一键收藏
0
评论
Oozie任务调度阻塞及内存优化方法

Oozie在执行过程中如果有多个fork产生并行任务的时候，这时会占用很多内存，如果机器的内存不够则会产生调度阻塞。或者是同时提交了多个Oozie任务，也会产生调度阻塞。本文针对上述问题，首先分析研究了Oozie的工作原理及Yarn的运行机制，并基于这两种机制原理的基础上，定位问题所在，实现了上述问题的优化，给出了具体的解决方案，最后对结果进行了验证。
复制链接

扫一扫