What's wrong with Hue Oozie Editor?

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

First, let's make the topic clear:

Comparing with providing raw Oozie workflow/coordinator XML file, what's disadvantages to create workflow/coordinator with Hue Oozie Editor? (The Hue Oozie Editor version discussed by this artical is HDP 2.2.4)

If no deep understanding with Hue Oozie Editor, everybody would like it in the first glance, why not? It's so easy-to-use and what do you see are, who want to write the ugly XML file manually?

But the truth is:the Hue Oozie Editor isn't so good as it looks, it's far away to stable and powerful tool to Create/man Age workflows.

Here is the problems:

1. As core source codes for workflows, the raw XML files should add to version control. The Hue Oozie Editor has no or very weak version control ability.

2. If we maintain raw XML file in project, with building tools, we can configure environment related parameters, i.e. Namenod E, input/output data location and etc. And then we can easily build project for Dev, test or production environment.

On the contrary, what if using Hue Oozie Editor? congratulations! Duplicated job again on production cluster:re-create the workflows/coordinators on the production cluster m Anually. Well, there's a import/export feature in Hue Oozie Editor, but it's only for workflow isn't for coordinator, and even for W Orkflows, you still has to change all environment related parameters manually.

1. It can ' t support some advanced features and so we have the to edit raw XML file. For example:you can ' t assign the expression between input-events and datasets, i.e. ${coord:current ( -1)}, you can only map them directly.

2. Can ' t import/export coordinators.

Well, at least, could we import our raw workflow file into Hue Oozie Editor?

Let's look at what weak the current Hue Oozie Editor:

2. For schema version, Hue Oozie Editor only, higher than 0.4 of workflow and not higher than 0.2 of hive-action, Otherwise you can ' t import your raw file.

4. It's hard-to-believe:the property Name:jobtracker and NameNode is hard code! If you don't use the name of the again, you can ' t import your raw file.

5. Some parameters accept embedded parameter, i.e. NameN od e/d aTa/ yeaR / {Month}, but some isn't, as for which accept which not? Try by yourself-one, otherwise, you can ' t import your raw file still.

Nobody hate UI design tools, but it had to be good enough. By now, I would say, building workflows above Hue Oozie Editor is unwise.

Obviously, we should choose raw XML file not Hue Oozie Editor.

But there are only one small trouble, the hue can only start a workflow/coordinator edited by Hue Oozie Editor.Note:once A Workflow/coordinator started, you can monitor & stop it from Hue even it's described by raw XML.

First, I don ' t think this is a trouble, we can start a workflow/coordinator with command line. Remember:normally, a workflow/coordinator is long-term running & background service, we scarcely start/stop It. So, the command line was enough for the operation and maintenance.

Besides command line, you can also the start a workflow/coordinator via Oozie Restful API from remote.

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

What's wrong with Hue Oozie Editor?