http://oozie.apache.org/docs/4.0.0/WorkflowFunctionalSpec.html

本文档的目标是定义一个工作流引擎系统，专门协调Hadoop Map/Reduce和Pig作业的执行。
Changelog

0 Definitions

Action: 一个执行/计算任务(Map-Reduce作业、Pig作业、shell命令)。它也可以被称为任务或“动作节点”。
Workflow: 以控制依赖关系DAG（Direct Acyclic Graph，有向无环图）来安排的操作集合。从一个操作到另一个操作的“控制依赖”意味着第二个操作在第一个操作完成之前不能运行。
Workflow Definition: 可执行的工作流程的程序化（programmatic ）描述。
Workflow Definition Language: 用于定义Workflow Definition的语言。
Workflow Job: 工作流定义的可执行实例。
Workflow Engine: 执行工作流作业的系统。它也可以被称为DAG引擎。

1 Specification Highlights

工作流应用程序（Workflow application）是DAG，它协调以下类型的actions：Hadoop、Pig和子工作流。

工作流应用程序中的流程控制操作可以使用decision、fork和join节点来完成。工作流中的循环不受支持。
可以使用job propertites、actions output（ie. Hadoop counters）和file information(文件存在、文件大小等)对action和decision进行参数化。形式参数（formal parameters）在工作流定义中表示为 ${VAR} 变量。
工作流应用程序是一个ZIP文件，它包含工Workflow Definition（一个XML文件）、运行所有action所需的所有文件：用于Map/Reduce作业的JAR文件、用于Streaming Map/Reduce作业的shell、原生库（native libraries）、Pig脚本和其他资源文件。

在运行工作流作业（workflow job）之前，必须在Oozie中部署相应的工作流应用程序。
部署工作流应用程序和运行工作流作业可以通过命令行工具、WS API和Java API来完成。
对系统和工作流作业的监视可以通过web控制台、命令行工具、WS API和Java API来完成。

在提交工作流作业时，必须提供一组属性来解析工作流定义中的所有形式参数。这组属性是Hadoop配置。
工作流作业的可能状态是: PREP , RUNNING , SUSPENDED , SUCCEEDED , KILLED 和FAILED 。
在工作流作业中的操作启动失败的情况下，根据失败的类型，Oozie将尝试自动重试，它将请求手动重试，否则将导致工作流作业失败。
Oozie可以在action 开始/结束/失败（start/end/failure）事件和工作流结束/失败（start/end/failure）事件上发出HTTP回调通知。

在工作流作业失败的情况下，可以跳过以前完成的操作重新提交工作流作业。在重新提交之前，可以使用补丁更新工作流应用程序，以修复工作流应用程序代码中的问题。

2 Workflow Definition

工作流定义（workflow definition）是一个DAG，包含控制流程节点（start, end, decision, fork, join, kill）（开始、结束、决策、分叉、连接、终止）或 操作节点（map-reduce、pig等），节点由转换箭头连接。
工作流定义语言（workflow definition language）是基于XML的，它被称为hPDL (Hadoop Process Definition Language)。
Refer to the Appendix A for theOozie Workflow Definition XML Schema . Appendix B has Workflow Definition Examples .

2.1 Cycles in Workflow Definitions

Oozie不支持工作流定义中的循环，工作流定义必须是严格的DAG。
在工作流应用程序部署时，如果Oozie在工作流定义中检测到一个循环，那么它一定会导致部署失败。

3 工作流程节点 - Workflow Nodes

工作流节点分为控制流节点和动作节点：

• Control flow nodes: 控制工作流的开始和结束以及工作流作业执行路径的节点。
• Action nodes: 触发计算/处理任务执行的节点。

节点名和转换（transition，表示节点转换）必须符合以下模式 [a-zA-Z][\-_a-zA-Z0-0]* ，最多20个字符。

3.1 控制流程节点 - Control Flow Nodes

控制流节点定义工作流的开始和结束（ start , end and kill 节点）开始、结束和结束节点)，并提供一种机制来控制工作流执行路径（ decision , fork and join 节点）。

3.1.1 start控制节点 - Start Control Node

