Oozie分布式工作流——流控制

最近又开始捅咕上oozie了，所以回头还是翻译一下oozie的文档。文档里面最重要就属这一章了——工作流定义。

一提到工作流，首先想到的应该是工作流都支持哪些工作依赖关系，比如串式的执行，或者一对多，或者多对一，或者条件判断等等。Oozie在这方面支持的很好，它把节点分为控制节点和操作节点两种类型，控制节点用于控制工作流的计算流程，操作节点用于封装计算单元。本篇就主要描述下它的控制节点...

背景

先看看oozie工作流里面的几个定义：

• action,一个action是一个独立的任务，比如mapreduce,pig,shell,sqoop,spark或者java程序，它也可能是引用了某个action节点。
• workflow,它是一组action的集合，内部控制了节点间的依赖关系，DAG(Direct Acyclic Graph)，一个action依赖另一个action，就意味着只有前一个action运行完成，才能继续运行下一个。
• worklfow definition，是可执行的workflow的描述
• workflow definition language，定义了workflow的语言
• workflow jon，是一个workflow的实例
• workflow engine，用来执行workflow的系统

在oozie里面，工作流就是一组操作的集合，他们之前包含了前后依赖的关系，比如hadoop，pig等等。工作流里面可以包含fork和join的节点，用于把任务水平拆分成多个，并行执行，然后再合并到一起。

在oozie中，工作流的状态可以是：

PREP   RUNNING   SUSPENDED   SUCCEEDED   KILLED   FAILED

当任务失败时，oozie会通过参数控制进行重试，或者直接退出。

工作流定义

一个工作流的定义包含了 流控制节点（比如start,end,decision,fork,join,kill）以及action节点（比如map-reduce,spark,sqoop,java,shell等），节点直接都是通过有向箭头相连。

注意：在oozie里面是不支持环路的，工作流必须是严格的单向DAG。

工作流节点

工作流节点的命名规则需要满足=[a-zA-Z][-_a-zA-Z0-0]*=,并且长度在20个字符以内。

流控制节点

流控制节点一般都是定义在工作流开始或者结束的位置，比如start,end,kill等。以及提供工作流的执行路径机制，如decision,fork,join等。

start

start节点是工作流的入口，workflow第一个action就需要是start。当工作流启动后，会自动寻找start节点执行。每个工作流都需要有一个start节点。

例如:

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

end

end节点是工作流执行成功的最后一个节点，当到达end节点后，工作流的状态会变成SUCCEEDED.如果有多个action指向了end，那么当第一个action执行后就会直接跳转到end节点，虽然后面的action都没有执行，但是workflow也认为是成功执行了。

例如：

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

kill

kill节点允许工作流自动停止，当工作流执行到kill时，工作流的状态将会被认为是KILLED。如果有一个或者多个节点指向了kill，那么工作流都会被停止。一个workflow可以声明零个或者多个节点。

其中name属性是kill节点的名称，message指定了工作流退出的原因。

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

decision

decision节点支持给工作流提供选择，有点类似switch-case的语法。它使用JSP表达式语法，来进行条件判断。

比如:

<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:fileSize(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和join

fork节点把任务切分成多个并行任务，join则合并多个并行任务。fork和join节点必须是成对出现的。join节点合并的任务，必须是通一个fork出来的子任务才行。

<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里面，这种fork和join的机制是非常有用的，它可以把水平的任务并行执行，这样能更有效的利用集群的资源，避免资源闲置浪费。

如果使用HUE图形化界面的话，这些流控制节点基本上都是自动生成的，用户可以不需要关注。但是为了能看懂实际的任务，最好还是了解一下他们的关系。