Oozie分布式工作流——流控制
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图形化界面的话，这些流控制节点基本上都是自动生成的，用户可以不需要关注。但是为了能看懂实际的任务，最好还是了解一下他们的关系。