start 节点是工作流作业的入口点，它指示工作流作业必须转换到的第一个工作流节点。
当工作流启动时，它会自动转换到 start 节点中指定的节点。
工作流定义必须有一个 start 节点。语法如下：

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
  ...
  <start to="[NODE-NAME]"/>
  ...
</workflow-app>

to 属性是要执行的第一个工作流节点的名称。示例如下：

<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <start to="firstHadoopJob"/>
    ...
</workflow-app>

3.1.2 end控制节点 - End Control Node

end节点是工作流作业的结束，它表示工作流作业已经成功完成。
当一个工作流作业到达 end 时，它就成功地完成了（SUCCEEDED）。
如果工作流作业启动的一个或多个操作在到达 end 节点时正在执行，这些操作将被杀死。在这个场景中，工作流作业仍然被认为是成功运行的。
工作流定义必须有一个 end 节点。语法如下：

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <end name="[NODE-NAME]"/>
    ...
</workflow-app>

name 属性是要做的转换（transition）的名称，以结束工作流作业。示例如下：

<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <end name="end"/>
</workflow-app>

3.1.3 kill控制节点 - Kill Control Node

kill 节点允许工作流作业杀死自己。
当工作流作业到达 kill 节点时，它将错误地结束（KILLED）。
如果到达kill节点时，工作流作业启动的一个或多个操作正在执行，则操作将被杀死。
工作流定义可以有零个或多个kill节点。语法如下：

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <kill name="[NODE-NAME]">
        <message>[MESSAGE-TO-LOG]</message>
    </kill>
    ...
</workflow-app>

kill 节点中的 name 属性是kill操作节点的名称。
message 元素的内容将被记录为工作流作业的终止原因。
kill节点没有转换元素，因为它结束了工作流作业。示例如下：

<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <kill name="killBecauseNoInput">
        <message>Input unavailable</message>
    </kill>
    ...
</workflow-app>

3.1.4 decision控制节点 - Decision Control Node

decision（决策）节点使工作流能够对要遵循的执行路径进行选择。
decision 节点的行为可以看作是开关条件语句（switch-case statement）。
decision 节点由判断-转换对（predicates-transition pairs）列表和默认转换组成。判断将按顺序或表现进行计算，直到其中一个判断的计算结果为true 并执行相应的转换为止。如果没有一个判断计算为true ，则执行default 转换。

判断是 JSP 表达式语言(EL, Expression Language)表达式(请参阅本文档4.2节)，它们解析为布尔值true或false。例如：

${fs:fileSize('/usr/foo/myinputdir') gt 10 * GB}

语法如下：

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <decision name="[NODE-NAME]">
        <switch>
            <case to="[NODE_NAME]">[PREDICATE]</case>
            ...
            <case to="[NODE_NAME]">[PREDICATE]</case>
            <default to="[NODE_NAME]"/>
        </switch>
    </decision>
    ...
</workflow-app>

decision 节点中的 name 属性是决策节点的名称。
每个 case 元素包含了一个判断语句和一个转换的名称。判断 ELs 按顺序计算，直到其中一个返回true并执行相应的转换。
default 元素表示如果所有判断的计算结果都不是true，它作为需要进行的转换。
所有 decision 节点都必须有一个 default 元素，以避免在没有一个判断计算结果为true时将工作流带入错误状态。示例如下：

<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <decision name="mydecision">
        <switch>
            <case to="reconsolidatejob">
              ${fs:fileSize(secondjobOutputDir) gt 10 * GB}
            </case>
            <case to="rexpandjob">
              ${fs:filSize(secondjobOutputDir) lt 100 * MB}
            </case>
            <case to="recomputejob">
              ${ hadoop:counters('secondjob')[RECORDS][REDUCE_OUT] lt 1000000 }
            </case>
            <default to="end"/>
        </switch>
    </decision>
    ...
</workflow-app>

3.1.5 fork和join控制节点 - Fork and Join Control Nodes

