Hive Query Failed with Token Renewer Error | Hive on Spark

If you run Hive on Spark on some CDH versions, you might run into issues when Hive is trying to renew HDFS delegation tokens. See below error message (that you can find from HiveServer2 server logs):

2017-06-27 17:04:08,836 INFO org.apache.hive.spark.client.SparkClientImpl: [stderr-redir-1]: 17/06/27 17:04:08 
WARN security.UserGroupInformation: PriviledgedActionException as:testuser (auth:PROXY) via 
hive/ (auth:KERBEROS) 
testuser tries to renew a token with renewer hive

If you do some googling, you should be able to locate the corresponding upstream Hive JIRA for this issue: HIVE-15485. And from this JIRA, you should also be able to identify that the issue was introduced by HIVE-14383. This is due to the fact that Spark needs the principal/keytab passed in via –principal and –keytab options, and does the renewal by copying the keytab to the cluster and handling login to kerberos inside the application. But the option –principal and –keytab could not work with –proxy-user in, so at this moment we could support either the token renewal or the impersonation, but not both.

The only way to avoid such issue is to upgrade CDH to the version that has the fix for HIVE-15485, which has been fixed in the following releases:

CDH5.10.1, CDH5.10.2
CDH5.11.0, CDH5.11.1

Since HIVE-14383 was introduced in the following CDH:

CDH5.8.3, CDH5.8.4, CDH5.8.5
CDH5.9.1, CDH5.9.2
CDH5.10.0, CDH5.10.1, CDH5.10.2 
CDH5.11.0, CDH5.11.1

This makes the following CDH currently will have such issues:

CDH5.8.3, CDH5.8.4, CDH5.9.1, CDH5.10.0

Please deploy the latest maintenance release for your major version to avoid such issue in Hive on Spark.

Hope above helps.

Read Files under Sub-Directories for Hive and Impala

Sometimes you might want to store data under sub-directories in HDFS and then you want Hive or Impala to read from those sub-directories. For example, you have the following directory structure:

root hdfs     231206 2017-06-30 02:45 /test/table1/000000_0
root hdfs          0 2017-06-30 02:45 /test/table1/child_directory
root hdfs     231206 2017-06-30 02:45 /test/table1/child_directory/000000_0

By default, Hive will only look for files in the root of directory specified, in my test case is /test/table1. However, Hive supports to read all data under the root table’s sub-directories as well. This can be achieved by updating the following settings:

SET mapred.input.dir.recursive=true;
SET hive.mapred.supports.subdirectories=true;

Impala however, on the other side, currently does not support reading files from table’s sub-directories. This has been reported in the upstream JIRA of IMPALA-1944. Currently there is no immediate plan to support such feature, but it might be in the future release of Impala.

Hope above information is useful.

Impala Auto Update Metadata Support

There are lots of CDH users requested that Impala to support automatic metadata update, so that they do NOT need to run “INVALIDATE METADATA” every time when create table or data are updated through other components, like Hive or Pig.

I would like to share that this has been reported upstream and tracked via JIRA: IMPALA-3124. Currently it is still not fixed and it requires detailed design to make sure that it will work in the proper way.

There is no ETA at this stage on when this feature will be added. Advise anyone interested on this feature to add comments to the JIRA. The more votes, the better chance that it will be prioritized.

Hope above information is helpful.

Oozie Server failed to Start with error java.lang.NoSuchFieldError: EXTERNAL_PROPERTY

This issue happens in CDH distribution of Hadoop that is managed by Cloudera Manager (possibly in other distributions as well, due to known upstream JIRA, but I have not tested). Oozie will fail to start after enabling Oozie HA through Cloudera Manager user interface.

The full error message from Oozie’s process stdout.log (can be found under /var/run/cloudera-scm-agent/process/XXX-oozie-OOZIE_SERVER/logs directory) file looks like below:

Wed Jan 25 11:07:41 GST 2017 
using 5 as CDH_VERSION 
using /var/lib/oozie/tomcat-deployment as CATALINA_BASE 
Copying JDBC jar from /usr/share/java/oracle-connector-java.jar to /var/lib/oozie 

ERROR: Oozie could not be started 

REASON: java.lang.NoSuchFieldError: EXTERNAL_PROPERTY 

