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

Eric Payne commented on MAPREDUCE-6166:
---------------------------------------

[~jira.shegalov], I have one question about re-using the {{input.read}} code in 
{{OnDisMapOutput}}.
{quote}
We can set 
{code}
long bytesLeft = compressedLength - ((IFileInputStream)input).getSize()
{code}
Then we don't need to touch the line {{input.read}} to do {{readWithChecksum}}
{quote}
In this case, {{input.read}} does not write the checksum to the disk while 
{{readWithChecksum}} will write it.

Since {{OnDiskMapOutput}} is shuffling the whole IFile to disk, the checksum is 
needed later during the last merge pass when the IFile contents are read again 
and decompressed.

If we were to implement {{input.read}} as above, it looks like we would still 
need to add something like the following in order to put the checksum on the 
disk:
{code}
disk.write(((IFileInputStream)input).getChecksum(), 0, (int) 
((IFileInputStream)input).getSize());
{code}

> Reducers do not catch bad map output transfers during shuffle if data 
> shuffled directly to disk
> -----------------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-6166
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6166
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv2
>    Affects Versions: 2.6.0
>            Reporter: Eric Payne
>            Assignee: Eric Payne
>         Attachments: MAPREDUCE-6166.v1.201411221941.txt, 
> MAPREDUCE-6166.v2.201411251627.txt
>
>
> In very large map/reduce jobs (50000 maps, 2500 reducers), the intermediate 
> map partition output gets corrupted on disk on the map side. If this 
> corrupted map output is too large to shuffle in memory, the reducer streams 
> it to disk without validating the checksum. In jobs this large, it could take 
> hours before the reducer finally tries to read the corrupted file and fails. 
> Since retries of the failed reduce attempt will also take hours, this delay 
> in discovering the failure is multiplied greatly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to