fork 节点将一个执行路径分割成多个并发的执行路径。
join 节点等待，直到前一个 fork 节点的每个并发执行路径都到达它。
fork 和 join 节点必须成对使用。 join 节点假设并发执行路径是同一个 fork 节点的子节点。语法如下：

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <fork name="[FORK-NODE-NAME]">
        <path start="[NODE-NAME]" />
        ...
        <path start="[NODE-NAME]" />
    </fork>
    ...
    <join name="[JOIN-NODE-NAME]" to="[NODE-NAME]" />
    ...
</workflow-app>

fork 节点中的 name 属性是工作流fork节点的名称。fork节点中的 path 元素中的 start 属性表示将成为并发执行路径一部分的工作流节点的名称。
join 节点中的name 属性是工作流join节点的名称。在相应的fork的所有并发执行路径到达join节点后，join节点中的 to 属性指明将执行的工作流节点的名称。示例如下：

<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <fork name="forking">
        <path start="firstparalleljob"/>
        <path start="secondparalleljob"/>
    </fork>
    <action name="firstparallejob">
        <map-reduce>
            <job-tracker>foo:8021</job-tracker>
            <name-node>bar:8020</name-node>
            <job-xml>job1.xml</job-xml>
        </map-reduce>
        <ok to="joining"/>
        <error to="kill"/>
    </action>
    <action name="secondparalleljob">
        <map-reduce>
            <job-tracker>foo:8021</job-tracker>
            <name-node>bar:8020</name-node>
            <job-xml>job2.xml</job-xml>
        </map-reduce>
        <ok to="joining"/>
        <error to="kill"/>
    </action>
    <join name="joining" to="nextaction"/>
    ...
</workflow-app>

默认情况下，Oozie会执行一些验证，以确保工作流中的任何分支（forking）都是有效的，不会导致任何不正确的行为或不稳定性。但是，如果Oozie阻止了工作流的提交，而您又非常确定它应该可以工作，那么您可以禁用forkjoin验证，这样Oozie就会接受工作流。
为了一个特定的工作流去禁用校验，在 job.properties 文件中简单地设置 oozie.wf.validate.ForkJoin 为 false 。
为了所有的工作流去禁用校验，在 oozie-site.xml 配置文件中简单地设置 oozie.validate.ForkJoin 为 false 。
禁用此验证是由这两个属性的 AND （与）来决定的，因此，如果其中一个或两个属性都设置为false，那么将禁用此验证；只有当两个属性都设置为true(或未指定)时，才启用此验证。

3.2 工作流action节点 - Workflow Action Nodes

action（操作）节点是工作流触发计算/处理任务执行的机制。

3.2.1 action基础 - Action Basis

以下小节定义所有action类型（如hadoop、pig、shell等）的公共行为和功能。

3.2.1.1 远程 - Action Computation/Processing Is Always Remote

action节点触发的所有计算/处理任务相对Oozie来说都是远程的。在Oozie中不执行特定于工作流应用程序的计算/处理任务。

3.2.1.2 异步 - Actions Are Asynchronous

由action节点触发的所有计算/处理任务都由Oozie异步执行。对于大多数由工作流操作触发的计算/处理任务类型，工作流作业必须等到计算/处理任务完成后，才能转换到工作流中的下一个节点。
有例外的是fs action，作为同步操作处理。
Oozie可以通过回调（callback）和轮询（polling）两种不同的方法来检测计算/处理任务的完成情况。
当Oozie启动计算/处理任务时，Oozie为任务提供一个惟一的回调URL，任务应该调用给定的URL来通知它的完成。
对于任务由于任意原因（例如临时网络故障）未能调用回调URL的情况，或者任务类型（the type of task）在完成时不能调用回调URL的情况，Oozie有一种机制来轮询计算/处理任务以使其完成。

3.2.1.3 Actions Have 2 Transitions, ok and error

如果计算/处理任务（由工作流触发）成功完成，则转换到ok。
如果计算/处理任务（由工作流触发）未能成功完成，则转换为error。
如果一个计算/处理任务出现了错误，那么计算/处理任务必须向Oozie提供error-code和error-message信息。这些信息可以由 decision 节点使用，以此来实现工作流应用程序级别的细粒度错误处理。
每个类型的action必须清楚地定义它所能产生的所有错误代码。

3.2.1.4 恢复 - Action Recovery

