Support Questions
Find answers, ask questions, and share your expertise
Announcements
Check out our newest addition to the community, the Cloudera Innovation Accelerator group hub.

Problem in oozie input path . How do I configure the oozie in cloudera manager,input path as s3n.

Explorer

My input path in s3n,

 

s3n://xxx-xxx/20130813/08

 

My oozie configuration show as ,

 

hdfs://xxx.internal:8020/s3n://xxx-xxx/20130813/08

1 ACCEPTED SOLUTION

Master Guru

@dvohra wrote:

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

 

Doesn't the coordinator expect the input path to be on HDFS as hdfs://{nameNode} is prepended automatically? The workflow.xml is on the HDFS? Isn't the workflow.xml required to be on the HDFS?


Yes unfortunately coordinators currently poll inputs over HDFS alone, which is a limitation. However, writing simple WF actions to work over S3 is still possible.

 

Yes, WFs should reside on HDFS, as Oozie views it as its central DFS. Similar to how MR requires a proper DFS to run. But this shouldn't impair simple I/O operations done over an external FS such as S3.

 

I think Romain has covered the relevant JIRAs for tracking removal of this limitation.

View solution in original post

19 REPLIES 19

Rising Star

Explorer

Sorry, my question is through Hue in cloudera manager  i'm running the oozie job .And I can able to access the hdfs,my question is to connect the another instance  Amazon  as s3n://xxx  to connect ..

Rising Star

The input path is required to be to HDFS, not S3. S3 is not the same as HDFS.

Master Guru

@dvohra wrote:

The input path is required to be to HDFS, not S3. S3 is not the same as HDFS.


This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

Rising Star

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

 

Doesn't the coordinator expect the input path to be on HDFS as hdfs://{nameNode} is prepended automatically? The workflow.xml is on the HDFS? Isn't the workflow.xml required to be on the HDFS?

Master Guru

@dvohra wrote:

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

 

Doesn't the coordinator expect the input path to be on HDFS as hdfs://{nameNode} is prepended automatically? The workflow.xml is on the HDFS? Isn't the workflow.xml required to be on the HDFS?


Yes unfortunately coordinators currently poll inputs over HDFS alone, which is a limitation. However, writing simple WF actions to work over S3 is still possible.

 

Yes, WFs should reside on HDFS, as Oozie views it as its central DFS. Similar to how MR requires a proper DFS to run. But this shouldn't impair simple I/O operations done over an external FS such as S3.

 

I think Romain has covered the relevant JIRAs for tracking removal of this limitation.

New Contributor
Is there any updates to this Jira item? Is there a way now to specify an S3n:// location for input or output directories in Oozie workflow without the location being prepended by "hdfs"?

Yes, https://issues.cloudera.org/browse/HUE-1501 is in Hue 3.5 or CDH5 beta 2 in one month (and CDH5 in 2 months).

If it is urgent you could try to patch your Hue with the fix: https://issues.cloudera.org/browse/HUE-1501?focusedCommentId=19417&page=com.atlassian.jira.plugin.sy...

New Contributor

Thank you.  However I think my question is a little different than that addresses.  I am trying to specify an input or output directory in form "s3://..." in an Oozie workflow itself (as an input to a hadoop map reduce job).  Do you know if this should work? I get an error that says the path can't have "s3" in it.

Yes, it should work, cf. above users using it with no problem. What is your Oozie version?

New Contributor
I'm using "oozie-3.3.2-cdh4.5.0". The installation is working fine when input/output paths are specified in form "hdfs://…." but when specified with either "s3://…" or "s3n://" we get the following error in the logs:

Scheme of ʼs3n://...ʼ is not supported.

Where "…" equals path to input/output, verified there, verified working with hadoop commands in console.

Anything you know of I can look at?

New Contributor
Nevermind, I got it.

The solution was a mix of upgrading the version (to previously listed version) AND adding the supported filesystems property back in.

thanks!

Glad to hear!

Master Guru

@Ashok wrote:

My input path in s3n,

 

s3n://xxx-xxx/20130813/08

 

My oozie configuration show as ,

 

hdfs://xxx.internal:8020/s3n://xxx-xxx/20130813/08


Can you share your workflow.xml for us to validate?

 

If you're passing an S3 input or output path, simply ensure your workflow does not template it as ${nameNode}/${input} or something like that. That way you're prepending a HDFS URI to your already-an-uri path. This could most likely be your issue.

Explorer

In coordinator jobs i'm passing the dataset  uri template as 

 

s3n://xxx-xxx/${YEAR}${MONTH}${DAY}/${HOUR}

 

and coord:dataOut as 

 

<property>
<name>in_folder</name>
<value>${coord:dataOut('in_folder')}</value>
</property>

 

and my workflow.xml  input as 

 

${in_folder}

 

when I submit the  coordinator job it automatically preappend  the configuration like:

 

${nameNode}s3n://xxx-xxx/${YEAR}${MONTH}${DAY}/${HOUR}

Good to know, Hue Coodinators are prepended only with hdfs.

 

Is https://issues.apache.org/jira/browse/OOZIE-426 finished?

Explorer

FWIW, the same job works fine as a workflow when submitted via Hue. In this case, we manually pass the input (S3) and output (hdfs) locations and the job runs successfuly - thus establishing that the problem is not with S3 support. The problem is when we let the co-ordinator pass this input (via a computed datasource) does it automatically prepend hdfs://{nameNode} in front of the s3n://<> URI. Hope this clarifies.

Ok this clarifies a lot! I updated https://issues.cloudera.org/browse/HUE-1501.

Explorer

Thanks. Is this considered as a bug? If yes, what are some workarounds that we can follow for now? Any help is appreciated.