[
https://issues.apache.org/jira/browse/HADOOP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616227#action_12616227
]
Doug Cutting commented on HADOOP-153:
-------------------------------------
I am concerned that this further complicates the already complicated JobTracker
and TaskTracker. Ideally we could layer this as a user library. Even if
that's not possible today, we should structure it so that we might transition
it to such an implementation. So, rather than adding more JobConf methods,
perhaps its configuration should be through static accessor methods on a
SkipBadRecords class?
Might it be possible to implement this through the filesystem? A MapRunnable
implementation could, when it catches exceptions, record the bad record
location to a task/attempt directory. Then, on startup, the MapRunnable could
list task/* files, to find all bad record locations generated by prior
invocations. Could that work? It shouldn't actually generate that many files,
since most tasks should not have errors. It would generate one extra listFiles
call to the namenode per task attempt, which doesn't seem too bad.
> skip records that throw exceptions
> ----------------------------------
>
> Key: HADOOP-153
> URL: https://issues.apache.org/jira/browse/HADOOP-153
> Project: Hadoop Core
> Issue Type: New Feature
> Components: mapred
> Affects Versions: 0.2.0
> Reporter: Doug Cutting
> Assignee: Sharad Agarwal
> Attachments: 153_1.patch, 153_2.patch, skipRecords_wip1.patch
>
>
> MapReduce should skip records that throw exceptions.
> If the exception is thrown under RecordReader.next() then RecordReader
> implementations should automatically skip to the start of a subsequent record.
> Exceptions in map and reduce implementations can simply be logged, unless
> they happen under RecordWriter.write(). Cancelling partial output could be
> hard. So such output errors will still result in task failure.
> This behaviour should be optional, but enabled by default. A count of errors
> per task and job should be maintained and displayed in the web ui. Perhaps
> if some percentage of records (>50%?) result in exceptions then the task
> should fail. This would stop jobs early that are misconfigured or have buggy
> code.
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