Oozie在启动或结束action时提供了恢复功能。
一旦一个action成功启动，如果这个动作在执行过程中失败了，Oozie将不会重试去启动这个action。假设执行操作的外部系统(即Hadoop)有足够的弹性来恢复已经启动的作业(即Hadoop任务重试)。
根据故障的性质，Oozie将有不同的恢复策略。
如果失败是暂时的（of transient nature），Oozie将在预定义的时间间隔之后执行重试。一个类型的action的重试次数和计时器间隔必须在Oozie级别预先配置。工作流作业可以覆盖此类配置。
暂时故障的示例是网络问题或远程系统临时不可用。
如果故障是非瞬态的（of non-transient nature），Oozie将暂停工作流作业，直到手动或程序化干预恢复工作流作业，并且重新尝试action的开始或结束。管理员或外部管理系统的职责是在恢复工作流作业之前执行任何必要的清理工作。
如果故障是一个错误，重试并不能解决问题，Oozie将为action执行错误转换。

3.2.2 Map-Reduce Action

map-reduce操作从工作流中启动Hadoop map/reduce作业。Hadoop作业可以是Java Map/Reduce作业，也可以是流作业。
可以将map-reduce操作配置为在启动map reduce作业之前执行文件系统清理和目录创建。该功能使Oozie能够在临时失败的情况下重试Hadoop作业(Hadoop检查作业输出目录不存在，然后在Hadoop作业启动时创建它，因此不清理作业输出目录的重试将失败)。
工作流作业将等待Hadoop map/reduce作业完成，然后继续执行工作流执行路径中的下一个操作。
Hadoop作业的计数器和作业退出状态( FAILED ， KILLED or SUCCEEDED )必须在Hadoop作业结束后对工作流作业是可用的。可以在decision节点和其他action配置中使用这些信息。
map-reduce操作必须配置所有必要的Hadoop JobConf属性来运行Hadoop map/reduce作业。
Hadoop JobConf属性可以在与工作流应用程序绑定的JobConf XML文件中指定，也可以在map-reduce操作配置中内联地（inline）指定。
配置属性按以下顺序加载： streaming 、 job-xml 和 configuration ，后面的值覆盖前面的值。
streaming和inline属性值可以使用EL表达式参数化(模板化)。
Hadoop mapred.job.tracker 和 fs.default.name 属性不能出现在job-xml和inline配置中。

3.2.2.1 Adding Files and Archives for the Job

