[ 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: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org