之前项目中的sqoop等离线数据迁移job都是利用shell脚本通过crontab进行定时执行，这样实现的话比较简单，但是随着多个job复杂度的提升，无论是协调工作还是任务监控都变得麻烦，我们选择使用oozie来对工作流进行调度监控。在此介绍一下oozie~
在没有工作流调度系统之前，公司里面的任务都是通过crontab来定义的，时间长了后会发现很多问题：
工作流定义： 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可以在继续失败的工作流运行
由于我在安装公司CDH集群时已经安装好oozie了，且有对应的可视化操作工具hue，所以我们直接选择oozie进行工作流调度啦！
简单来说：workflow是对要进行的顺序化工作的抽象，coordinator是对要进行的顺序化的workflow的抽象，bundle是对一堆coordiantor的抽象。层级关系层层包裹。
1、这个文件如果是在本地通过命令行进行任务提交的话，这个文件在本地就可以了，当然也可以放在hdfs上，与workflow.xml和lib处于同一层级。
文件需要被放在HDFS上才能被oozie调度，如果在启动需要调动MR任务，jar包同样需要在hdfs上
在workflow工作流定义的同级目录下，需要有一个lib目录，在lib目录中存在java节点MapReduce使用的jar包。
需要注意的是，oozie并不是使用指定jar包的名称来启动任务的，而是通过制定主类来启动任务的。在lib包中绝对不能存在某个jar包的不同版本，不能够出现多个相同主类。
action节点是workflow触发计算/处理任务执行的机制。Oozie为不同类型的操作提供了支持：Hadoop map-reduce、Hadoop文件系统、Pig、SSH、HTTP、电子邮件和Oozie子工作流。Oozie可以扩展来支持其他类型的操作。
Oozie Workflow可以被参数化（在工作流定义中使用诸如$inputDir之类的变量）。在提交workflow作业值时，必须提供参数。如果适当地参数化（即使用不同的输出目录），几个相同的workflow作业可以并发。
通常，workflow作业是基于常规的时间间隔（time intervals）和数据可用性（data availability）运行的。在某些情况下，它们可以由外部事件触发。
表示触发workflow作业的条件可以被建模为必须满足的谓词（predicate ）。workflow作业是在谓词满足之后开始的。谓词可以引用数据、时间和/或外部事件。在将来，可以扩展模型来支持额外的事件类型。
还需要连接定期运行的workflow作业，但在不同的时间间隔内。多个后续运行的workflow的输出成为下一个workflow的输入。例如，每15分钟运行一次的workflow的4次运行的输出，就变成了每隔60分钟运行一次的workflow的输入。将这些workflow链接在一起会导致它被称为数据应用程序管道。
Oozie Coordinator系统允许用户定义和执行周期性和相互依赖的workflow作业（数据应用程序管道）。
用户将能够在bundle级别启动/停止/暂停/恢复/重新运行，从而获得更好、更容易的操作控制。
更具体地说，oozie Bundle系统允许用户定义和执行一堆通常称为数据管道的Coordinator应用程序。在Bundle中，Coordinator应用程序之间没有显式的依赖关系。然而，用户可以使用Coordinator应用程序的数据依赖来创建隐式数据应用程序管道。
