Which HDFS characteristic best matches typical Big Data analytics workloads for municipal archives?
Select an answer to reveal the explanation.
Short Explanation
HDFS likes big files you write once and read a lot, like a city’s archived sensor lakes. It is not a cash register clicking tiny updates all day.
Full Explanation
Typical municipal archive workloads match HDFS characteristics that favor large files and write-once/read-many patterns suited to analytical scans—not millions of tiny random transactional updates. Sensor lakes and meter history are scanned repeatedly for analytics and planning far more often than they are randomly rewritten in place like point-of-sale tickets at a counter window. HDFS is not optimized primarily like a transactional point-of-sale system for tiny random updates across millions of keys each second. It is not designed so every byte must be rewritten in place many times per second as a classic OLTP engine would expect for balances and carts. It does not prefer interactive single-row OLTP edits over large analytical scans of archived civic data for mobility, utilities, and open-data products. Exam caveat: write-once/read-many and large-file analytics versus OLTP is a standard HDFS positioning question; mixing the models causes both design failures and exam errors. Operational check: land archives as large columnar or sequence files, avoid tiny-file storms from naive per-event ingest, keep transactional permitting edits on the SQL system of record, and let HDFS serve analytical read-many scans for planning and publication pipelines.