A city 311 desk runs a MapReduce job over complaint tickets so analysts can tally each reason code. What should each mapper emit during the map phase?
Select an answer to reveal the explanation.
Short Explanation
Picture each mapper as a clerk stamping one sticky note per ticket: reason code on the left, a lonely 1 on the right. Those intermediate pairs are the map phase's job—not final citywide totals. Later stages do the grouping and summing.
Full Explanation
In a MapReduce tally of 311 complaint tickets, each mapper should emit intermediate key/value pairs such as (reason-code, 1) for later grouping and summing—not final citywide dashboard rows. The map phase produces partial signals; reduce produces totals for municipal analysts. Emitting a final dashboard row with every reason code already totaled for the whole city from each mapper incorrectly collapses reduce work into map and cannot combine correctly across splits. A single global accumulator object shared across all mapper JVMs breaks the MapReduce programming model’s isolation assumptions. A sorted HDFS directory of reducer output files ready for public download is an output of a finished job, not what mappers emit during the map phase. Exam caveat: mappers emit intermediates; reducers aggregate—do not swap those responsibilities. Operational check: sample map output for a 311 job and confirm pairs look like (reason-code, 1) before shuffle, then reconcile reducer totals to a control extract. 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.