[
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829738#action_12829738
]
Joydeep Sen Sarma commented on MAPREDUCE-326:
---------------------------------------------
+1 to the idea of moving sort out.
in hive - we have wanted to have the sort/partition/merge done in the (hive)
application land. that way there's only map-reduce+map-onl+map-only... type
jobs (other than the first map - sort/partition/merge live in hive) (this makes
sense where the output is already greatly shrunk by the first scan - which is a
common case). scheduling related latencies are a lot worse than actual
execution time for small jobs and this would almost surely improve latencies
for end users.
regardless - one would think there's gotta be some big perf win to moving these
compute intensive parts from out from java.
> 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
>
> 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.
