oozie workflow example for shell action with end to end configuration

Oozie provides a convenient way to run any shell command. This could be Unix commands, Perl,Python or even Java programs invoked through the Unix shell. The shell command runs on an arbitrary Hadoop cluster node and the commands being run have to be available locally on that node. There are some limitation like Interactive commands and sudo or run as another user is not allowed also because the shell command runs on any Hadoop node, you need to be aware of
the path of the binary on these nodes.

The elements that make up this action are as follows:

1. job-tracker (required)
2. name-node (required)
3. prepare
4. job-xml
5. configuration
6. exec (required)
7. argument
8. env-var
9. file
10. archive
11. capture-output

The <exec> element has the actual shell command with the arguments passed in through the <argument> elements. If the excutable is a script instead of a standard Unix command, the script needs to be copied to the workflow root directory on HDFS and defined via the <file> element as always. The <shell> action also includes an <env-var> element that contains the Unix environment variable, and it’s defined using the standard Unix syntax like PATH=$PATH:my_path.

1. Co-ordinator xml file – coordinator.xml

An Oozie coordinator schedules workflow executions based on a start-time and a frequency parameter, and it starts the workflow when all the necessary input data becomes available. If the input data is not available, the workflow execution is delayed until the input data becomes available. A coordinator is defined by a start and end time, a frequency, input and output data, and a workflow. A coordinator runs periodically from the start time until the end time.

Beginning at the start time, the coordinator job checks if the required input data is available. When the input data becomes available, a workflow is started to process the input data, which on completion, produces the corresponding output data. This process is repeated at every tick of the frequency until the end time of the coordinator job. If the input data is not available for a workflow run, the execution of the workflow job will be delayed until the input data becomes available. Normally, both the input and output data used for a workflow execution are aligned with the coordinator time frequency.

<sla:should-end>${15 * MINUTES}</sla:should-end>
<sla:notification-msg>Check if HOUSE_KEEPING job for ${coord:nominalTime()} is running properly!</sla:notification-msg>

2. Oozie workflow xml – workflow.xml

An Oozie workflow is a multistage Hadoop job. A workflow is a collection of action and control nodes arranged in a directed acyclic graph (DAG) that captures control dependency where each action typically is a Hadoop job like a MapReduce, Pig, Hive, Sqoop, or Hadoop DistCp job. There can also be actions that are not Hadoop jobs like a Java application, a shell script, or an email notification. The order of the nodes in the workflow determines the execution order of these actions. An action does not start until the previous action in the workflow ends. Control nodes in a workflow are used to manage the execution flow of actions. The start and end control nodes define the start and end of a workflow. The fork and join control nodes allow executing actions in parallel. The decision control node is like a switch/case statement that can select a particular execution path within the workflow using information from the job itself.


<workflow-app name=”${wf_name}” xmlns=”uri:oozie:workflow:0.5″>
<credential name=’hcat’ type=’hcat’>
<start to=”purge-data”/>

<action name=”purge-data”>
<shell xmlns=”uri:oozie:shell-action:0.1″>
<ok to=”success-notification-email”/>
<error to=”failed-notification-email”/>

<action name=”success-notification-email”>
<email xmlns=”uri:oozie:email-action:0.1″>
<subject>SUCCESS : [${wf_hadoop_instance}] ${wf:name()} is successful for Run Date Time :- ${wf_exec_datetime}</subject>

This is auto-generated email. Please do not reply to this email.
<ok to=”End”/>
<error to=”failed-notification-email”/>
<action name=”failed-notification-email”>
<email xmlns=”uri:oozie:email-action:0.1″>
<subject>FAIL: [${wf_hadoop_instance}] ${wf:name()} is failed for Run Date Time :- ${wf_exec_datetime}</subject>

Workflow : ${wf:name()}
Failed Node : ${wf:lastErrorNode()}
Error Message : ${wf:errorMessage(wf:lastErrorNode())}

This is auto-generated email. Please do not reply to this email.
<ok to=”Kill”/>
<error to=”Kill”/>
<kill name=”Kill”>
<message>Action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]</message>
<end name=”End”/>


3.Shell File

We are basically deleting the older files based on the configured retention policy using this shell script.

if [ -z "$1" ] || [ -z "$2" ];
echo 'Missing 2 argument input! Hdfs purging path and file retention are not specified! '
exit 1

now=$(date +%s)
hadoop fs -ls -R $1 | while read f; do
dir_date=`echo $f | awk '{print $6}'`
file=`echo $f | awk '{print $8}'`
difference=$(( ( $now - $(date -d "$dir_date" +%s) ) / (24 * 60 * 60 ) ))
if [ $difference -gt $2 ]; then
hadoop fs -rm -r -skipTrash $file

4. coordinator property file to pass configuration – coordinator.properties

Finally the property file where the configuration parameters are passed from.




[email protected]

5. running the coordinator job

oozie job -oozie http://oozie_host:port/oozie -dryrun -config coordinator.properties

oozie job -oozie http://oozie_host:port/oozie -config coordinator.properties -run