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

Bikas Saha commented on MAPREDUCE-4892:
---------------------------------------

I meant unnecessary computations for nodes that are not going to produce more 
splits in every iteration. The code will try to group any remaining blocks and 
fail to produce a meaningful split. And it will do this again and again.

In the example, we could end up generating 5, 1, 3 or 4, 1, 4 splits by trying 
to be completely node local. Or we could go 3, 1, 3 and 2 rack-local. Upon 
scheduling the rack-local option would start 3, 3, 3 if there are 3 slots per 
node. The extra node local ones would have to wait  for nodes 1 and 3 to finish 
the first wave before they can run. Or wait for delay scheduling to kick in and 
get scheduled on node 2. Which of these will be faster is not obvious.

In any case, we can debate this endlessly. I have attached an alternative patch 
which iterates multiple times over nodes until it all blocks have been grouped 
or no node if left with more than minsize of blocks, while trying to keep 
number of iterations low.
                
> CombineFileInputFormat node input split can be skewed on small clusters
> -----------------------------------------------------------------------
>
>                 Key: MAPREDUCE-4892
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-4892
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>            Reporter: Bikas Saha
>            Assignee: Bikas Saha
>             Fix For: 3.0.0
>
>         Attachments: MAPREDUCE-4892.1.alt.patch, MAPREDUCE-4892.1.patch
>
>
> The CombineFileInputFormat split generation logic tries to group blocks by 
> node in order to create splits. It iterates through the nodes and creates 
> splits on them until there aren't enough blocks left on a node that can be 
> grouped into a valid split. If the first few nodes have a lot of blocks on 
> them then they can end up getting a disproportionately large share of the 
> total number of splits created. This can result in poor locality of maps. 
> This problem is likely to happen on small clusters where its easier to create 
> a skew in the distribution of blocks on nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to