[
https://issues.apache.org/jira/browse/MAPREDUCE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041752#comment-14041752
]
Arun C Murthy commented on MAPREDUCE-2841:
------------------------------------------
{quote}
If the MR developer community generally agrees this belongs in the core, I'd
like to start a feature branch for it in order to import the current code, sort
out the build/integration issues, and take care of the remaining items that
Sean mentioned above.
{quote}
[~tlipcon] Thanks for starting this discussion. I have a few thoughts I'd like
to run by you.
I think the eventual goal of this (looking at
https://github.com/intel-hadoop/nativetask/blob/master/README.md) is a
full-native runtime for MapReduce including sort, shuffle, merge etc.
Hence, it does look like we will achieve a compatible, but alternate
implementation of MapReduce runtime. Hence, this is similar to other alternate
runtimes for MapReduce such as Apache Tez.
Furthermore, this is implemented in C++ - which is, frankly, a concern for the
poor job C++ has done with ABI. I'm glad to see that it doesn't rely on boost -
the worst affender. This is the same reason the native Hadoop client
(HADOOP-10388) is being done purely in C. Also, the MR development community is
pre-dominantly Java, which is something to keep in mind. This is a big concern
for me.
In all, it seems to me we could consider having this not in Apache Hadoop, but
as an incubator project to develop a native, MR compatible runtime.
This will allow it to develop a like-minded community (C++ skills etc.) and not
be bogged down by *all* of Hadoop's requirements such as security (how/when
will this allow for secure shuffle or encrypted shuffle etc.), compatibility
with several OSes (flavours of Linux, MacOSX, Windows) etc. It will also allow
them to ship independently and get user feedback more quickly.
Similarly, I am wary of importing a nearly 75K LOC codebase into a stable
project and it's impact on our releases on breakage - particularly given the
difference in skills of the community i.e. Java v/s C++ etc.
What do you think Todd & Sean? I'm more than happy to help with incubator
process if required.
> Task level native optimization
> ------------------------------
>
> Key: MAPREDUCE-2841
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2841
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: task
> Environment: x86-64 Linux/Unix
> Reporter: Binglin Chang
> Assignee: Sean Zhong
> Attachments: DESIGN.html, MAPREDUCE-2841.v1.patch,
> MAPREDUCE-2841.v2.patch, dualpivot-0.patch, dualpivotv20-0.patch,
> fb-shuffle.patch
>
>
> I'm recently working on native optimization for MapTask based on JNI.
> The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs
> emitted by mapper, therefore sort, spill, IFile serialization can all be done
> in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising
> results:
> 1. Sort is about 3x-10x as fast as java(only binary string compare is
> supported)
> 2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware
> CRC32C is used, things can get much faster(1G/
> 3. Merge code is not completed yet, so the test use enough io.sort.mb to
> prevent mid-spill
> This leads to a total speed up of 2x~3x for the whole MapTask, if
> IdentityMapper(mapper does nothing) is used
> There are limitations of course, currently only Text and BytesWritable is
> supported, and I have not think through many things right now, such as how to
> support map side combine. I had some discussion with somebody familiar with
> hive, it seems that these limitations won't be much problem for Hive to
> benefit from those optimizations, at least. Advices or discussions about
> improving compatibility are most welcome:)
> Currently NativeMapOutputCollector has a static method called canEnable(),
> which checks if key/value type, comparator type, combiner are all compatible,
> then MapTask can choose to enable NativeMapOutputCollector.
> This is only a preliminary test, more work need to be done. I expect better
> final results, and I believe similar optimization can be adopt to reduce task
> and shuffle too.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
