[
https://issues.apache.org/jira/browse/MAPREDUCE-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446093#comment-13446093
]
Mariappan Asokan commented on MAPREDUCE-4049:
---------------------------------------------
Hi Avner,
Please take a look at MAPREDUCE-2454 patch. There, I wanted to decouple the
merge from shuffle to make the reduce sort pluggable. However, presumably you
want to retain that coupling for a reason namely RDMA merge which takes care of
both shuffle and merge. We seem to have conflict of interest here:)
In order to resolve this conflict, I have the following suggestion:
We can make the {{ShuffleRunner}} which is defined as below as pluggable:
{code:title=ShuffleRunner.java|borderStyle=solid}
public interface ShuffleRunner extends ExceptionReporter {
public void run(ShuffleCallback shuffleCallback)
throws IOException, InterruptedException;
}
{code}
where {{ShuffleCallback}} is defined as:
{code:title=ShuffleCallback.java|borderStyle=solid}
public interface ShuffleCallback {
public void waitForResource() throws InterruptedException;
public MapOutput reserve(TaskAttemptID mapId, long shuffleSize, int fetcherId)
throws IOException;
public void close() throws Throwable;
}
{code}
With MAPREDUCE-2454 patch, {{MergeManager}} or external sort implementations
implement {{ShuffleCallback}}.
When {{createShuffleRunner()}} in {{ReduceTask}} is called(see the
MAPREDUCE-2454 patch), it can return either the default implementation which is
an instance of {{Shuffle}} class itself or a plugin implementation.
Now, in order to do the RDMA merge, you can implement {{ShuffleRunner}},
{{ShuffleCallback}}, and {{SortPlugin}}. Your {{ShuffleRunner}} and
{{ShuffleCallback}} implementations will do nothing. {{SortPlugin}} will use
{{DefaultMapSortPlugin}} for map side sort and you provide your
{{ReduceSortPlugin}} implementation which is going to do the RDMA merge.
How does this sound? I would like to hear from Arun and others on this idea.
Thanks.
-- Asokan
> plugin for generic shuffle service
> ----------------------------------
>
> Key: MAPREDUCE-4049
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4049
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: performance, task, tasktracker
> Affects Versions: 1.0.3, 1.1.0, 2.0.0-alpha, 3.0.0
> Reporter: Avner BenHanoch
> Labels: merge, plugin, rdma, shuffle
> Attachments: HADOOP-1.x.y.patch, Hadoop Shuffle Consumer Plugin
> TLD.rtf, Hadoop Shuffle Provider Plugin TLD.rtf, mapred-site.xml,
> mapreduce-4049.patch, mapreduce-4049.patch
>
>
> Support generic shuffle service as set of two plugins: ShuffleProvider &
> ShuffleConsumer.
> This will satisfy the following needs:
> # Better shuffle and merge performance. For example: we are working on
> shuffle plugin that performs shuffle over RDMA in fast networks (10gE, 40gE,
> or Infiniband) instead of using the current HTTP shuffle. Based on the fast
> RDMA shuffle, the plugin can also utilize a suitable merge approach during
> the intermediate merges. Hence, getting much better performance.
> # Satisfy MAPREDUCE-3060 - generic shuffle service for avoiding hidden
> dependency of NodeManager with a specific version of mapreduce shuffle
> (currently targeted to 0.24.0).
> References:
> # Hadoop Acceleration through Network Levitated Merging, by Prof. Weikuan Yu
> from Auburn University with others,
> [http://pasl.eng.auburn.edu/pubs/sc11-netlev.pdf]
> # I am attaching 2 documents with suggested Top Level Design for both plugins
> (currently, based on 1.0 branch)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
