Is there a way to prevent the start of the Tez AM from the Hive CLI?

[#1]

The desired end result is that I want no YARN containers automatically started when I enter the Hive CLI and the engine default is Tez.

hive.prewarm prevents default work containers but I need to stop the Tez AM from launching.

[#2]

@gopal

[#3 · Accepted solution]

Looks like the answer is no:

https://issues.apache.org/jira/browse/HIVE-9602

[#4]

@sseth

[#5]

For anyone that is interested in why I want this:

People use Oozie Shell actions to orchestrate work because they are familiar/comfortable with bash.

When using the Hive CLI from a YARN container context and secure cluster the engine specification must be done in an early stage.

For the Hive CLI this means users must change their existing HQL from

 hive -e 'set tez.credentials.path=${HADOOP_TOKEN_FILE_LOCATION}' 

to 

--hiveconf tez.credentials.path=${HADOOP_TOKEN_FILE_LOCATION}

For Sqoop, there is no way to affect this change from configuration and the user must ship a custom hive-site.xml in the distributed cache of the Oozie-shell.  This hive-site.xml must set the engine to MR

If this is not done, Hive and Sqoop will launch a Tez AM that may never even be used but which fails due to missing the delegation token.

These changes are small from from this explanation but rather large for organizations that already have established HQL and the cluster upgrade includes a default engine change from MR to Tez.

[#6]

A workaround for this could be launching the hive cli in the following manner:

hive -hiveconf hive.execution.engine=mr

But this would mean that if you want to run any queries in tez you would need to run "set hive.execution.engine=tez;" before running your queries.

[#7]

Can you help understand the scenario when this is needed? So the Hive shell is executed but wait until a query is executed for creating AM.. this means there are situations where Hive shell is executed and then exited without executing the query? Wont this be an exception scenario or in your case this is so frequent / regular that a workaround is required. I am sorry, just trying to understand when will such a configuration be needed..

[#8]

@kkane are you still having issues with this? Can you accept best answer or provide your own solution?