[
https://issues.apache.org/jira/browse/HADOOP-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-3702:
---------------------------------------
Attachment: patch3702.txt
I've got Enis point of making use of generics in the {{addMapper}} and
{{setReducer}} methods in the {{Chain*}} classes. This enforces a compile time
type check between the defined key/value in/out classes and the mapper/reducer
classes when defining the chain. I've modified the patch to do so.
An additional question on this. Currently the {{addMapper}} and {{setReducer}}
signatures are like:
{code}
public static <K1, V1, K2, V2> void addMapper(boolean isMap, JobConf jobConf,
Class<? extends Mapper<K1, V1, K2, V2>> klass,
Class<K1> inputKeyClass, Class<V1> inputValueClass,
Class<K2> outputKeyClass, Class<V2> outputValueClass,
boolean byValue, JobConf mapperConf) {
{code}
Shouldn't be appropriate to make them?
{code}
public static <K1, V1, K2, V2> void addMapper(boolean isMap, JobConf jobConf,
Class<? extends Mapper<? extends K1,? extends V1,?
extends K2,? extends V2>> klass,
Class<K1> inputKeyClass, Class<V1> inputValueClass,
Class<K2> outputKeyClass, Class<V2> outputValueClass,
boolean byValue, JobConf mapperConf) {
{code}
-----
Still, I don't agree on making the {{Chain*}} classes generic. Their generics
would not be use for any type checking at compilation. And it is not possible
to get rid of the [EMAIL PROTECTED]("unchecked")}} .
> add support for chaining Maps in a single Map and after a Reduce [M*/RM*]
> -------------------------------------------------------------------------
>
> Key: HADOOP-3702
> URL: https://issues.apache.org/jira/browse/HADOOP-3702
> Project: Hadoop Core
> Issue Type: New Feature
> Components: mapred
> Environment: all
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Fix For: 0.19.0
>
> Attachments: Hadoop-3702.patch, patch3702.txt, patch3702.txt,
> patch3702.txt, patch3702.txt, patch3702.txt, patch3702.txt, patch3702.txt,
> patch3702.txt, patch3702.txt, patch3702.txt, patch3702.txt, patch3702.txt
>
>
> On the same input, we usually need to run multiple Maps one after the other
> without no Reduce. We also have to run multiple Maps after the Reduce.
> If all pre-Reduce Maps are chained together and run as a single Map a
> significant amount of Disk I/O will be avoided.
> Similarly all post-Reduce Maps can be chained together and run in the Reduce
> phase after the Reduce.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