file 、 archive 元素为Map-Reduce任务提供可用的files和archives。如果指定的路径是相对的，则假定files或archiver位于应用程序目录中相应的子路径中。如果路径是绝对路径，则files或archive应在给定的绝对路径中。
file 元素指定的 files 将是任务主目录中的符号链接（symbolic links）。
如果一个file是一个本地库(一个 .so 或 .so.# 文件)，它将被符号链接为 .so 文件，.so 文件在任务运行目录下，因此对任务JVM是可用的。
在任务运行目录上为文件强加符号链接，请在符号链接名称后面加上 # 。例如 mycat.sh#cat 。
有关files和archives的更多详细信息，请参阅Hadoop分布式缓存文档。

The file, archive elements make available, to map-reduce jobs, files and archives. If the specified path is relative, it is assumed the file or archiver are within the application directory, in the corresponding sub-path. If the path is absolute, the file or archive it is expected in the given absolute path.
Files specified with the file element, will be symbolic links in the home directory of the task.
If a file is a native library (an ‘.so’ or a ‘.so.#’ file), it will be symlinked as and ‘.so’ file in the task running directory, thus available to the task JVM.
To force a symlink for a file on the task running directory, use a ‘#’ followed by the symlink name. For example ‘mycat.sh#cat’.
Refer to Hadoop distributed cache documentation for details more details on files and archives.

++++++5.2.0中
Configuring the MapReduce action with Java code
可以使用Java代码进一步配置MapReduce操作。如果您已经有MapReduce操作的“驱动程序”代码，如果您更熟悉MapReduce的Java API，如果有些配置需要逻辑，或者有些配置很难用直接的XML(例如Avro)完成，那么这将非常有用。
创建一个类实现 org.apache.oozie.action.hadoop.``OozieActionConfigurator 接口，来自“oozie-sharelib-oozie”artifact。它包含一个接收 JobConf 作为参数的方法。MapReduce操作将使用在这个 JobConf 上设置的任何配置属性。
OozieActionConfigurator有这样的签名：

public interface OozieActionConfigurator {
    public void configure(JobConf actionConf) throws OozieActionConfiguratorException;
}

其中actionConf是JobConf，可以更新。如果您需要抛出一个异常，您可以将其封装在OozieActionConfiguratorException异常中，也可以将其封装在“oozie-sharelib-oozie”artifactt中。
例如:

package com.example;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.mapred.FileInputFormat;
import org.apache.hadoop.mapred.FileOutputFormat;
import org.apache.hadoop.mapred.JobConf;
import org.apache.oozie.action.hadoop.OozieActionConfigurator;
import org.apache.oozie.action.hadoop.OozieActionConfiguratorException;
import org.apache.oozie.example.SampleMapper;
import org.apache.oozie.example.SampleReducer;
public class MyConfigClass implements OozieActionConfigurator {
    @Override
    public void configure(JobConf actionConf) throws OozieActionConfiguratorException {
        if (actionConf.getUser() == null) {
            throw new OozieActionConfiguratorException("No user set");
        }
        actionConf.setMapperClass(SampleMapper.class);
        actionConf.setReducerClass(SampleReducer.class);
        FileInputFormat.setInputPaths(actionConf, new Path("/user/" + actionConf.getUser() 
                                                           + "/input-data"));
        FileOutputFormat.setOutputPath(actionConf, new Path("/user/" + actionConf.getUser() 
                                                           + "/output"));
        ...
    }
}

要在MapReduce操作中使用配置类，只需将它编译成一个jar，使jar对您的action可用，并在 config-class 元素中指定类名(这至少需要schema 0.5):

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:1.0">
    ...
    <action name="[NODE-NAME]">
        <map-reduce>
            ...
            <job-xml>[JOB-XML-FILE]</job-xml>
            <configuration>
                <property>
                    <name>[PROPERTY-NAME]</name>
                    <value>[PROPERTY-VALUE]</value>
                </property>
                ...
            </configuration>
            <config-class>com.example.MyConfigClass</config-class>
            ...
        </map-reduce>
        <ok to="[NODE-NAME]"/>
        <error to="[NODE-NAME]"/>
    </action>
    ...
</workflow-app>

另一个例子可以在Oozie附带的“map-reduce”例子中找到。
一个有用的提示：传递给 configure 方法的初始 JobConf 包含一个工作流中MR操作的 configuration 部分中列出的所有属性。如果你需要传递任何信息到你的OozieActionConfigurator，你可以简单地把它们放在这里。

3.2.2.2 Streaming

可以在 streaming 元素中指定流信息。
mapper 和 reducer 元素用于指定作为mapper和reducer使用的可执行/脚本。
用户定义的脚本必须与工作流应用程序绑定，它们必须在流配置的files元素中声明。如果没有在配置的files元素中声明，则假定它们在Hadoop从机（slave machines）的命令路径中是可用的。
一些流作业要求在HDFS上找到的文件对mapper/reduce脚本可用。这是使用前一节中描述的 file和archive元素完成的。
Mapper/Reducer可以被 job-xml 文件或 configuration 元素中的 mapred.mapper.class 或 mapred.reducer.class 属性覆盖。

3.2.2.3 Pipes

Pipes信息可以在pipes元素中指定。
可以通过元素(map、reduce、inputformat、partitioner、writer、program)指定命令行选项的子集，这些选项可以在使用Hadoop Pipes提交程序时使用。
program元素用于指定要使用的可执行/脚本。
用户定义的程序必须与工作流应用程序绑定。
一些管道作业要求在HDFS上找到的文件对mapper/reduce脚本可用。这是使用前一节中描述的文件和归档元素完成的。
可以通过在job-xml文件或配置元素中指定管道属性来覆盖它们。

3.2.2.4 Syntax

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="[NODE-NAME]">
        <map-reduce>
            <job-tracker>[JOB-TRACKER]</job-tracker>
            <name-node>[NAME-NODE]</name-node>
            <prepare>
                <delete path="[PATH]"/>
                ...
                <mkdir path="[PATH]"/>
                ...
            </prepare>
            <streaming>
                <mapper>[MAPPER-PROCESS]</mapper>
                <reducer>[REDUCER-PROCESS]</reducer>
                <record-reader>[RECORD-READER-CLASS]</record-reader>
                <record-reader-mapping>[NAME=VALUE]</record-reader-mapping>
                ...
                <env>[NAME=VALUE]</env>
                ...
            </streaming>
            <!-- Either streaming or pipes can be specified for an action, not both -->
            <pipes>
                <map>[MAPPER]</map>
                <reduce>[REDUCER]</reducer>
                <inputformat>[INPUTFORMAT]</inputformat>
                <partitioner>[PARTITIONER]</partitioner>
                <writer>[OUTPUTFORMAT]</writer>
                <program>[EXECUTABLE]</program>
            </pipes>
            <job-xml>[JOB-XML-FILE]</job-xml>
            <configuration>
                <property>
                    <name>[PROPERTY-NAME]</name>
                    <value>[PROPERTY-VALUE]</value>
                </property>
                ...
            </configuration>
            <file>[FILE-PATH]</file>
            ...
            <archive>[FILE-PATH]</archive>
            ...
        </map-reduce>        <ok to="[NODE-NAME]"/>
        <error to="[NODE-NAME]"/>
    </action>
    ...
</workflow-app>

prepare 元素(如果存在)指示在开始作业之前要删除的路径列表。这应该专门用于目录清理或删除要执行的作业的hcatalog表分区。删除操作将在hdfs uri的 fs.default.name 文件系统中执行。指定hcatalog表分区URI的格式是 hcat://[metastore server]:[port]/[database name]/[table name]/[partkey1]=[value];[partkey2]=[value] 。对于hcatalog URI, hive-site.xml 需要使用 file 标记来提供，而hcatalog和hive jar需要放在workflow lib目录中，或者使用 archive 标记来指定。

job-xml元素(如果存在)必须引用绑定在工作流应用程序中的Hadoop JobConf job.xml 文件。job-xml元素是可选的，从schema 0.4开始，允许使用多个job-xml元素来指定多个Hadoop JobConf job.xml文件。

configuration 元素(如果存在)包含Hadoop作业的 JobConf属性。
在 configuration 元素中指定的属性覆盖在 job-xml 元素中指定的文件中指定的属性。
可以通过指定属性 oozie.action.external.stats 来打开/关闭外部统计信息(External Stats)。在workflow.xml的configuration元素中写入true或false。此属性的默认值为false。
file 元素(如果存在)必须为二进制文件指定目标sybolic链接，方法是用 # ( file#target-symm-link )分隔原始文件和目标文件。这对于库来说不是必需的。
streaming作业的mapper和reducer进程，应该指定带有URL编码的可执行命令。如。’%’应改为’%25’。
示例：

<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="myfirstHadoopJob">
        <map-reduce>
            <job-tracker>foo:8021</job-tracker>
            <name-node>bar:8020</name-node>
            <prepare>
                <delete path="hdfs://foo:8020/usr/tucu/output-data"/>
            </prepare>
            <job-xml>/myfirstjob.xml</job-xml>
            <configuration>
                <property>
                    <name>mapred.input.dir</name>
                    <value>/usr/tucu/input-data</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>/usr/tucu/input-data</value>
                </property>
                <property>
                    <name>mapred.reduce.tasks</name>
                    <value>${firstJobReducers}</value>
                </property>
                <property>
                    <name>oozie.action.external.stats.write</name>
                    <value>true</value>
                </property>
            </configuration>
        </map-reduce>
        <ok to="myNextAction"/>
        <error to="errorCleanup"/>
    </action>
    ...
</workflow-app>

在上面的示例中，在创建工作流作业时，必须将Map/Reduce作业使用的Reducer的数量指定为工作流作业配置的一个参数。（mapred.output.dir，/usr/tucu/output-data）
Streaming示例：

<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:1.0">
    ...
    <action name="firstjob">
        <map-reduce>
            <resource-manager>foo:8032</resource-manager>
            <name-node>bar:8020</name-node>
            <prepare>
                <delete path="${output}"/>
            </prepare>
            <streaming>
                <mapper>/bin/bash testarchive/bin/mapper.sh testfile</mapper>
                <reducer>/bin/bash testarchive/bin/reducer.sh</reducer>
            </streaming>
            <configuration>
                <property>
                    <name>mapred.input.dir</name>
                    <value>${input}</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>${output}</value>
                </property>
                <property>
                    <name>stream.num.map.output.key.fields</name>
                    <value>3</value>
                </property>
            </configuration>
            <file>/users/blabla/testfile.sh#testfile</file>
            <archive>/users/blabla/testarchive.jar#testarchive</archive>
        </map-reduce>
        <ok to="end"/>
        <error to="kill"/>
    </action>
  ...
</workflow-app>

Pipes示例：

<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:1.0">
    ...
    <action name="firstjob">
        <map-reduce>
            <resource-manager>foo:8032</resource-manager>
            <name-node>bar:8020</name-node>
            <prepare>
                <delete path="${output}"/>
            </prepare>
            <pipes>
                <program>bin/wordcount-simple#wordcount-simple</program>
            </pipes>
            <configuration>
                <property>
                    <name>mapred.input.dir</name>
                    <value>${input}</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>${output}</value>
                </property>
            </configuration>
            <archive>/users/blabla/testarchive.jar#testarchive</archive>
        </map-reduce>
        <ok to="end"/>
        <error to="kill"/>
    </action>
  ...
</workflow-app>

3.2.3 Pig Action

3.2.4 Fs (HDFS) action

<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="[NODE-NAME]">
        <fs>
            <delete path='[PATH]'/>
            ...
            <mkdir path='[PATH]'/>
            ...
            <move source='[SOURCE-PATH]' target='[TARGET-PATH]'/>
            ...
            <chmod path='[PATH]' permissions='[PERMISSIONS]' dir-files='false' />
            ...
            <touchz path='[PATH]' />
            ...
            <chmod path='[PATH]' group='[GROUP]' dir-files='false' />
        </fs>
        <ok to="[NODE-NAME]"/>
        <error to="[NODE-NAME]"/>
    </action>
    ...
</workflow-app>

3.2.5 Ssh Action

NOTE: SSH actions are deprecated in Oozie schema 0.1, and removed in Oozie schema 0.2

3.2.6 Sub-workflow Action

3.2.7 Java Action

3.2.7.1 Overriding an action’s Main class

4 Parameterization of Workflows

4.1 Workflow Job Properties (or Parameters)
4.2 Expression Language Functions
4.2.1 Basic EL Constants
4.2.2 Basic EL Functions
4.2.3 Workflow EL Functions
4.2.4 Hadoop EL Constants
4.2.5 Hadoop EL Functions
4.2.6 Hadoop Jobs EL Function
4.2.7 HDFS EL Functions
4.2.8 HCatalog EL Functions
5 Workflow Notifications
5.1 Workflow Job Status Notification
5.2 Node Start and End Notifications
6 User Propagation
7 Workflow Application Deployment
8 External Data Assumptions
9 Workflow Jobs Lifecycle
10 Workflow Jobs Recovery (re-run)
11 Oozie Web Services API
12 Client API
13 Command Line Tools
14 Web UI Console
15 Customizing Oozie with Extensions
16 Workflow Jobs Priority
17 HDFS Share Libraries for Workflow Applications (since Oozie 2.3)
17.1 Action Share Library Override (since Oozie 3.3)
18 User-Retry for Workflow Actions (since Oozie 3.1)
19 Global Configurations
20 Suspend On Nodes
Appendixes
Appendix A, Oozie XML-Schema
Oozie Schema Version 0.5
Oozie Schema Version 0.4
Oozie Schema Version 0.3
Oozie Schema Version 0.2.5
Oozie Schema Version 0.2
Oozie SLA Version 0.2
Oozie SLA Version 0.1
Oozie Schema Version 0.1
Appendix B, Workflow Examples