azkaban任务调度系统部分功能介绍（使用篇）

2019独角兽企业重金招聘Python工程师标准>>>

这篇文章主要针对azkaban最新版本（3.35.0）的一些常用功能做一些介绍

1.azkaban的command执行模式参数传递

1.1 在job中可以定义运行时需要接受的参数：

#A.job
dateparam=2017-09-09
type=command
command=echo "This A job,current date is:"${dateparam}
command.1= sleep 1

azkaban运行job A时，${dateparam}参数从上面定义的dateparam变量中获取

1.2 管控台界面执行时传参：

#B.job
type=command
command=echo "This B job,runing param:"${testparam}
command.1= sleep 2

job B在执行的时候需要用到${testparam}这个参数，该参数并未指定，需要在执行对应flow的时候动态传递

 

注意：若.job文件中有定义参数，运行时界面上也有传递相同的参数，则对应job会取.job文件中定义的参数，因为运行时界面上传递的是flow param相当于全局变量，而.job文件中定义的参数是针对具体job生效的，相当于局部变量

2.断点续跑功能

其实并没有端点续跑这个专有名词，这是我们自己的说法

在flow C中，job B想要正确运行的话是需要接受运行时参数${testparam}的

首先不传递参数，直接执行，报错相信信息如下

 

因为job A已经成功执行，job B因为没有接收到参数${testparam}而执行失败。job C依赖于job B，因为job B的执行失败而被取消执行，在很多场景下，我们可能会想要重新执行这个flow中失败的job(即我们所说的端点续跑)，azkaban就有提供这个功能，点击History列表中对应的Execution Id,进入执行流程图详情页

点击Prepare Execution，可以看到这时候job A是处于Disable状态的

这时候添加job B所需要的参数，继续执行

再从History列表中进入详情查看，发现azkaban已经将刚才执行失败的job重新执行了一遍：

当然重新执行的，也可以将job A的属性设为Enable，重新执行该flow中的所有job

3.指定某个flow由某台executor主机执行

该功能仅对管理员用户生效

因为我在服务器159和160都部署了executor主机，所以根据job执行的工作目录可以看出来useExecutor参数是否有生效

在数据库中配置了两台executor主机

executorId=1的时候对应的是159，159中executor项目部署在source_buit目录下

执行日志如下：

同理，配useExecutor=2的情况下，该flow将交给160这台主机处理

 

4.人性化的定时任务执行

能够根据flow的通配符设置列出最近的10次flow执行计划

 

在上图中，seconds并没有与列表中10次执行计划对应上（实际上seconds的配置保存后已经写入数据库，仅仅是界面我没有作相应修改，因为测试后秒级别执行并未生效）,是我这边对azkaban源码进行了一个小小的改造，而azkaban本身也只是支持到min，由于azkaban的执行和job实际执行本身存在一定的时间差，所以并不能精确到秒级别，估计这也是azkaban只配置到min的原因，azkaban官方源码的配置如下：

 

 

 

转载于:https://my.oschina.net/u/2988360/blog/1538967