工作流调研 oozie vs azkaban

 clark010 关注2016.03.19 08:58* 字数 1826 阅读 6662评论 1喜欢 11公司内现在已经有团队在使用Airflow，运维UI界面以及对开发的友好性上貌似都要好于Oozie，本文只针对14年的调研对比结果，有空会对比一下两个系统

流程

Java主流程代码，Shell/Python代码对主流程调用，完成控制逻辑
QA需要分别针对Java主流程代码测试，并添加Python代码的测试
增加流程需要修改Python控制逻辑，并做整体逻辑回归
Shell/Python代码的灵活性较高，实现风格迥异，在业务变化比较频繁的情况下，单元测试变化也较大

目标

能够增加业务调度的稳定性和健壮性和灵活性
将重心放在业务代码的实现上，通过模块化、插件化的方案将业务接入到调度系统中
支持流程、业务模块的复用，减少业务平台的开发
方便PE的运维，方便日志的查看，方便版本的更新、回滚
方便日常运维的操作，支持对流程的启停
良好的文档，以及社区有很好的活跃度，长期项目

开源系统

server-sides：Azkaban、Oozie、Luigi
client-sides：Cascading、Hamake

Oozie VS Azkaban

架构

Azkaban主要由三个组件构成：AzkabanWebServer(Jetty)、AzkabanExecutorServer、DataBase(H2/Mysql)
WebServer是整个Azkaban工作流系统的主要管理者,负责project管理、用户登录认证、定时执行工作流、跟踪工作流执行进度等
ExecutorServer主要负责任务的执行


Azkaban组件

Oozie主要部分是Oozie Client、Oozie Server（Tomcat）、DataBase（Debry/Mysql）
Oozie Client完成对workflow进行提交、查询、执行
实现Ooozie向Oozie Server提交一个Workflow(job.property)，Server端收到后会根据workflow xml，提交一个map only的MR Job
Job在map task中通过Hadoop JobClient将action对应的jar/job.xml提交到JobTracker
action job未完成前，map only job一直等待
Oozie server通过callback url通知等待action job的完成
action job执行成功后会将action对应的状态信息保存到DB中

主要概念

AzkabanJob：最小的执行单元，作为DAG的一个结点
Flow：由多个Job组成，并通过dependent配置Job的依赖属性

OozieControl Node：工作流的开始、结束以及决定Workflow的执行路径的节点（start、end、kill、decision、fork/join）
Action Node：工作流执行的计算任务，支持的类型包括（HDFS、MapReduce、Java、Shell、SSH、Pig、Hive、E-Mail、Sub-Workflow、Sqoop、Distcp）
Workflow：由Control Node以及一系列Action Node组成的工作流
Coordinator：根据指定Cron信息触发的workflow
Bundle：按照组的方式批量管理Coordinator任务，实现集中的启停

安装部署

Azkaban部署方便：下载解压，配置连接已有Mysql，并启动WebServer和ExecutorServer
支持solo-server的模式以及multi-server的模式
multi-server模式下需要配置mysql、JobType plugin
配置用户权限

Oozie部署相对复杂，需要配置hadoop的core-site.xml文件增加代理用户的配置，并重启hadoop集群
默认使用derby数据库，推荐使用Mysql数据库
安装环境依赖maven、tomcat、hadoop，同时需要独立安装extJS包
安装之后需要更新sharelib并初始化数据库，容易出现问题

工作流定义

AzkabanJob和Flow的定义直接通过key-value的属性文件配置
Azkaban内建支持的两种JobType只有Shell和Java，其它的JobType需要以插件的形式接入Azkaban
依赖关系直接通过dependent属性配置

Oozie基于hPDL语言描述的配置文件（XML）
通过control flow node以及一系列action node确定一个workflow
Coordinator有两种触发条件：时间触发、数据触发
支持参数化的定义Workflow的配置以及Java EL函数，多种配置传入的方式configure-default.xml
global域
configuration域
job.property

工作流发布

Azkaban将用户定义的job的property配置文件以及依赖的lib都打包在同一个zip中
通过WebUI或者通过ajax接口将zip包提交到WebServer
定时任务的发布需要在WebUI上直接设置

Oozie将workflow、coordinator、bundle的配置以及依赖的lib都放在统一的目录中，并上传到hdfs上
通过job.property配置指定任务的hdfs根路径
通过命令行的方式，将workflow提交

WebUI

AzkabanAzkaban所有任务的提交、监控、执行、编辑都可以通过前端完成

Oozie只支持Workflow当前以及历史状态的查询
action的log需要通过oozie提交的hadoop job的日志查看
cloudera HUE提供了更加nice的UI，支持oozie任务查看、编辑、操作的功能

运维

Azkaban通过Web端可以完成任务的提交、编辑、执行、查看
能够通过Web端完成任务的重启以及暂停

OozieOozie原生Web页面能够看到工作流的图形化定义、log日志、workflow状态以及action的执行状态
通过HUE可以更加方便的在Web页面上完成workflow的启动、停止、恢复

日志、监控

Azkaban支持stdout日志的直接输出，支持配置SLA以及邮件报警

Ooziestdout日志只能通过点击oozie启动的mr-job中查看，ssh action没法查看stdout日志
支持SLA Alters
基础的E-Mail通知，后续可以自定义实现报警的Action
支持JMS API，可以对接JMS provider，由下游自己获取状态并做报警，默认可以配置ActiveMQ

扩展

Azkaban非常好的模块化和插件化的结构，支持自定义JobType或者插件，本身支持的类型并不多

Oozie可以扩展自定义类型的Action
支持自定义EL函数

Oozie方案

使用场景

需要按顺序并能够并行处理的工作流（DAG）
对运行结果或异常需要报警、重启
需要Cron的任务
适用于批量处理的任务，不适合实时的情况

优点

Oozie与Hadoop生态系统紧密结合，提供做种场景的抽象
Oozie有更强大的社区支持，文档
Job提交到hadoop集群，server本身并不启动任何job
通过control node/action node能够覆盖大多数的应用场景
Coordinator支持时间、数据触发的启动模式
支持参数化和EL语言定义workflow，方便复用
结合HUE，能够方便的对workflow查看以及运维
结合HUE，能够完成workflow在前端页面的编辑、提交
支持action之间内存数据的交互（默认2K）
支持workflow的rerun（从某一个节点重启）

缺点

学习门槛比较高，需要丰富的Action配置方法，需要写大量的XML配置
不支持动态的fork，不支持loop
应用中有动态参数不好支持