首先本人以前还真不知道Oozie这个东东,经别人说才知道,所以感觉也是比较惭愧。毕竟正在做的项目DIP-DATA-ANALYZE与这个有些共同处,就是提供类似工作流的机制更好的调度任务。不过Oozie支持的更多,支持了pig,直接mr,streaming。我们目前是基于hive的,当然也可以支持streaming,mr,不过目前还没有。
另外一个不同是Oozie使用自定义的xml语言hPDL来定义工作流。工作如何进行全部在配置文件中定义。而DIP-DATA-ANALYZE完全界面化,通过选择原任务来指定这个依赖关系。易用性方面个人觉得我们的使用起来更加方便些。当然一些工作流设计实现上Oozie更加完善。
闲言少说,还是进入主题,介绍下Oozie。
Oozie是一种Java Web应用程序,它运行在Java servlet容器——即Tomcat——中,并使用数据库来存储以下内容:
Oozie工作流是放置在控制依赖DAG(有向无环图 Direct Acyclic Graph)中的一组动作(例如,Hadoop的Map/Reduce作业、Pig作业等),其中指定了动作执行的顺序。我们会使用hPDL(一种XML流程定义语言)来描述这个图。
hPDL是一种很简洁的语言,只会使用少数流程控制和动作节点。控制节点会定义执行的流程,并包含工作流的起点和终点(start、end和fail节点)以及控制工作流执行路径的机制(decision、fork和join节点)。动作节点是一些机制,通过它们工作流会触发执行计算或者处理任务。Oozie为以下类型的动作提供支持: Hadoop map-reduce、Hadoop文件系统、Pig、Java和Oozie的子工作流(SSH动作已经从Oozie schema 0.2之后的版本中移除了)。
所有由动作节点触发的计算和处理任务都不在Oozie之中——它们是由Hadoop的Map/Reduce框架执行的。这种方法让Oozie可以支持现存的Hadoop用于负载平衡、灾难恢复的机制。这些任务主要是异步执行的(只有文件系统动作例外,它是同步处理的)。这意味着对于大多数工作流动作触发的计算或处理任务的类型来说,在工作流操作转换到工作流的下一个节点之前都需要等待,直到计算或处理任务结束了之后才能够继续。Oozie可以通过两种不同的方式来检测计算或处理任务是否完成,也就是回调和轮询。当Oozie启动了计算或处理任务的时候,它会为任务提供唯一的回调URL,然后任务会在完成的时候发送通知给特定的URL。在任务无法触发回调URL的情况下(可能是因为任何原因,比方说网络闪断),或者当任务的类型无法在完成时触发回调URL的时候,Oozie有一种机制,可以对计算或处理任务进行轮询,从而保证能够完成任务。
Oozie工作流可以参数化(在工作流定义中使用像${inputDir}之类的变量)。在提交工作流操作的时候,我们必须提供参数值。如果经过合适地参数化(比方说,使用不同的输出目录),那么多个同样的工作流操作可以并发。
一些工作流是根据需要触发的,但是大多数情况下,我们有必要基于一定的时间段和(或)数据可用性和(或)外部事件来运行它们。Oozie协调系统(Coordinator system)让用户可以基于这些参数来定义工作流执行计划。Oozie协调程序让我们可以以谓词的方式对工作流执行触发器进行建模,那可以指向数据、事件和(或)外部事件。工作流作业会在谓词得到满足的时候启动。
经常我们还需要连接定时运行、但时间间隔不同的工作流操作。多个随后运行的工作流的输出会成为下一个工作流的输入。把这些工作流连接在一起,会让系统把它作为数据应用的管道来引用。Oozie协调程序支持创建这样的数据应用管道。
设计思想
Oozie workflows are actions arranged in a control dependency DAG (Direct Acyclic Graph).
An Oozie workflow may contain the following types of actions nodes: map-reduce, map-reduce streaming, map-reduce pipes, pig, file-system, sub-workflows, java, http (no yet implemented), email (not yet implemented) and ssh (deprecated).
Flow control operations within the workflow can be done using decision, fork and join nodes. Cycles in workflows are not supported.
工作流控制可以通过decision\fork\join等几个节点完成。目前不支持环形工作流.
Actions and decisions can be parameterized with job properties, actions output (i.e. Hadoop counters) and HDFS file information (file exists, file size, etc). Formal parameters are expressed in the workflow definition as ${VAR} variables.
动作和决定可以和job的属性、action的输出(例如计数等)、hdfs的文件信息(是否存在、大小等)一起参数化。这些参数可以使用${var}定义在工作流配置文件中。
A Workflow application is an HDFS directory that contains the workflow definition (anXML file), all the necessary files to run all the actions: JAR files for Map/Reduce jobs, shells for streaming Map/Reduce jobs, native libraries, Pig scripts, and other resource files.
工作流应用是一个包含了工作流定义(xml文件),所有必须的文件的目录,并执行所有的动作。这些必须文件包括jar文件(用来执行mr任务)、shell脚本(用来执行streaming mr 任务)、还有其他的比如本地库、pig脚本以及其他文件。
Running workflow jobs is done via command line tools, a WebServices API or a JavaAPI.
通过命令行工具或者webservice api或java api即可执行工作流。
Monitoring the system and workflow jobs can be done via a web console, the command line tools, the WebServices API and the Java API.
Oozie is a transactional system and it has built in automatic and manual retry capabilities.
通过web控制台、命令行工具、webservice api、java api即可对系统和工作流任务进行监控。Oozie是一个事务系统,其已经内在支持了自动化和手动的重试机制。(这点DIP-DATA-ANALYZE有转发(自动第二次重试),jobtrace(手动重试)也可以支持).
In case of workflow job failure, the workflow job can be rerun skipping previously completed actions, the workflow application can be patched before being rerun.
如果任务失败了,工作流的任务就会略过之前完成的动作重新执行,并且工作流应用在重新运行前可以被修补(这里patched不确定是否这样表达).
目前特性:
参考资料:
官网:http://yahoo.github.com/oozie/
apache:http://incubator.apache.org/oozie/
博客文章:http://blog.sina.com.cn/s/blog_62a9902f01011ccd.html
完结