Azkaban 使用问题及解决
1. Azkaban是什么?
Azkaban是由Linkedin公司推出的一个批量工作流任务调度器,主要用于在一个工作流内以一个特定的顺序运行一组工作和流程,它的配置是通过简单的key:value对的方式,通过配置中的dependencies 来设置依赖关系,这个依赖关系必须是无环的,否则会被视为无效的工作流。Azkaban使用job配置文件建立任务之间的依赖关系,并提供一个易于使用的web用户界面维护和跟踪你的工作流。
在介绍Azkaban之前,我们先来看一下现有的两个工作流任务调度系统。知名度比较高的应该是Apache Oozie,但是其配置工作流的过程是编写大量的XML配置,而且代码复杂度比较高,不易于二次开发。另外一个应用也比较广泛的调度系统是Airflow,但是其开发语言是Python。由于我们团队内部使用Java作为主流开发语言,所以选型的时候就被淘汰掉了。我们选择Azkaban的原因基于以下几点:
提供功能清晰,简单易用的Web UI界面
提供job配置文件快速建立任务和任务之间的依赖关系
提供模块化和可插拔的插件机制,原生支持command、Java、Hive、Pig、Hadoop
基于Java开发,代码结构清晰,易于二次开发
2. Azkaban的适用场景
实际项目中经常有这些场景:每天有一个大任务,这个大任务可以分成A,B,C,D四个小任务,A,B任务之间没有依赖关系,C任务依赖A,B任务的结果,D任务依赖C任务的结果。一般的做法是,开两个终端同时执行A,B,两个都执行完了再执行C,最后再执行D。这样的话,整个的执行过程都需要人工参加,并且得盯着各任务的进度。但是我们的很多任务都是在深更半夜执行的,通过写脚本设置crontab执行。其实,整个过程类似于一个有向无环图(DAG)。每个子任务相当于大任务中的一个流,任务的起点可以从没有度的节点开始执行,任何没有通路的节点之间可以同时执行,比如上述的A,B。总结起来的话,我们需要的就是一个工作流的调度器,而Azkaban就是能解决上述问题的一个调度器。
3. Azkaban架构
Azkaban在LinkedIn上实施,以解决Hadoop作业依赖问题。我们有工作需要按顺序运行,从ETL工作到数据分析产品。最初是单一服务器解决方案,随着多年来Hadoop用户数量的增加,Azkaban 已经发展成为一个更强大的解决方案。
Azkaban由三个关键组件构成:
关系型数据库(MySQL)
AzkabanWebServer
AzkabanExecutorServer
3.1 关系型数据库(MySQL)
Azkaban使用数据库存储大部分状态,AzkabanWebServer和AzkabanExecutorServer都需要访问数据库。
AzkabanWebServer使用数据库的原因如下:
项目管理:项目、项目权限以及上传的文件。
执行流状态:跟踪执行流程以及执行程序正在运行的流程。
以前的流程/作业:通过以前的作业和流程执行以及访问其日志文件进行搜索。
计划程序:保留计划作业的状态。
SLA:保持所有的SLA规则
AzkabanExecutorServer使用数据库的原因如下:
访问项目:从数据库检索项目文件。
执行流程/作业:检索和更新正在执行的作业流的数据
日志:将作业和工作流的输出日志存储到数据库中。
交互依赖关系:如果一个工作流在不同的执行器上运行,它将从数据库中获取状态。
3.2 AzkabanWebServer
AzkabanWebServer是整个Azkaban工作流系统的主要管理者,它负责project管理、用户登录认证、定时执行工作流、跟踪工作流执行进度等一系列任务。同时,它还提供Web服务操作的接口,利用该接口,用户可以使用curl或其他ajax的方式,来执行azkaban的相关操作。操作包括:用户登录、创建project、上传workflow、执行workflow、查询workflow的执行进度、杀掉workflow等一系列操作,且这些操作的返回结果均是json的格式。并且Azkaban使用方便,Azkaban使用以.job为后缀名的键值属性文件来定义工作流中的各个任务,以及使用dependencies属性来定义作业间的依赖关系链。这些作业文件和关联的代码最终以*.zip的方式通过Azkaban UI上传到Web服务器上。
3.3 AzkabanExecutorServer
以前版本的Azkaban在单个服务中具有AzkabanWebServer和AzkabanExecutorServer功能,目前Azkaban已将AzkabanExecutorServer分离成独立的服务器,拆分AzkabanExecutorServer的原因有如下几点:
某个任务流失败后,可以更方便的将其重新执行
便于Azkaban升级
AzkabanExecutorServer主要负责具体的工作流的提交、执行,可以启动多个执行服务器,它们通过mysql数据库来协调任务的执行。
1、什么是Azkaban
Azkaban是一款基于Java编写的任务调度系统
任务调度:有四个任务脚A、B、C、D,其中任务A与任务B可以并行运行,然后任务C依赖任务A和任务B的运行结果,任务D依赖任务C的运行结果,此时整个过程可以等效为一个有向无环图,而给所有的任务运行定一个运行规则就可以理解为任务调度。
在任务简单时可以人为控制,但是当任务非常多,依赖复杂时,如果没有清晰的任务规划图,很容易在任务之间形成闭环从而出错,或者多个可并行的任务没有并行执行而浪费资源,这种时候就需要一个工作流调度器,Azkaban就是完成这种任务的。
2、Azkaban分为三个部分:
mysql服务器:用于存储项目、日志或者执行计划之类的信息
web服务器:使用Jetty对外提供web服务,使用户可以通过web页面方便管理
executor服务器:负责具体的工作流的提交、执行
Azkaban服务器交互图
3、基础搭建
首先可从Azkaban官网上下载azkaban,初学时可以只下载
azkaban-web-server-2.5.0.tar.gz,azkaban-executor-server-2.5.0.tar.gz和azkaban-sql-script-2.5.0.tar.gz
三个组件压缩包即可,下载后进行解压
azkaban-sql-script-2.5.0.tar.gz包中包含的都是Azkaban所需用到的所有数据库表的创建语句,在Azkaban 2.5.0版本的这个包中会有一个create-all.sql文件,可以一次性创建好所有的数据库表。
azkaban-web-server-2.5.0.tar.gz解压后在其conf/azkaban.properties文件中可以进行web服务器数据库连接,web访问方式与端口,web访问账号密码,邮件等设置,各位根据自己的实际情况进行配置。
azkaban-executor-server-2.5.0.tar.gz解压后在其conf/azkaban.properties文件中可以进行执行服务器数据库连接,执行服务器线程数等设置。
在这些都设置好以后,浏览器访问对应IP与端口,即可进入Azkaban的web界面了。此时Azkaban的基础搭建基本完成。
4、了解各个元素及其关系
Azkaban界面中的主要元素有三个,分别是project、job与flow
project可以理解为某个项目,其项目中包含了许多需要执行的任务,即为job,各个job之间形成依赖关系,便组成了工作流flow。
5、创建工作 job 与创建工作流 flow
在Azkaban系统的web界面中有创建project的交互,可以通过界面创建一个project,但是Azkaban没有创建job与flow的界面,这一点很讨厌。于是需要编写以.job为扩展名的文件然后上传,才能在系统中形成job任务。
5.1、创建job
首先,需要创建以.job为扩展名的文件,一个文件即代表一个任务。
所有的job都需要一个知道他们如何去执行的type。
一般的,有这样四种job类型:Java、command、javaprocess和pig。
本文以type=command为例
其次在这个文件中添加这个任务所需的参数与参数值,
必须的参数有type与command
例如
type=command
command=echo 'jobs start'
四类job类型的文件都可以添加的参数有
retries --> 任务失败时自动重启的次数
retry.backoff --> 每一次任务尝试重启时之间等待的毫秒数
working.dir --> 可以重新指定任务执行的工作目录,默认为目前正在运行的任务的工作目录
failure.emails --> 任务失败时的邮件提醒设置,以逗号分隔多个邮箱
success.emails --> 任务成功时的邮件提醒设置,以逗号分隔多个邮箱
notify.emails --> 任务无论失败还是成功都邮件提醒设置,以逗号分隔多个邮箱
dependencies--> 定义该文件依赖的文件,值为被依赖文件的文件名,多个目标以逗号分隔,不加扩展名
保存为start.job文件即创建好了一个job
Azkaban每个project中只能上传一个.zip文件
5.2、创建工作流flow
定义好所有的参数后即为定义好了一个job,如果添加了dependencies参数即形成了工作流flow
以开头的任务流为例:
#start.job
type=command
command=echo "jobs start"
#A.job
type=command
command=echo "This A job"
dependencies=start
#B.job
type=command
command=echo "This B job"
dependencies=start
#C.job
type=command
command=echo "This C job"
dependencies=A,B
#D.job
type=command
command=echo "This D job"
dependencies=C
保存好5个文件后,将5文件打包成zip,然后在界面中进行上传,就会将这几个job上传到了系统中,最终呈现
从而一个工作流flow建好。
注意,想多个工作流flow并到一张图中,必须多个工作流flow有一个公共的结束job文件
5.3、创建子工作流subflow及其作用
Azkaban可以给每一个flow设定定时调度,这样就可以等到特定时间运行,然而,这样依旧不能满足一些需求
例如:
一个整个平台的任务调度中,大部分的job任务是根据依赖依次进行,但是有某些个job则依然需要自己的运行设定时间,即上一个job完成后需要等待,不能立即执行下一个job,但是Azkaban给job任务单独设定时后,会覆盖整个任务流flow的设置,所以此时需要引进子任务流subflow
子任务流的创建需要一个job文件,其参数形式为
type= xxx
flow.name= xxx
dependencies= xxx
注意子流文件的参数设置需要遵循:
flow.name为设定的子流subflow的结束job文件的文件名
子流内部的起始文件不存在依赖 ,其依赖关系在type=flow这个文件中设定
子流后面的文件的依赖则为type=flow这个job文件的文件名
所以上面这个例子中
添加一个文件:
#subflow.job
type=flow
flow.name=C
dependencies=start
相应修改文件:
#A.job
type=command
command=echo "This A job"
#B.job
type=command
command=echo "This B job"
#D.job
type=command
command=echo "This D job"
dependencies=subflow
此时工作流会变为
这样在这个project中,就可以分别对两个流进行调度的设定,并且主流中的依赖会等待子流的运行,总体任务调度图也会非常的清晰
5.4、邮件提醒设置
Azkaban自带有邮件提醒功能,在web服务器的conf/azkaban.properties文件中,有以下字段
# mail settings
mail.host=
mail.sender=
mail.user=
mail.password=
job.failure.email=
job.success.email=
job.notify.email=
这里面所有的值都是设定的是邮件的发送者,当初以为是设定接受者,被坑了好久,而邮件的接受者设置则需要前文所说的job文件的failure.emails,success.emails ,notify.emails三个参数,但是这三个属性不是直接加在.job文件中,而是需要在所有.job文件的根目录下创建一个以.properties为扩展名的文件
例如:
# system.properties
success.emails=xxx@xx.com
failure.emails=xxx@xx.com
一些其他需要全局作用的参数也可以添加在这个文件中,此属性文件会作用于全局job文件,一起打包上传即可。这样就可以实现任务成功或失败时的邮件提醒。