Meter archive files must be processed in parallel across the cluster. What foundational distributed-computing practice enables that parallelism?
Select an answer to reveal the explanation.
Short Explanation
Parallel jobs need the data already sliced across machines. Think many mail carriers each taking a street instead of one carrier walking the whole city.
Full Explanation
Processing meter archive files in parallel across the cluster depends on splitting or sharding data across machines so tasks can run on partitions concurrently. Foundational distributed computing partitions both work and data; without splits, adding nodes cannot create useful parallelism for the municipal archive job no matter how many idle CPUs exist. Keeping the entire archive as one unsplittable blob on a single disk forever serializes work and defeats the purpose of buying a cluster. Requiring sequential reads on one workstation before any cluster job starts reintroduces the single-server bottleneck the city is trying to escape. Encrypting filenames only, without distributing block contents across nodes, does not create parallel data locality or partitioned task input for MapReduce-style work. Exam caveat: input split or shard is the conceptual enabler of map-style parallelism—not merely purchasing more nodes or faster disks. Operational check: verify meter archives land as splittable large files or partitioned datasets on HDFS, confirm map tasks schedule across DataNodes holding those blocks, reject packaging that forces a single unsplittable sequential read, and document the split strategy in the utilities data playbook.