Integration testing Hive jobs

Solution 1:

Ideally one would be able to test hive queries with LocalJobRunner rather than resorting to mini-cluster testing. However, due to HIVE-3816 running hive with mapred.job.tracker=local results in a call to the hive CLI executable installed on the system (as described in your question).

Until HIVE-3816 is resolved, mini-cluster testing is the only option. Below is a minimal mini-cluster setup for hive tests that I have tested against CDH 4.4.

Configuration conf = new Configuration();

/* Build MiniDFSCluster */
MiniDFSCluster miniDFS = new MiniDFSCluster.Builder(conf).build();

/* Build MiniMR Cluster */
System.setProperty("hadoop.log.dir", "/path/to/hadoop/log/dir"); // MAPREDUCE-2785
int numTaskTrackers = 1;
int numTaskTrackerDirectories = 1;
String[] racks = null;
String[] hosts = null;
miniMR = new MiniMRCluster(numTaskTrackers, miniDFS.getFileSystem().getUri().toString(),
                           numTaskTrackerDirectories, racks, hosts, new JobConf(conf));

/* Set JobTracker URI */
System.setProperty("mapred.job.tracker", miniMR.createJobConf(new JobConf(conf)).get("mapred.job.tracker"));

There is no need to run a separate hiveserver or hiveserver2 process for testing. You can test with an embedded hiveserver2 process by setting your jdbc connection URL to jdbc:hive2:///

Solution 2:

I come to find one pretty good tool: HiveRunner. It is framework on top of jUnit to test hive scripts. Under the hood it starts a stand alone HiveServer with in memory HSQL as the metastore.

Solution 3:

I have implemented HiveRunner.

https://github.com/klarna/HiveRunner

We tested it on Mac and had some trouble with Windows, however with a few changes listed below the util served well.

For windows here are some of the changes that were done in order to have HiveRunner work in windows environment. After these changes unit testing is possible for all Hive queries.

1.Clone the project at https://github.com/steveloughran/winutils to anywhere on your computer, Add a new environment variable, HADOOP_HOME, pointing to the /bin directory of that folder. no forward slashes or spaces allowed. 2.Clone the project at https://github.com/sakserv/hadoop-mini-clusters to anywhere on your computer. Add a new environment variable HADOOP_WINDOWS_LIBS, pointing to the /lib directory of that folder. Again, no forward slashes or spaces allowed. 3.I also installed cygwin, assuming severla win utils for linux might be available through.

This pull on gitbub helped with making it work on windows, https://github.com/klarna/HiveRunner/pull/63

Solution 4:

Hive supports embedded mode only in the sense that the RDBMS which stores the meta information for the Hive tables can run locally or on a stand alone server (see https://cwiki.apache.org/confluence/display/Hive/HiveClient for details). Furthermore, hive with it's accompanying database is merely an orchestrator for a string of MapReduce jobs, which requires the Hadoop framework to be running as well.

I recommend using this virtual machine that has a pre-configured Hadoop stack http://hortonworks.com/products/hortonworks-sandbox/ . Hortonworks is one of 2 leading Hadoop distribution providers, so it is well-supported.

Solution 5:

I'm uncertain of what has changed since the accepted answer in Feb. 2014, but as of Hive 1.2.0, the following works around the issue described by OP:

System.setProperty(HiveConf.ConfVars.SUBMITLOCALTASKVIACHILD.varname, "false");

Do be aware of the warning given in the config documentation:

Determines whether local tasks (typically mapjoin hashtable generation phase) runs in separate JVM (true recommended) or not. Avoids the overhead of spawning new JVM, but can lead to out-of-memory issues.

This works around the issue because in MapredLocalTask.java:

  @Override
  public int execute(DriverContext driverContext) {
    if (conf.getBoolVar(HiveConf.ConfVars.SUBMITLOCALTASKVIACHILD)) {
      // send task off to another jvm
      return executeInChildVM(driverContext);
    } else {
      // execute in process
      return executeInProcess(driverContext);
    }
  }

The default config value causes the executeInChildVM() method to be called, which literally calls hadoop jar. The other code path has so far worked out in my testing. Potential memory issues can likely be resolved by tweaking Java heap configs (Xmx, Xms, etc).