[
https://issues.apache.org/jira/browse/MAPREDUCE-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204264#comment-17204264
]
Daryn Sharp commented on MAPREDUCE-7282:
----------------------------------------
I'm also -1 on changing the default. It exposes users to new (old but new to
them) behavior that may have quirks. This was a 2.7 change from 5 years ago so
if it's a high risk issue our customers would have squawked by now. Has this
been frequently observed or theorized?
Notably our users won't tolerate the performance regression and SLA misses. I
seem to recall jobs that ran for a single-digit minutes followed by a
double-digit commit. The v2 commit amortized the commit to under a minute.
I'm not a MR expert. Here's my understanding:
{quote}if a task commit fails partway through and another task attempt commits
-unless exactly the same filenames are used, output of the first attempt may be
included in the final result
{quote}
Isn't that indicative of a non-deterministic job? Should the risk to a few
"bad" jobs outweigh the benefit to the mass majority of jobs? Why not change
the committer for at risk jobs?
{quote}if a worker partitions partway through task commit, and then continues
after another attempt has committed, it may partially overwrite the output
-even when the filenames are the same
{quote}
I don't think this can happen. Tasks request permission from the AM to commit.
> MR v2 commit algorithm should be deprecated and not the default
> ---------------------------------------------------------------
>
> Key: MAPREDUCE-7282
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-7282
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 3.3.0, 3.2.1, 3.1.3, 3.3.1
> Reporter: Steve Loughran
> Priority: Major
>
> The v2 MR commit algorithm moves files from the task attempt dir into the
> dest dir on task commit -one by one
> It is therefore not atomic
> # if a task commit fails partway through and another task attempt commits
> -unless exactly the same filenames are used, output of the first attempt may
> be included in the final result
> # if a worker partitions partway through task commit, and then continues
> after another attempt has committed, it may partially overwrite the output
> -even when the filenames are the same
> Both MR and spark assume that task commits are atomic. Either they need to
> consider that this is not the case, we add a way to probe for a committer
> supporting atomic task commit, and the engines both add handling for task
> commit failures (probably fail job)
> Better: we remove this as the default, maybe also warn when it is being used
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
