Affects Version/s: None
Fix Version/s: 0.17.0
Release Note:Reducers now perform merges of shuffle data (both in-memory and on disk) while fetching map outputs. Earlier, during shuffle they used to merge only the in-memory outputs.
Proposal to extend the parallel in-memory-merge/copying, that is being done as part of
HADOOP-830, to the on-disk files.
Today, the Reduces dump the map output files to disk and the final merge happens only after all the map outputs have been collected. It might make sense to parallelize this part. That is, whenever a Reduce has collected io.sort.factor number of segments on disk, it initiates a merge of those and creates one big segment. If the rate of copying is faster than the merge, we can probably have multiple threads doing parallel merges of independent sets of io.sort.factor number of segments. If the rate of copying is not as fast as merge, we stand to gain a lot - at the end of copying of all the map outputs, we will be left with a small number of segments for the final merge (which hopefully will feed the reduce directly (via the RawKeyValueIterator) without having to hit the disk for writing additional output segments).
If the disk bandwidth is higher than the network bandwidth, we have a good story, I guess, to do such a thing.
|Field||Original Value||New Value|
|Assignee||Gautam Kowshik [ gautamk ]|
|Assignee||Gautam Kowshik [ gautamk ]||Amar Kamat [ amar_kamat ]|
|Status||Patch Available [ 10002 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Fix Version/s||0.17.0 [ 12312913 ]|
|Release Note||Reducers now perform merges of shuffle data (both in-memory and on disk) while fetching map outputs. Earlier, during shuffle they used to merge only the in-memory outputs.|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Component/s||mapred [ 12310690 ]|