Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <23082769.1176919237691.JavaMail.jira@brutus>
Date: Wed, 18 Apr 2007 11:00:37 -0700 (PDT)
From: "Runping Qi (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-485) allow a different comparator for
 grouping keys in calls to reduce
In-Reply-To: <18308270.1156578742395.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489837 ] 

Runping Qi commented on HADOOP-485:
-----------------------------------


You want to control the partitioning as well.
For example, let's we have the following map output:

PK1, SK11, V1
PK1, SK12, V2
PK2, SK21, V3
PK2, SK22, V4

where PKi are primary keys and SKij are secondary keys.
What you want is that all the tuples with same primary keys will go to the same reducer.
Within the same reducer, the tuples are sorted by the primary/secondary keys.
When passing to reduce calls, you want the primary key wil be the key to reduce call, and the values with the same primary key 
will be passed to the reduce call, in the sorted order by the secondary keys.


> allow a different comparator for grouping keys in calls to reduce
> -----------------------------------------------------------------
>
>                 Key: HADOOP-485
>                 URL: https://issues.apache.org/jira/browse/HADOOP-485
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: mapred
>    Affects Versions: 0.5.0
>            Reporter: Owen O'Malley
>         Assigned To: Tahir Hashmi
>         Attachments: Hadoop-485-pre.patch, TestUserValueGrouping.java.patch
>
>
> Some algorithms require that the values to the reduce be sorted in a particular order, but extending the key with the additional fields causes  them to be handled by different calls to reduce. (The user then collects the values until they detect a "real" key change and then processes them.)
> It would be much easier if the framework let you define a second comparator that did the grouping of values for reduces. So your reduce inputs look like:
> A1, V1
> A2, V2
> A3, V3
> B1, V4
> B2, V5
> instead of getting calls to reduce that look like:
> reduce(A1, {V1}); reduce(A2, {V2}); reduce(A3, {V3}); reduce(B1, {V4}); reduce(B2, {V5});
> you could define the grouping comparator to just compare the letters and end up with:
> reduce(A1, {V1,V2,V3}); reduce(B1, {V4,V5});
> which is the desired outcome. Note that this assumes that the "extra" part of the key is just for sorting because the reduce will only see the first representative of each equivalence class.

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