[ 
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834306#action_12834306
 ] 

Owen O'Malley commented on MAPREDUCE-326:
-----------------------------------------

Clearly if the argument to write is a ByteBuffer, then pipes could read 
straight into a DirectByteBuffer and send it straight to the map output 
collector at the cost of a single copy.

{code}
void write(int partition, ByteBuffer key, ByteBuffer value) throws IOException, 
InterruptedException;
{code}

That still leaves serializers doing a second copy and to avoid that, you need 
to invert the control and do something like:

{code}
public class RawKeyValueOutputStream extends DataOutputStream {
   public void startKey(int partition) throws IOException, InterruptedException;
   public void startValue() throws IOException, InterruptedException;
}
{code}

where you can write straight to the map output collector. Personally, I think 
the ByteBuffer approach is easier, but I can see arguments both ways.

However, there is still a bigger issue. At this point we are arguing about a 
single method to collect the raw map outputs. Why should we introduce a new 
level of abstraction that our users *absolutely* don't need? Wouldn't it make 
more sense to just add the method to MapContext to collect raw outputs?


> The lowest level map-reduce APIs should be byte oriented
> --------------------------------------------------------
>
>                 Key: MAPREDUCE-326
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-326
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>            Reporter: eric baldeschwieler
>         Attachments: MAPREDUCE-326-api.patch, MAPREDUCE-326.pdf
>
>
> As discussed here:
> https://issues.apache.org/jira/browse/HADOOP-1986#action_12551237
> The templates, serializers and other complexities that allow map-reduce to 
> use arbitrary types complicate the design and lead to lots of object creates 
> and other overhead that a byte oriented design would not suffer.  I believe 
> the lowest level implementation of hadoop map-reduce should have byte string 
> oriented APIs (for keys and values).  This API would be more performant, 
> simpler and more easily cross language.
> The existing API could be maintained as a thin layer on top of the leaner API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to