Uh oh!
There was an error while loading. Please reload this page.
[SPARK-19981][SQL] Respect aliases in output partitioning of projects and aggregates - #17400
[SPARK-19981][SQL] Respect aliases in output partitioning of projects and aggregates#17400maropu wants to merge 3 commits into
Conversation
SparkQA
commented
Mar 23, 2017
Test build #75104 has finished for PR 17400 at commit
|
Just curious, how come the fix is not in this code? So anywhere we compare expressions for semantic equality, we can say |
Here is a sort example with 1 partition. I believe the extra sort on |
ISTM the solution you suggested does not work because the planner actually compares references (that is, |
allengeorge
commented
Mar 29, 2017
I suggest the following code for |
maropu
commented
Apr 17, 2017
@allengeorge yea, we could there. But, I think we should first make sure about how to fix this issue. I'm not sure that the approach of this pr is the best. cc: @gatorsmile |
91a412e to
0492c0fCompareSparkQA
commented
May 10, 2017
Test build #76738 has finished for PR 17400 at commit
|
SparkQA
commented
May 10, 2017
Test build #76740 has finished for PR 17400 at commit
|
maropu
commented
May 16, 2017
ping |
There was a problem hiding this comment.
Could we fix the issue in EnsureRequirements? Aggregate operators can also introduce alias.
SparkQA
commented
May 17, 2017
Test build #77030 has finished for PR 17400 at commit
|
maropu
commented
May 18, 2017
Jenkins, retest this please. |
SparkQA
commented
May 18, 2017
Test build #77053 has finished for PR 17400 at commit
|
maropu
commented
May 20, 2017
@gatorsmile ping |
maropu
commented
May 23, 2017
ping |
SparkQA
commented
Jul 11, 2017
Test build #79520 has finished for PR 17400 at commit
|
SparkQA
commented
Dec 18, 2017
Test build #85034 has finished for PR 17400 at commit
|
eyalfa
commented
Aug 14, 2018
@maropu , any reason why this is on hold for so long? |
There was a problem hiding this comment.
this might do more than you'd like it to (at least if it behaves the way I understand collect first), i.e.df.select($"x" as "x1, struct($"a" as "a1", $"b" as "b1") as "s1")
x1 and s1 are aliases, a1 and b1 are not. it could even get more complicated if there was an a1 alias in the top level projections list.
There was a problem hiding this comment.
This pr only focuses on aliases, so the point you described above is out-of-scope in this pr. IMO more complicated cases should be fixed in follow-ups.
There was a problem hiding this comment.
@maropu , I didn't aim for supporting complex partitioning expressions (which deserves its own separate PR), I meant that this code could introduce regressions by 'over-capturing' nested aliases.
- my specific example is wrong since struct is transformed into a named struct (alias is replaced by an explicit name).
maropu
commented
Aug 14, 2018
I think that's because the priority is not much high. This issue causes any problem in your query? |
eyalfa
commented
Aug 14, 2018
@maropu , yes it does :-) |
maropu
commented
Aug 14, 2018
If possible, could you describe that problem in your case to encourage this work? |
eyalfa
commented
Aug 14, 2018
in my use case, I aggregate a dataset, the use select to align columns with a case-class. I later try to join the resulting dataset based on the same columns used for aggregattion. |
SparkQA
commented
Aug 21, 2018
Test build #94999 has finished for PR 17400 at commit
|
SparkQA
commented
Aug 21, 2018
Test build #95009 has finished for PR 17400 at commit
|
e288288 to
ec3e6d9CompareSparkQA
commented
Aug 22, 2018
Test build #95079 has finished for PR 17400 at commit
|
SparkQA
commented
Aug 22, 2018
Test build #95078 has finished for PR 17400 at commit
|
SparkQA
commented
Aug 22, 2018
Test build #95080 has finished for PR 17400 at commit
|
SparkQA
commented
Aug 22, 2018
Test build #95097 has finished for PR 17400 at commit
|
SparkQA
commented
Aug 22, 2018
Test build #95102 has finished for PR 17400 at commit
|
maropu
commented
Sep 14, 2018
retest this please |
SparkQA
commented
Sep 14, 2018
Test build #96061 has finished for PR 17400 at commit
|
maropu
commented
Sep 17, 2018
retest this please |
| import org.apache.spark.sql.catalyst.expressions.{Alias, Expression, NamedExpression} | ||
| import org.apache.spark.sql.catalyst.plans.physical._ | ||
| trait AliasAwareOutputPartitioning extends UnaryExecNode { |
There was a problem hiding this comment.
We might need a general utility class for this. cc @maryannxue She did the similar things for the other projects in the past. Maybe @maryannxue can help deliver such a utility class?
SparkQA
commented
Sep 18, 2018
Test build #96161 has finished for PR 17400 at commit
|
maropu
commented
Sep 18, 2018
retest this please |
SparkQA
commented
Sep 18, 2018
Test build #96164 has finished for PR 17400 at commit
|
SparkQA
commented
Oct 22, 2018
Test build #97746 has finished for PR 17400 at commit
|
SparkQA
commented
Oct 22, 2018
Test build #97753 has finished for PR 17400 at commit
|
SparkQA
commented
Oct 22, 2018
Test build #97788 has finished for PR 17400 at commit
|
What changes were proposed in this pull request?
The current master might wrongly add shuffle operations when projects and aggregates in physical plans have aliases in output expressions. A concrete example is as follows;
In the query, the second
Exchangeis not necessary. The root cause is that the planner wrongly regardskeyandkas different attributes because they have differentexprId. Then, it fails distribution requirement checks inEnsureRequirements. This pr proposes to handle these aliases inEnsureRequirementsso as to check if the operators satisfy their output distribution requirements.How was this patch tested?
Added tests in
SQLQueryTestSuite.