A metropolitan planning office needs last year's mobility indices recomputed overnight from archived fare-tap and sensor files. Why is classic MapReduce a strong fit?
Select an answer to reveal the explanation.
Short Explanation
Overnight recomputes are like baking a whole sheet of cookies, not plating one at a time. Classic MapReduce loves big historical scans that can finish by morning. Live per-tap flags and OLTP checkout belong to other tools.
Full Explanation
Classic MapReduce is a strong fit when a metropolitan planning office must recompute last year’s mobility indices overnight from archived fare-tap and sensor files because it is designed for large-scale batch jobs that scan historical data and finish on a schedule. It is not meant to return a sub-millisecond decision on each tap as riders board—that is an online serving problem. It does not permanently replace the city’s OLTP ticketing database as the system of record for fare media. It is a poor fit when every record must update a live NoSQL row within 50 ms; that latency shape needs a different path. Exam caveat: MapReduce = batch historical scan/compute, not per-event online response. Operational check: schedule the overnight mobility recompute on the Hadoop batch cluster, gate morning planning views on job success, and keep live tap authorization off the MapReduce path. 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.