By

文章目录
  1. 1. Start Control Node
  2. 2. End Control Node
  3. 3. Kill Control Node
  4. 4. Decision Control Node
  5. 5. Fork and Join Control Nodes
  6. 6. 总结
  7. 7. 参考资料

Oozie 工作流中，控制节点包括工作流的开始和结束节点，即 start 节点、end 节点和 kill 节点，并提供了控制工作流执行路径的节点，即 decison 节点、fork 节点和 join 节点。

Start Control Node

start 节点是一个工作流的入口节点，当工作流开始执行时，将会自动的过渡到由 start 节点 指向的节点。一个工作流必须有一个 start 节点。

语法:

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

其中，to 属性即是工作流执行的第一个节点的名字。

例子:

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

End Control Node

end 节点是一个控制流的结束点，即一个控制流执行到 end 节点时，表明工作流执行成功。其中，当工作流中有多个 action 节点在执行，而其中一个 action 节点执行后到了 end 节点，则其它正在执行的 action 节点将会被终止，此时，工作流被认为执行成功。一个工作流必须有一个 end 节点。

语法:

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

其中，name 属性即是工作流在结束时的过渡过程

例子：

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

Kill Control Node

kill 节点允许工作流终止自己。当一个工作流执行到 kill 节点时，表明执行失败。其中，当工作流中有多个 action 节点在执行，而其中一个 action 节点执行后到了 kill 节点，则其它正在执行的 action 节点将会被终止，此时，工作流被认为执行失败。一个工作流可以有0个或者多个 kill 节点。

语法:

1
2
3
4
5
6
7
<workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.1">
    ...
    <kill name="[NODE-NAME]">
        <message>[MESSAGE-TO-LOG]</message>
    </kill>
    ...
</workflow-app>

其中，name 属性是工作流被终止时，需要执行的后续工作的节点名称。message 的内容将作为日志，记录工作流失败的原因。

例子:

1
2
3
4
5
6
7
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <kill name="killBecauseNoInput">
        <message>Input unavailable</message>
    </kill>
    ...
</workflow-app>

Decision Control Node

decision 节点使得工作流可以选择执行路径执行，decision 节点可以看作一个 switch-case。 在 decision 节点中，有多个可选择执行的过渡节点和一个默认执行的过渡节点。工作流将会按照这些节点在 decision 节点中排列的顺序，一个接着一个比较是否满足过渡条件。当有过渡条件满足时，将会执行对应的过渡节点，否则执行默认的过渡节点。

过渡条件为 JSP 表达式语言（EL） 形式，解析为布尔结果，如：

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

语法:

1
2
3
4
5
6
7
8
9
10
11
12
<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>

其中，name 属性即是 decison 节点的名称。每一个 case 包含一个判断条件，即 EL 表达式，并按照顺序判断，直到有一个 EL 表达式计算结果为 true 时执行对应的过渡节点。当所有的 EL 表达式计算结果为 false 时，将会执行 default 中 to 属性的名字的节点。每一个 decsion 节点必须有一个 default 元素，从而避免当所有的 EL 表达式计算结果为 false 时工作流进入执行错误的执行状态。

例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<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>

Fork and Join Control Nodes

fork 节点将工作流的执行路径分割为多个并发执行的子路径，而 join 节点等待，直到 fork 分割的多个并发执行的子路径都执行结束后执行。因此，fork 节点与 join 节点成对出现。

语法:

1
2
3
4
5
6
7
8
9
10
11
<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 节点的名字，start 属性是多个并发执行的子路径的名称。join 中的 name 是 join 节点的名称。

例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<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 会对工作流中任何一个并发执行的路径进行验证，确保工作流不会出现异常的行为或不稳定。如果在提交包含有并发执行路径的工作流时被 Oozie 阻止，而提交者确认该工作流可以正常的工作，则可以通过在 job.properties 文件中设置 oozie.wf.validate.ForkJoin 为 false 取消对该工作流的验证过程。若要取消对所有包含并发执行路径的工作流的验证过程，可以在 oozie-site.xml 中设置 oozie.validate.ForkJoin 为 false。

总结

本篇主要介绍了 Oozie Workflow 中控制节点的语法，同时给出了例子予以说明。

参考资料

  1. WorkflowFunctionalSpec
文章目录
  1. 1. Start Control Node
  2. 2. End Control Node
  3. 3. Kill Control Node
  4. 4. Decision Control Node
  5. 5. Fork and Join Control Nodes
  6. 6. 总结
  7. 7. 参考资料