[
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833230#action_12833230
]
Owen O'Malley commented on MAPREDUCE-326:
-----------------------------------------
I have reservations about doubling the width of the *public* API by having both
a raw and object level APIs. That will make a much much harder problem to
guarantee compatibility and still enable us to make improvements to the sort
and shuffle.
It is a software engineering truism that if you can accomplish something in
library code, it is much better to do so rather than the framework. So instead
of making a new lower level API, I'd propose layering your API on top of the
object API.
So my proposal would be:
* All types (map input key and value, map output key and value, and reduce
output key and value) as ByteBuffer.
* Add a new method in the MapContext that takes write(int partition, KEYOUT
key, VALUEOUT value);
* Define a new class-based serialization that handles ByteBuffer input/output.
* There are already sequence file input/output formats that deal with binary
(SequenceFileAsBinary{Input|Output}Format)
With the context object API, the run method gets complete control and with the
extra write method, it would be easy to add new map/reduce APIs on top.
> 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.
