After mappers emit (reason-code, 1) pairs for municipal 311 tickets, what must the shuffle and group stages guarantee before reduce runs?
Select an answer to reveal the explanation.
Short Explanation
Think of sorting mail into one bin per zip code before anyone totals the letters. Shuffle and group pull every sticky note with the same reason code into the same reducer. Without that co-location, citywide tallies would be incomplete.
Full Explanation
After mappers emit (reason-code, 1) pairs for municipal 311 tickets, shuffle and group must guarantee that all intermediate values sharing the same reason-code key arrive together at one reducer so aggregation is correct. Every mapper writing pairs straight into a public open-data REST API skips the MapReduce shuffle contract and bypasses governed batch output paths. Converting all reason codes into floating-point embeddings for ML is an unrelated modeling step, not the shuffle/group guarantee. Randomly shuffling reducer inputs so no two identical keys share a task would destroy the grouping MapReduce depends on for totals. Exam caveat: same-key co-location at a reducer is the purpose of shuffle/group. Operational check: inspect partitioner behavior and reducer inputs for a hot reason code, confirming all its values land on the assigned reducer before sum. 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.