I believe that you are correct about the split processing.  It orders the 
splits by size so that the largest splits are processed first.  This allows for 
the smaller splits to potentially fill in the gaps.  As far as a fix is 
concerned I think overriding the file name in the file output committer is a 
much more straight forward solution to the issue.

--Bobby Evans

On 5/5/12 10:50 AM, "Jim Donofrio" <donofrio...@gmail.com> wrote:

I am trying to use a map side join to merge the output of multiple map
side joins. This is failing because of the below code in
JobClient.writeOldSplits which reorders the splits from largest to
smallest. Why is that done, is that so that the largest split which will
take the longest gets processed first?

Each map side join then fails to name its part-* files with the same
number as the incoming partition so files that named part-00000 that go
into the first map side join get outputted to part-00010 while another
one of the first level map side joins sends files named part-00000 to
part-00005. The second level map side join then does not get the input
splits in partitioner order from each first level map side join output
directory.

I can think of only 2 fixes, add some conf property to allow turning off
the below sorting OR extend FileOutputCommitter to rename the outputs of
the first level map side join to merge_part-the orginal partition
number. Any other solutions?

     // sort the splits into order based on size, so that the biggest
     // go first
     Arrays.sort(splits, new
Comparator<org.apache.hadoop.mapred.InputSplit>() {
       public int compare(org.apache.hadoop.mapred.InputSplit a,
                          org.apache.hadoop.mapred.InputSplit b) {
         try {
           long left = a.getLength();
           long right = b.getLength();
           if (left == right) {
             return 0;
           } else if (left < right) {
             return 1;
           } else {
             return -1;
           }

Reply via email to