[
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833248#action_12833248
]
Tom White commented on MAPREDUCE-326:
-------------------------------------
Thanks for looking at the proposal, Owen.
> 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.
This is not a risk since the API is marked "unstable" so we retain the freedom
to change it in any way we like. You can think of this change as a refactor to
make the MapReduce shuffle more accessible to framework developers, which will
make (e.g.) MAPREDUCE-1183, MAPREDUCE-1220 more straightforward.
>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.
I totally agree. I'm proposing that the new (context objects) MapReduce API is
implemented in library code. The idea here is to reduce the amount of kernel
code, which would be a good thing.
> So instead of making a new lower level API, I'd propose layering your API on
> top of the object API.
I think this is the wrong way round. The low-level API has fewer features than
the object API - for example it doesn't have the concept of record reader,
since this is done in higher-level framework code - whereas the low-level API
is designed to support the old and new Java APIs, and would be able to directly
support Streaming, Pipes, etc.
> 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.
