MapReduce job execution flow in Hadoop - Time & Space Complexity
We want to understand how the time to run a MapReduce job changes as the input data grows.
How does the job's execution time grow when we add more data to process?
Analyze the time complexity of the following MapReduce job execution flow.
// Simplified MapReduce job flow
Job job = new Job(conf, "word count");
job.setMapperClass(WordCountMapper.class);
job.setReducerClass(WordCountReducer.class);
job.setInputFormatClass(TextInputFormat.class);
job.setOutputFormatClass(TextOutputFormat.class);
FileInputFormat.addInputPath(job, new Path(inputPath));
FileOutputFormat.setOutputPath(job, new Path(outputPath));
job.waitForCompletion(true);
This code sets up and runs a MapReduce job that counts words in input files.
- Primary operation: The Mapper processes each input record once.
- How many times: Once per input record, so as many times as there are records.
- Secondary operation: The Reducer processes each unique key and its values.
- How many times: Once per unique key, which depends on data.
As input data grows, the Mapper runs more times, once per record.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 map operations |
| 100 | About 100 map operations |
| 1000 | About 1000 map operations |
Pattern observation: The number of map operations grows directly with input size.
Time Complexity: O(n)
This means the job's running time grows roughly in direct proportion to the amount of input data.
[X] Wrong: "The Reducer runs once regardless of input size."
[OK] Correct: The Reducer runs once per unique key, so if input grows and produces more unique keys, the Reducer work also grows.
Understanding how MapReduce scales with data size helps you explain how big data jobs handle growth efficiently.
"What if we added a Combiner step before the Reducer? How would the time complexity change?"
Practice
Map task in a MapReduce job?Solution
Step 1: Understand the Map task function
The Map task reads input data and transforms it into intermediate key-value pairs.Step 2: Differentiate from Reduce task
The Reduce task aggregates these key-value pairs, so it is not responsible for initial processing.Final Answer:
Process input data and create key-value pairs -> Option AQuick Check:
Map task = create key-value pairs [OK]
- Confusing Map with Reduce task role
- Thinking Map stores final output
- Assuming Map schedules tasks
Solution
Step 1: Recall MapReduce execution order
The job starts with Map tasks processing input, then Shuffle sorts and transfers data, followed by Reduce tasks aggregating results.Step 2: Match sequence to options
Only Map -> Shuffle -> Reduce correctly shows Map first, then Shuffle, then Reduce.Final Answer:
Map -> Shuffle -> Reduce -> Option AQuick Check:
Execution order = Map, Shuffle, Reduce [OK]
- Mixing up Shuffle and Map order
- Placing Reduce before Map
- Ignoring Shuffle step
map(String key, String value) {
emit(value, 1);
}
reduce(String key, Iterator values) {
int sum = 0;
while (values.hasNext()) {
sum += values.next();
}
emit(key, sum);
}What will be the output for input:
["a", "apple"], ["b", "apple"], ["c", "banana"]?Solution
Step 1: Analyze Map output
Map emits (value, 1) pairs: ('apple',1), ('apple',1), ('banana',1).Step 2: Analyze Reduce aggregation
Reduce sums counts for each key: 'apple' = 1+1=2, 'banana' = 1.Final Answer:
[('apple', 2), ('banana', 1)] -> Option CQuick Check:
Count of 'apple' = 2, 'banana' = 1 [OK]
- Counting keys instead of values
- Confusing input keys with values
- Adding counts incorrectly
Map task reads input and emits key-value pairs.
Reduce task tries to read input directly from HDFS instead of shuffle output.
Reduce task aggregates values by key.
Solution
Step 1: Understand Reduce input source
Reduce tasks receive data from the shuffle phase, not directly from HDFS input files.Step 2: Identify incorrect flow
Reading directly from HDFS in Reduce breaks the flow and causes errors.Final Answer:
Reduce task should read from shuffle output, not directly from HDFS -> Option DQuick Check:
Reduce reads shuffle output [OK]
- Thinking Reduce reads input files
- Swapping Map and Reduce roles
- Ignoring shuffle phase
Solution
Step 1: Understand filtering impact
Filtering early reduces data volume, saving network and processing time.Step 2: Apply filter in Map task
Filtering in Map avoids sending unnecessary data to shuffle and Reduce phases.Final Answer:
In the Map task before emitting key-value pairs -> Option BQuick Check:
Filter early in Map for best performance [OK]
- Filtering only in Reduce wastes resources
- Trying to filter during shuffle (not possible)
- Filtering after job completion is too late
Ready to prove it?
Pass the test and this pattern moves unknown
