A municipal data platform already runs nightly MapReduce batch jobs on HDFS and plans NoSQL serving plus Spark streaming next. How should leaders view MapReduce's place?
Select an answer to reveal the explanation.
Short Explanation
Think of a transit yard with overnight freight trains and daytime express buses—different vehicles, same city. MapReduce batch can sit beside NoSQL serving and Spark streams. You do not scrap the freight line to add buses.
Full Explanation
Leaders should view MapReduce batch on HDFS as able to coexist with NoSQL serving and Spark streaming for other latency shapes on a municipal data platform—paradigms complement rather than mutually annihilate when architectures are layered by need. MapReduce must not be deleted before any NoSQL store or Spark job is allowed; that is a false exclusivity. MapReduce is not the only BDPC technology permitted with NoSQL and Spark always forbidden; the syllabus includes multiple paradigms. Installing MapReduce does not automatically fulfill every CAP theorem trade-off for OLTP checkout; CAP and OLTP concerns remain separate design spaces. Exam caveat: BDPC expects coexistence of batch, serving, and streaming patterns matched to civic latency needs. Operational check: keep nightly MapReduce on HDFS for historical batch, introduce NoSQL for low-latency lookups, add Spark streaming for near-real-time sensors, and document which SLA each path owns. 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.