公司内现在已经有团队在使用Airflow，运维UI界面以及对开发的友好性上貌似都要好于Oozie，本文只针对14年的调研对比结果，有空会对比一下两个系统
流程
- Java主流程代码，Shell/Python代码对主流程调用，完成控制逻辑
- QA需要分别针对Java主流程代码测试，并添加Python代码的测试
- 增加流程需要修改Python控制逻辑，并做整体逻辑回归
- Shell/Python代码的灵活性较高，实现风格迥异，在业务变化比较频繁的情况下，单元测试变化也较大
目标
- 能够增加业务调度的稳定性和健壮性和灵活性
- 将重心放在业务代码的实现上，通过模块化、插件化的方案将业务接入到调度系统中
- 支持流程、业务模块的复用，减少业务平台的开发
- 方便PE的运维，方便日志的查看，方便版本的更新、回滚
- 方便日常运维的操作，支持对流程的启停
- 良好的文档，以及社区有很好的活跃度，长期项目
开源系统
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中
主要概念
- Azkaban
- Job：最小的执行单元，作为DAG的一个结点
- Flow：由多个Job组成，并通过dependent配置Job的依赖属性
- Oozie
- Control 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并初始化数据库，容易出现问题
工作流定义
- Azkaban
- Job和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
- Azkaban
- Azkaban所有任务的提交、监控、执行、编辑都可以通过前端完成
- Oozie
- 只支持Workflow当前以及历史状态的查询
- action的log需要通过oozie提交的hadoop job的日志查看
- cloudera HUE提供了更加nice的UI，支持oozie任务查看、编辑、操作的功能
运维
- Azkaban
- 通过Web端可以完成任务的提交、编辑、执行、查看
- 能够通过Web端完成任务的重启以及暂停
- Oozie
- Oozie原生Web页面能够看到工作流的图形化定义、log日志、workflow状态以及action的执行状态
- 通过HUE可以更加方便的在Web页面上完成workflow的启动、停止、恢复
日志、监控
- Azkaban
- 支持stdout日志的直接输出，支持配置SLA以及邮件报警
- Oozie
- stdout日志只能通过点击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
- 应用中有动态参数不好支持