Oozie调研
在作业设计器中，实用哪种作业工作流的引擎是最主要的，现在对Oozie进行调研。
一．Oozie介绍
Oozie是一种工作流引擎，用于运行MR，Spark Job（有待测试），Pig等任务工作流。它是以Web呈现给用户，运行在Tomcat中。
工作流以多个Action作为组成部分，Action以有向无环图DAG的模式部署运行，工作流通过HDPL（一种类似于XML的自定义处理语言）来构造。
Oozie工作流中的Action在运程系统运行如(Hadoop,Pig服务器上).一旦Action完成,远程服务器将回调Oozie的接口并通知Action已经完成,这时Oozie又会以同样的方式执行工作流中的下一个Action,直到工作流中所有Action都完成(完成包括失败)。
在工作流中主要分为两类工作流点：
|
节点名 |
解析 |
|
可控点（Control flow node） |
这个为Oozie的语法，定义了流开始，结束，失败以及选择（decision），并行（fork），join（合并）的节点。 |
|
Action节点 |
各种不同任务类型的节点如：java，Pig，MR等 |
二．Oozie的搭建
Oozie作为一个Server对外提供Web页面，效果图如下：
上面记录了历史的作业。以及作业的状态。如果运行失败，则节点会报错，不会像Azkaban一样只要执行结束就可返回成功。
Oozie提供了Client用于提交和管理作业，每个作业包含结构如下：
其中:
|
job.properties |
任务的一些配置文件，例如运行的HDFS以及JobTracker (ResourceManager)等 |
|
Lib |
存放执行的JAR包 |
|
Workflow.xml |
工作流的依赖 |
|
****.jar |
执行任务的jar包（自定义的文件） |
这些数据需要上传到HDFS中才可执行。每次执行的任务记录均保存在Mysql数据库中。线下的数据库有其自定义的表来存储用户的操作。
三．任务执行流程：
由于Oozie支持MR等java任务的job，现在测试自定义的spark任务job是否可以提交执行。
3.1 自定义spark任务
使用spark wordcount做为测试代码，定义的job.properties包含：
Namenode节点，设置nameNode和JobTracker以及队列的相关类型。
Workflow.xml：
参数解析：
|
Prepare |
指定了任务在开始之前删除和创建的路径list |
|
Job.xml |
SparkJob的配置 |
|
Configuration |
SparkJob中间运行的配置 |
|
Master |
Spark Master url |
|
Mode |
Client or Cluster，spark运行的driver |
|
Name |
任务名 |
|
Class |
Application的Main Class() |
|
Jar |
依赖的jar或者py文件 |
|
Spark-opts |
传递给spark的其他配置 |
|
Args |
Application的参数 |
配置好当前任务jar，job.properties和workflow.xml之后，将依赖的lib放置在当前文件夹下的lib文件夹下。将此文件夹上传到HDFS中。
3.2 执行任务
在ooize的client端执行：
Oozie job --oozie http://ip:11000/oozie -config ${job.properties} -run
执行之后，可以在web页面查询执行的结果。
可以查看每个job的执行结果以及job的相关信息。在HDFS中也会产生这个job的最终生成文件。
PS.出现错误是因为集群日志问题。
以上的任务执行信息以及任务本身信息都会存储与Mysql Oozie的数据库中，这个数据库在搭建Oozie服务器时创建。
四．代码执行过程：
从oozie的脚本中可以得出其提交的源码入口在：org.apache.oozie.cli.OozieCLI。
当时会生成一个OozieClient，然后使用JobCommand，提交运行的信息到V1JosServlet的doPost接口，在这个接口中会调用submitJob()方法。此时会生成一个DAG对象，然后DAG.submitJon(JobConf,startJob)。
在执行提交的任务时，Oozie会使用Instrumentation进行监控，使用org.apache.oozie.command.wf.SignalXCommand中的execute()方法对WorkFlowJobBean进行提交，MR作业的提交是通过JobClient进行发送同理Spark。（Sqoop的好像是通过Shell有待验证）。
在Oozie为了方便将用户定义的Action以及Workflow进行管理，底层使用Jpa将这些数据存储于数据库中。
五．Oozie和Azkaban的区别：
两者在功能方面大致相同，只是Oozie底层在提交Hadoop Spark作业是通过org.apache.hadoop的封装好的接口进行提交，而Azkaban可以直接操作shell语句。在安全性上可能Oozie会比较好。
工作流定义：Oozie是通过xml定义的而Azkaban为properties来定义。
部署过程：Oozie的部署太虐心了。有点难。同时它是从Yarn上拉任务日志。
Azkaban中如果有任务出现失败，只要进程有效执行，那么任务就算执行成功，这是BUG，但是Oozie能有效的检测任务的成功与失败。
操作工作流：Azkaban使用Web操作。Oozie支持Web，RestApi，Java API操作。
权限控制：Oozie基本无权限控制，Azkaban有较完善的权限控制，入用户对工作流读写执行操作。
Oozie的action主要运行在hadoop中而Azkaban的actions运行在Azkaban的服务器中。
记录workflow的状态：Azkaban将正在执行的workflow状态保存在内存中，Oozie将其保存在Mysql中。
出现失败的情况：Azkaban会丢失所有的工作流，但是Oozie可以在继续失败的工作流运行。
经过调研，Azkaban类似于Oozie，提供了一套有效的Ajax Api，可用于HttpClient进行通信。两类流程引擎，在功能方面大致相似，均可支持spark Job以及Hadoop MR交叉运行，只是Azkaban的操作运行于服务器上而Oozie的操作运行于HDFS中。
但是Azkaban的操作流程比较简易，并且部署过程不像Oozie那样折磨人。比较偏向使用Azkaban作为底层的流程引擎。