What does a Hadoop MapReduce job do differently when mapreduce.job.reduces is set to 0?

## The setting and what it removes `mapreduce.job.reduces` controls how many reduce tasks a job runs. Its default is 1. Setting it to 0 — in code with `job.setNumReduceTasks(0)`, or on the command line with `-D mapreduce.job.reduces=0` for a `Tool`-based driver — turns the job into a **map-only** job, and that removes more machinery than people expect: - No `Partitioner` is consulted; there are no partitions to assign records to. - No sort: the in-memory sort buffer and its spills to local disk are bypassed entirely. - No combiner: a class registered with `setCombinerClass` is silently never invoked, because combining exists only to shrink what the shuffle carries. - No copy phase, no reduce-side merge, no `reduce()` call. Instead, the map task's `Context.write` goes straight to a `RecordWriter` created by the job's `OutputFormat`, writing to a task-attempt temporary directory in the output path. The `OutputCommitter` promotes each successful attempt to the final location, so a retried or speculative attempt cannot leave a half-written file behind. Output files are named `part-m-00000`, `part-m-00001`, … — the `m` is the tell that no reducer ran, and a useful thing to notice when reading someone else's output directory. ## Why it is so much faster Everything expensive about MapReduce lives in the shuffle: serializing and sorting every intermediate record, spilling to local disk, merging spills, transferring bytes across the network to every reducer, and merge-sorting them again. A map-only job pays none of it. Runtime becomes roughly the time to read the input and write the output, and the job scales linearly with map parallelism. Where a shuffling job's cost grows with intermediate data volume and skew, a map-only job's does not. ## What it is good for Map-only jobs are the right shape whenever the computation is per-record and needs no cross-record grouping: - filtering rows against a predicate - format conversion, for example text to Avro, ORC or Parquet - projection and column pruning - masking, tokenizing or otherwise transforming fields - lookup-style enrichment where a small dimension file is shipped via the distributed cache and held in a map in each mapper — a map-side join - bulk file copying, which is exactly how `distcp` works The distributed-cache map-side join is worth naming explicitly: if one side of a join is small enough to fit in a mapper's memory, joining it in the map phase eliminates the shuffle entirely, which is the same idea a broadcast join expresses in later engines. ## The other half of the knob Because the default is 1, a job that genuinely needs a reduce phase but never sets a count sends every key through one reduce task on one node. That job will appear to progress quickly to "map 100%, reduce 33%" and then crawl. Sizing reducers is a matter of aiming for a reasonable amount of data per reducer — enough that container startup is amortized, small enough that a reducer's merge and output stay comfortable — and staying within the parallelism the queue will actually grant you. Too many reducers is also a real cost: each one produces a file, so a large reduce count over a small dataset manufactures the small-files problem in the output directory. ## What an interviewer is checking This is a small question that separates people who have used MapReduce from people who have only read about it. Knowing that the shuffle is optional, that `part-m` versus `part-r` tells you which shape ran, and that a combiner is dead code in a map-only job, all signal real exposure.