{"id":848,"date":"2010-01-14T06:12:31","date_gmt":"2010-01-14T11:12:31","guid":{"rendered":"http:\/\/philippeadjiman.com\/blog\/?p=848"},"modified":"2025-07-18T13:49:12","modified_gmt":"2025-07-18T13:49:12","slug":"hadoop-tutorial-series-issue-4-to-use-or-not-to-use-a-combiner","status":"publish","type":"post","link":"https:\/\/philippeadjiman.com\/blog\/2010\/01\/14\/hadoop-tutorial-series-issue-4-to-use-or-not-to-use-a-combiner\/","title":{"rendered":"Hadoop Tutorial Series, Issue #4: To Use Or Not To Use A Combiner"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Welcome to the fourth issue of the Hadoop Tutorial Series<\/a>. Combiners are another important Hadoop’s feature that every hadoop developer should be aware of. The primary goal of combiners is to optimize\/minimize the number of key value pairs that will be shuffled accross the network between mappers and reducers and thus to save as most bandwidth as possible.<\/p>\n\n\n\n

Indeed, to give you the intuition of why combiner helps reducing the number of data sent to the reducers, imagine the word count example<\/a> on a text containing one million times the word “the”. Without combiner the mapper will send one million key\/value pairs of the form <the,1><\/strong>. With combiners, it will potentially send much less key\/value pairs of the form <the,N><\/strong> with N<\/em> a number potentially much bigger than 1. That’s just the intuition (see the references at the end of the post for more details).<\/p>\n\n\n\n

Simply speaking a combiner can be considered as a “mini reducer” that will be applied potentially several times still during the map phase before to send the new (hopefully reduced) set of key\/value pairs to the reducer(s). This is why a combiner must implement the Reducer interface<\/a> (or extend the Reducer class<\/a> as of hadoop 0.20).<\/p>\n\n\n\n

In general you can even use the same reducer method as both your reducer and your combiner. This is the case for the word count example where using a combiner remains to add a single line of code in your main method:<\/p>\n\n\n\n

conf.setCombinerClass(Reduce.class);<\/pre>\n\n\n\n
where conf is your JobConf<\/a>, or, if you use hadoop 0.20.1:<\/p>\n\n\n\n
job.setCombinerClass(Reduce.class);<\/pre>\n\n\n\n
where job is your Job<\/a> built with a customized Configuration<\/a>.<\/p>\n\n\n\n
That sounds pretty simple and useful and at first look you would be ready to use combiners all the time by adding this simple line, but there is a small catch. The first kind of reducers that comes naturally as a counter example of using combiner is the “mean reducer” that computes the mean of all the values associated with an given key.<\/p>\n\n\n\n
Indeed, suppose 5 key\/value pairs emitted from the mapper for a given key k<\/em>: <k,40><\/strong>, <k,30><\/strong>, <k,20><\/strong>, <k,2><\/strong>, <k,8><\/strong>. Without combiner, when the reducer will receive the list <k,{40,30,20,2,8}><\/strong>, the mean output will be 20<\/strong>, but if a combiner were applied before on the two sets (<k,40><\/strong>, <k,30><\/strong>, <k,20><\/strong>) and (<k,2><\/strong>, <k,8><\/strong>) separately, then the reducer would have received the list <k,{30,5}><\/strong> and the output would have been different (17.5<\/strong>) which is an unexpected behavior.<\/p>\n\n\n\n
More generally, combiners can be used when the function you want to apply is both commutative<\/a> and associative<\/a> (that’s pretty intuitive to understand why). That’s the case for the addition function, this is why the word count example can benefit from combiners but not for the mean function (which is not associative as shown in the counter example above).<\/p>\n\n\n\n
Note that for the mean function you can use a workaround for using combiners by using two separate reduce methods, a first one that would be used as the addition function (and thus that can be set as the combiner) that would emit the intermediate sum as the key and the number of addition involved as the value, and a second reduce function that would compute the mean by taking into account the number of addition involved (see the references for more details on that).<\/p>\n\n\n\n
As usual in this series, let’s observe the lesson learned in action using our learning playground<\/a>. For that you can use the original word count example<\/a> (or its hadoop 0.20.1 version that we used in the previous issue<\/a>), add it the single combine line as specified earlier in the post and run it on our moby-dick<\/a> mascot. Here what we can see at the end of the execution:<\/p>\n\n\n\n
\"\"
Output of the word count example when using a combiner.<\/figcaption><\/figure>\n\n\n\n
Now that you understand what counters are<\/a>, if you click to enlarge the picture, you’ll see the value of two counters: Combine input records=215137<\/strong> and Combine output records=33783<\/strong>. That’s a pretty serious reduction of the number of key\/value pairs to send to the reducers. You can easily imagine the impact for much larger jobs (see the reference below for real numbers).<\/p>\n\n\n\n
Enjoy combiners, whenever you can…<\/p>\n\n\n\n
References<\/strong><\/p>\n\n\n\n