hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joydeep Sen Sarma (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MAPREDUCE-326) The lowest level map-reduce APIs should be byte oriented
Date Thu, 04 Feb 2010 19:51:29 GMT

    [ 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.


Mime
View raw message