[
https://issues.apache.org/jira/browse/MAPREDUCE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833288#action_12833288
]
Chris Dyer commented on MAPREDUCE-326:
--------------------------------------
bq. It would help discussion if Pig, Hive, or Avro had a concrete use case
demonstrating a clear performance win that cannot be implemented in the current
API.
I haven't commented on this thread yet, but I've been following with interest
since I am a representative of the (evidently small) minority of Hadoop users
who don't use Java, and a really solid MapReduce API that doesn't depend on the
Java type system seems to me to be our best hope of promoting non-Java
languages to be first class citizens in Hadoop. I agree thinking in terms of
use cases (hopefully several) is an excellent idea, and I would strenuously
support picking a *non-Java* use-case, such as the Pipes interface, to evaluate
proposals against. Currently, the Pipes implementation does things like
allocate a new array for every byte array object read (search for the
declaration of {{readObject}} in
http://svn.apache.org/repos/asf/hadoop/mapreduce/trunk/src/java/org/apache/hadoop/mapred/pipes/BinaryProtocol.java),
and the whole data flow is fairly insane: marshalling opaque non-Java data up
into Java objects that have their own--admittedly limited--semantics. Anyway,
I think a tremendously beneficial outcome of this project would be a Pipes /
streaming workflow that is more natural and which has the same overhead as the
Java workflow.
> 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.
