MapReduce with MongoDB 1.8 and Java
by Brendan McAdams
In my last post, I introduced the new MapReduce features introduced in MongoDB 1.8, which is now available as a release candidate. Most importantly the temporary collection system has gone away, now requiring that you specify an output parameter. With that required output comes new options for how to create incremental output using the merge and reduce output modes.
As I write this, we are prepping new releases of our Java Driver (v2.5) and our Scala Driver, Casbah (v2.1) which are intended to support MongoDB 1.8’s new features including incremental MapReduce. Since I implemented the APIs for the new MapReduce output in both drivers, I thought I’d demonstrate the application of these new output features to the previous dataset. This post is focused on the Java API, but a Scala one will likely follow.
As a reminder (or a primer for those who skipped my last post), I’ve been testing the 1.8 MapReduce using a dataset and MapReduce job originally created to test the MongoDB+Hadoop Plugin. It consists of daily U.S. Treasury Yield Data for about 20 years; the MapReduce task calculates an annual average for each year in the collection. You can grab a copy of the entire collection in a handy mongoimport friendly datadump from the MongoDB+Hadoop repo; here’s a quick snippet of it:
The map function I’m using extracts the year from the date, and the 10 year benchmark value:
… while the reduce function aggregates the data by year, creating a set that can be averaged. Remember that MongoDB reduce tasks have to be able to be called repeatedly, so the output is crafted to match the input: something that becomes even more important when we say, ask MongoDB to re-reduce our output with the old data.
We’ll round it all out out with a quick and dirty finalize function which can calculate the current average. Note that I’m keeping all the intermediate data around for demonstrating “reduce” mode.
First, we’ll need to stick these functions into some Java strings to pass around for our testing:
The Java API now allows you to pass an optional MapReduceCommand.OutputType value, which controls the type of output received. If one is not specifed, the output collection is assumed to be REPLACE — namely, the standard mode in which the named collection is replaced completely with the output of the MapReduce job. Looking at INLINE as our example, we can call the new method in collection. Feel free to set the output collection name to null or a throwaway value; it is ignored by the Java driver in Inline output mode.
Which should output each DBObject in the results to the screen. The new MapReduceOutput code detects the result set type from MongoDB and provides it in
results() as a
Iterable<DBObject>—whether the results are INLINE or stored in a collection. Note that I did not specify the
finalize function here, as the interface on DBCollection doesn’t accept it as a parameter. Alternately, we could construct a MapReduceCommand instance, which allows us to set
Using the MERGE and REDUCE Output Modes follows much the same pattern. I’ll leave figuring out MERGE as an exercise for the reader (it should be easy if you read my last post) but here’s how we would handle a REDUCE on two halves of the same year.
That’s it! Go forth, and MapReduce…tags: