[
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833263#action_12833263
]
Doug Cutting commented on MAPREDUCE-326:
----------------------------------------
> If you are proposing that we make this the "real" interface, then I've
> already expressed my -1.
To be clear, do you reject any plan to incorporate a new low-level,
buffer-based MapReduce API that existing object-based MapReduce APIs would
layer on top of? The kernel would call only the new low-level API directly,
and library code would use the low-level API to compatibly implement the
existing API with no loss in performance. And you would veto any such approach?
If that's right, can you please provide a more exhaustive rationale for your
veto than, "users don't want to think in bytes". Since the existing API would
remain unchanged, user code would not need to be altered. So I don't
understand that rationale. Thanks!
> 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.
