Debugging MapReduce Programs With MRUnit

The distributed nature of MapReduce programs makes debugging a challenge. Attaching a debugger to a remote process is cumbersome, and the lack of a single console makes it difficult to inspect what is occurring when several distributed copies of a mapper or reducer are running concurrently. Furthermore, operations that work on small amounts of input (e.g., saving the inputs to a reducer in an array) fail when running at scale, causing out-of-memory exceptions or other unintended effects.

A full discussion of how to debug MapReduce programs is beyond the scope of a single blog post, but I’d like to introduce you to a tool we designed at Cloudera to assist you with MapReduce debugging: MRUnit.

MRUnit helps bridge the gap between MapReduce programs and JUnit by providing a set of interfaces and test harnesses, which allow MapReduce programs to be more easily tested using standard tools and practices.

While this doesn’t solve the problem of distributed debugging, many common bugs in MapReduce programs can be caught and debugged locally. For this purpose, developers often try to use JUnit to test their MapReduce programs. The current state of the art often involves writing a set of tests that each create a JobConf object, which is configured to use a mapper and reducer, and then set to use the LocalJobRunner (via JobConf.set(”mapred.job.tracker”, “local”)). A MapReduce job will then run in a single thread, reading its input from test files stored on the local filesystem and writing its output to another local directory.

This process provides a solid mechanism for end-to-end testing, but has several drawbacks. Developing new tests requires adding test inputs to files that are stored alongside one’s program. Validating correct output also requires filesystem access and parsing of the emitted data files. This involves writing a great deal of test harness code, which itself may contain subtle bugs. Finally, this process is slow. Each test requires several seconds to run. Users often find themselves aggregating several unrelated inputs into a single test (violating a unit testing principle of isolating unrelated tests) or performing less exhaustive testing due to the high barriers to test authorship.

The easiest way to test MapReduce programs is to include as little Hadoop-specific code as possible in one’s application. Parsers can operate on instances of String instead of Text, and mappers should instantiate instances of MySpecificParser to tokenize input data rather than embed parsing code in the body of MyMapper.map(). Your MySpecificParser implementation can then be tested with ordinary JUnit tests. Another class or method could then be used to perform processing on parsed lines.

But even with those components separately tested, your map() and reduce() calls should still be tested individually, as the composition of separate classes may cause unintended bugs to surface. MRUnit provides test drivers that accept programmatically specified inputs and outputs, which validate the correct behavior of mappers and reducers in isolation, as well as when composed in a MapReduce job. For instance, the following code checks whether the IdentityMapper emits the same (key, value) pair as output that it receives as input:

The MapDriver orchestrates the test process, feeding the input (“foo” and “bar”) record to the IdentityMapper when its runTest() method is called. It also passes a mock OutputCollector implementation to the mapper. The driver then validates the output received by the OutputCollector against the expected output (”foo” and “bar”) record. If the actual and expected outputs mismatch, a JUnit assertion failure is raised, informing the developer of the error. More test drivers exist for testing individual reducers, as well as mapper/reducer compositions.

End-to-end tests involving JobConf configuration code, InputFormat and OutputFormat implementations, filesystem access, and larger scale testing are still necessary. But many errors can be quickly identified with small tests involving a single, well-chosen input record, and a suite of regression tests allows correct behavior to be assured in the face of ongoing changes to your data processing pipeline. We hope MRUnit helps your organization test code, find bugs, and improve its use of Hadoop by facilitating faster and more thorough test cycles.

MRUnit is open source and is included in Cloudera’s Distribution for Hadoop. For more information about MRUnit, including where to get it and how to use its API, see the MRUnit documentation page.

Filed under:

8 Responses
  • Dioktos / February 17, 2010 / 1:35 PM

    The link to MRUnit given in the post seems to no longer valid.

  • I did a minor change for MRUnit / May 01, 2010 / 8:11 PM

    Sometimes, we set multiple paths for one map, and we write code like this in the map:

    String fileSplitPath = ((FileSplit)reporter.getInputSplit()).getPath().toString();

    But for the MRUnit, the inputsplit path is “some file” hard coded, so I did a minor change: now I can do this:

    commonMapDriver = new MapDriver(commonMapper);

    commonMapDriver.setInputSplitPath(“/group/tbsc-dev/chijiong/data”);

    How to contribute this change to you? Thanks!

    Send me Email if you think it is possible.

  • Aaron Kimball / May 10, 2010 / 1:30 PM

    That sounds like a good improvement. You should submit this as a patch to Hadoop; file a ticket on the issue tracker (issues.apache.org/jira/browse/MAPREDUCE) and attach a patch with your changes and a testcase. You’ll need to make your changes against Apache Hadoop’s trunk branch from subversion. There are much more complete instructions here: http://wiki.apache.org/hadoop/HowToContribute

    Also feel free to shoot me an email (aaron at cloudera) if you’ve got more questions.

    Cheers,
    - Aaron

  • Leonid Furman / June 09, 2010 / 3:30 PM

    I encountered the same problem recently. There is a way to override the hardcoded input split path. Since it is declared as static final String, it is possible to remove the static modifier so you can set the input split value using reflection. Here is the reference:

    http://stackoverflow.com/questions/2474017/using-reflection-to-change-static-final-file-separatorchar-for-unit-testing

    http://www.javaspecialists.eu/archive/Issue161.html

    This is a hack, but I guess it should be acceptable if used exclusively within the unit test scope.

    Another solution could be applying the aspect oriented programming techniques, such as enhancing the Context class with CGLIB.

Leave a comment


− 1 = two