java.lang.NoSuchFieldError: EXTERNAL_PROPERTY 
at org.apache.oozie.util.FixedJsonInstanceSerializer.serialize( 
at org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.internalRegisterService( 
at org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.registerService( 
at org.apache.oozie.util.ZKUtils.advertiseService( 
at org.apache.oozie.util.ZKUtils.<init>( 
at org.apache.oozie.util.ZKUtils.register( 
at org.apache.oozie.service.ZKLocksService.init( 
at org.apache.oozie.service.Services.setServiceInternal( 
at org.apache.oozie.service.Services.setService( 
at org.apache.oozie.service.Services.loadServices( 
at org.apache.oozie.service.Services.init( 
at org.apache.oozie.servlet.ServicesLoader.contextInitialized( 
at org.apache.catalina.core.StandardContext.listenerStart( 
at org.apache.catalina.core.StandardContext.start( 
at org.apache.catalina.core.ContainerBase.addChildInternal( 
at org.apache.catalina.core.ContainerBase.addChild( 
at org.apache.catalina.core.StandardHost.addChild( 
at org.apache.catalina.startup.HostConfig.deployWAR( 
at org.apache.catalina.startup.HostConfig.deployWARs( 
at org.apache.catalina.startup.HostConfig.deployApps( 
at org.apache.catalina.startup.HostConfig.start( 
at org.apache.catalina.startup.HostConfig.lifecycleEvent( 
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( 
at org.apache.catalina.core.ContainerBase.start( 
at org.apache.catalina.core.StandardHost.start( 
at org.apache.catalina.core.ContainerBase.start( 
at org.apache.catalina.core.StandardEngine.start( 
at org.apache.catalina.core.StandardService.start( 
at org.apache.catalina.core.StandardServer.start( 
at org.apache.catalina.startup.Catalina.start( 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke( 
at sun.reflect.DelegatingMethodAccessorImpl.invoke( 
at java.lang.reflect.Method.invoke( 
at org.apache.catalina.startup.Bootstrap.start( 
at org.apache.catalina.startup.Bootstrap.main( 

To fix the issue, please follow the steps below:

  1. Delete or move the following files under CDH’s parcel directory (most likely they are symlinks):
  2. Download hive-exec-{cdh version}-core.jar file from the Cloudera repo, for example, for CDH5.8.2, please go to:

    and put the file under the following directories on the Oozie server:

  3. Download kryo-2.22.jar from the maven repository:

    and put it under directories on the Oozie server:

  4. Finally restart Oozie service

This is a known Oozie issue and reported in the upstream JIRA: OOZIE-2621, which has been resolved and targeted for 4.3.0 release.

Hope this helps.

Unable to Import Data as Parquet into Encrypted HDFS Zone | Sqoop Parquet Import

Recently I discovered an issue in Sqoop that when importing data into Hive table, whose location is in an encrypted HDFS zone, it will fail with “can’t be moved into an encryption zone” error:


sqoop import --connect <postgres_url> --username <username> --password <password> \
--table sourceTable --split-by id --hive-import --hive-database staging \
--hive-table hiveTable --as-parquetfile


2017-05-24 13:38:51,539 INFO [Thread-84] 
Setting job diagnostics to Job commit failed: Could not move contents of hdfs://nameservice1/tmp/staging/.
temp/job_1495453174050_1035/mr/job_1495453174050_1035 to 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(
        at java.util.concurrent.ThreadPoolExecutor$
Caused by: org.apache.hadoop.ipc.RemoteException( 
can't be moved into an encryption zone.
        at org.apache.hadoop.hdfs.server.namenode.EncryptionZoneManager.checkMoveValidity(
        at org.apache.hadoop.hdfs.server.namenode.FSDirectory.unprotectedRenameTo(
        at org.apache.hadoop.hdfs.server.namenode.FSDirectory.renameTo(
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameToInternal(
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameToInt(
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(

This is caused by a known Sqoop bug: SQOOP-2943. This happens because Sqoop uses Kite SDK to generate Parquet file, and Kite SDK uses /tmp directory to generate the parquet file on the fly. And because /tmp directory is not encrypted and hive warehouse directory is encrypted, the final move command to move the parquet file from /tmp to hive warehouse will fail due to the encryption. The import only fails with parquet format, text file format works as expected.

Currently SQOOP-2943 is not fixed and there is no direct workaround.

For the time being, the workaround is to:

  1. Import data as text file format into Hive temporary table, and then use Hive query to copy data into destination parquet table. OR
  2. Import data as parquet file into temporary directory outside of Hive warehouse, and then again use Hive to copy data into destination parquet table