Skip to content

Conversation

@curtishoward
Copy link
Collaborator

…and KeyValueGroupedDataset's child

When we create a RelationalGroupedDataset or a KeyValueGroupedDataset we set its child to the logicalPlan of the DataFrame we need to aggregate. Since the logicalPlan is already analyzed, we should not analyze it again. But this happens when the new plan of the aggregate is analyzed.

The current behavior in most of the cases is likely to produce no harm, but in other cases re-analyzing an analyzed plan can change it, since the analysis is not idempotent. This can cause issues like the one described in the JIRA (missing to find a cached plan).

The PR adds an AnalysisBarrier to the logicalPlan which is used as child of RelationalGroupedDataset or a KeyValueGroupedDataset.

added UT

Author: Marco Gaido [email protected]

Closes apache#21432 from mgaido91/SPARK-24373.

(cherry picked from commit de01a8d)

What changes were proposed in this pull request?

(Please fill in changes proposed in this fix)

How was this patch tested?

(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)

(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

…and KeyValueGroupedDataset's child

When we create a `RelationalGroupedDataset` or a `KeyValueGroupedDataset` we set its child to the `logicalPlan` of the `DataFrame` we need to aggregate. Since the `logicalPlan` is already analyzed, we should not analyze it again. But this happens when the new plan of the aggregate is analyzed.

The current behavior in most of the cases is likely to produce no harm, but in other cases re-analyzing an analyzed plan can change it, since the analysis is not idempotent. This can cause issues like the one described in the JIRA (missing to find a cached plan).

The PR adds an `AnalysisBarrier` to the `logicalPlan` which is used as child of `RelationalGroupedDataset` or a `KeyValueGroupedDataset`.

added UT

Author: Marco Gaido <[email protected]>

Closes apache#21432 from mgaido91/SPARK-24373.

(cherry picked from commit de01a8d)
@curtishoward curtishoward requested a review from WenboZhao May 30, 2018 01:59
@icexelloss
Copy link
Member

@curtishoward is this just a cherry-pick? If so, we don't need to review this.

@curtishoward
Copy link
Collaborator Author

Hi @icexelloss - OK, I'll close these two PRs then, and discuss with Wenbo before pushing my changes. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants