Oozie How workflow properties are configured and policies

This article source: http://blog.csdn.net/bluishglc/article/details/46049817 prohibited any form of reprint, or will entrust CSDN official maintenance rights!

Oozie three ways to configure workflow properties

Oozie There are three ways to provide attribute property configuration to a workflow:

1. App Deployment folder root directory: Config-default.xml
2. Job Properties File: Job.properties
3. Specify properties on the command line:-dkey=value

Oozie Policy for Workflow properties configuration (best practices)

Frankly, the three configurations overlap, and the use of all of them makes the configuration of the properties too fragmented, making locating and locating properties cumbersome. In my personal experience, I tend to do this:

1. For static configuration items that do not change from one boot to the other, all are configured in Config-default.xml because this file is part of the Oozie deployment self-contained (self-contained application) Application specification, This means that the file will be automatically loaded and read, as in the Java EE in the same way as Web. XML, so it is ideal to write static configuration items here.

2. For dynamic, the configuration items that vary with each boot (typically the coordinator start time), are specified by the command line as the most appropriate.

3. Typically, most build tools, such as MAVEN, can replace some of the variables in the configuration file at build time based on the target environment of the build, and we should use this feature to The environment-related properties in Config-default.xml and the command line (if you have a command-line script) are replaced at build time. Typical examples are namenode and jobtracker.

4. Avoid using job.properties because Job.properties is a local file and it is obviously not config-default.xml convenient because config-default.xml is self-contained.

On top of that, a simple command line to start a workflow should look like this: first, Specifying Oozie.wf.application.path or Oozie.coord.application.path or Oozie.bundle.application.path is essential because at least you have to tell Oozie where your application is placed, and then I We need to specify some dynamic parameters from the command line. Therefore, starting a workflow from the command line is often the case:

oozie job -run -Doozie.wf.application.path=hdfs://your-namenode:8020/your/app/path -DPARAM1=${PARAM1} -DPARAM1=${PARAM2}

As for the other property configurations of the workflow, they are already stored in hdfs://your-namenode:8020/your/app/path/config-default.xml.

Oozie naming conventions for workflow properties

Finally, as a supplement, let's talk about Oozie's requirements for naming its properties:

- Properties that are a valid Java identifier, [A-Za-z_][0-9A-Za-z_]* , are available as ‘${NAME}‘ variables within the workflow definition.- **Properties that are not valid Java Identifier, for example ‘job.tracker‘**, are available via the String wf:conf(String name) function.

Yes, it seems to be a bit of a wonderful rule. For Oozie attribute names, only numbers, letters, and glide lines are allowed, and property names like Job.tracker are illegal!

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Oozie How workflow properties are configured and policies