[ 
https://issues.apache.org/jira/browse/MAPREDUCE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805779#action_12805779
 ] 

Aaron Kimball commented on MAPREDUCE-1126:
------------------------------------------

Why are proposals now focusing on allowing users to specify different 
serialization *factories?*

If allowing users to specify the use of a particular {{SerializationBase}} via 
a flexible metadata map is considered too obscure, then I feel like the notion 
of having separate {{SerializationFactory}} instances seems to be an 
unnecessary level of abstraction. The current {{SerializationFactory}} 
implemented in hadoop-common allows access to all {{SerializationBase}} 
instances. If the focus is on user-accessibility of API, asking users to define 
a SerializationFactory which will only produce a single {{SerializationBase}} 
(e.g., {{WritableSerialization}} or {{AvroGenericSerialization}}) requires 
needless one-off code, and clutters the class hierarchy.

Instead, I might understand adding an API such as 
{{Job.setSerializationBase(ctxt, SerializationBase}}) where users directly set 
the {{SerializationBase}} instance to use in a given context, and disregard the 
{{SerializationFactory}} entirely.

For what it's worth, the patches that I and Tom have produced all make use of 
the default {{SerializationFactory}} in Hadoop; this API then uses the metadata 
map as defined in HADOOP-6165 to acquire the user's desired 
{{SerializationBase}} instance as appropriate for each of map output key, 
value, etc.


> shuffle should use serialization to get comparator
> --------------------------------------------------
>
>                 Key: MAPREDUCE-1126
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-1126
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: task
>            Reporter: Doug Cutting
>            Assignee: Aaron Kimball
>             Fix For: 0.22.0
>
>         Attachments: MAPREDUCE-1126.2.patch, MAPREDUCE-1126.3.patch, 
> MAPREDUCE-1126.4.patch, MAPREDUCE-1126.5.patch, MAPREDUCE-1126.6.patch, 
> MAPREDUCE-1126.patch, MAPREDUCE-1126.patch
>
>
> Currently the key comparator is defined as a Java class.  Instead we should 
> use the Serialization API to create key comparators.  This would permit, 
> e.g., Avro-based comparators to be used, permitting efficient sorting of 
> complex data types without having to write a RawComparator in Java.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to