During a citywide log-parse MapReduce job, one mapper node crashes mid-task. What resilience behavior should operators expect in a classic MapReduce framework?
Select an answer to reveal the explanation.
Short Explanation
If one oven goes cold, move those trays to another oven—don't rebuild the kitchen. MapReduce retries failed tasks on healthy workers. It does not reformat the cluster or magically rewrite the job as Spark streaming.
Full Explanation
When one mapper node crashes mid-task during a citywide log-parse MapReduce job, operators should expect failed map tasks to be re-executed on other available worker nodes—classic framework resilience for municipal overnight jobs. The entire cluster does not need to be reformatted before any job can continue after a single mapper failure. Already-finished reducers should not discard their output and halt permanently solely because one mapper crashed; the framework retries failed tasks. HDFS does not automatically convert the job into a streaming Spark Structured Streaming query when a mapper fails. Exam caveat: task re-execution on other workers is the expected MapReduce fault-tolerance behavior. Operational check: kill a mapper container in a non-prod drill, confirm the task is reassigned and the job completes, and note retry counts in JobHistory for the runbook. In municipal platform operations, record the rationale in the architecture decision record so future on-call staff know which pattern was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that monitoring, access paths, and recovery steps still match the documented design for agencies that depend on this platform.