工作流调研 oozie vs azkaban

公司内现在已经有团队在使用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主要负责任务的执行
      工作流调研 oozie vs azkaban_第1张图片
      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
  • 应用中有动态参数不好支持

你可能感兴趣的:(工作流调研 oozie vs azkaban)