Why it matters
Cold data dominates the storage footprint of most analytical clusters. Historical logs, archived events, and old snapshots collectively account for the bulk of petabytes on production HDFS. Storing three copies of data that gets read once a month is wasteful when the primary durability requirement is data preservation, not read throughput.
Cutting storage overhead in half turns a hundred-petabyte cluster into a fifty-petabyte cluster with the same effective data volume. That directly saves capital expenditure on disks and reduces the physical footprint of the cluster. For cloud deployments, the savings are even more direct: less object storage means less monthly billing.
The architecture
The default EC scheme in HDFS is Reed-Solomon with six data cells and three parity cells, written as RS(6,3). A user-visible block is split into six equal-size cells, and three parity cells are computed from them using Galois-field arithmetic. All nine cells are then distributed across nine DataNodes on ideally nine different racks. This is a stripe: a group of cells belonging to the same original block.
The mathematical property of Reed-Solomon is that any six of the nine cells are sufficient to reconstruct the original data. This means up to three cell losses can be tolerated without losing data, which is the same tolerance as three-way replication (any two of three replicas can be lost). Durability is equivalent; the difference is in the space cost. RS(6,3) uses fifty percent overhead (three parity cells for six data cells), where three-way replication uses two hundred percent overhead (two extra copies for one original).
How it works end to end
Reading an erasure-coded file works simply if all cells are available: the client reads the six data cells in parallel from the six DataNodes hosting them and reassembles the block. There is no penalty compared to reading a replicated block, except that the read now involves six network connections instead of one.
Reading with cell loss is where the cost shows up. If any of the six data cells is missing, the client must fetch some of the parity cells and perform Reed-Solomon decoding to reconstruct the missing data cell. This is CPU-intensive and generates extra network traffic. On busy clusters, reconstruction storms during a large-scale failure can noticeably degrade cluster performance.
Writing is even more expensive. Every write requires computing the parity cells and distributing all nine cells to nine DataNodes. Compare this to replication, where the client streams data once and it is forwarded through the pipeline; EC writes involve more CPU and more distinct network destinations. This is why EC is a poor fit for hot write paths.