A parks department has a 2 GB CSV of playground inspection notes used by three analysts. What is the sound capacity judgment?
Select an answer to reveal the explanation.
Short Explanation
You do not rent a freight train to move a backpack. A 2 GB parks CSV for a few analysts is backpack-sized—desktop or ordinary database tools fit. Multi-node Hadoop is for large-scale workloads, not every file.
Full Explanation
A 2 GB parks CSV of playground inspection notes used by three analysts does not justify a multi-node Hadoop cluster—sound capacity judgment matches platform cost and complexity to data scale and concurrency for the department. Standing up a multi-rack Hadoop cluster because any CSV supposedly requires HDFS blocks over-provisions and wastes civic budget. Mandating MapReduce for every filter even when a desktop tool finishes in seconds adds operational complexity without analytical benefit. Replacing the CSV with a Kafka cluster before anyone may open the file confuses streaming ingest infrastructure with a small departmental working file. Exam caveat: BDPC expects right-sizing—Hadoop is for large-scale problems, not every spreadsheet in city hall. Operational check: keep the parks CSV on a managed share or lightweight warehouse table, document why Hadoop was not selected, and revisit only if volume or concurrent analytics grow by orders of magnitude. 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.