-
Notifications
You must be signed in to change notification settings - Fork 461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GLUTEN-4836][VL]Add support for WindowGroupLimitExec in gluten #5398
Conversation
Run Gluten Clickhouse CI |
1 similar comment
Run Gluten Clickhouse CI |
4ba85bb
to
ad22534
Compare
Run Gluten Clickhouse CI |
@JkSelf Could you please help with review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ayushi-agarwal Thanks for your great work.
@@ -319,6 +319,15 @@ message WindowRel { | |||
} | |||
} | |||
|
|||
message WindowGroupLimitRel { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ayushi-agarwal It seems that the only difference between WindowGroupLimitRel and WindowRel is the "limit" parameter? If that's the case, can we simply use WindowRel and pass the "limit" parameter through advanced_extension? This would prevent the introduction of a new operator in the Substrait code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JkSelf For now we are only supporting row number but later when we support rank and dense rank, then I was thinking that we would need an extra parameter for passing the function name, so I created the new operator. Shall that info also be passed in advanced_extension?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ayushi-agarwal Yes, it can be included in the advanced_extension. However, it appears that the WindowGroupLimitRel is intended to map to the TopNRowNumber operator, not the Window operator. Therefore, it make sense to introduce a new operator in Substrait for this purpose. @zhztheplayer Do you have any input?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Therefore, it make sense to introduce a new operator in Substrait for this purpose.
I am inclined to this approach, like adding a TopNRowNumberRel
or something in proto. 1:1 mapping from Velox's operator to Substrait / Gluten operator is definitely encouraged, like discussed in #5409 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make things fancier, we can even add a TopNRowNumberExec
in backends-velox
module then use a rule to convert Spark's WindowGroupLimitExec
conditionally to TopNRowNumberExec
. That would be the best method to solve this kind of operator-mapping problems.
However if you think WindowGroupLimitExec
and TopNRowNumberRel
don't have much semantic difference apart of the window function types they support, then we can do it without rules and it's also fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept it as WindowGroupLimitRel and not TopNRowNumberRel so that later we can use the same for rank and denseRank.
|
||
override def requiredChildOrdering: Seq[Seq[SortOrder]] = { | ||
if (BackendsApiManager.getSettings.requiredChildOrderingForWindowGroupLimit()) { | ||
// Velox StreamingTopNRowNumber need to require child order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ayushi-agarwal In Velox, the TopNRowNumber here will reorder the input channels based on the passed partition key and order by key here. Do we still need to set the sorting order in scala side? Moreover, it seems that this method is not used anywhere; can we remove it? If it is indeed necessary, can we construct it on the Velox native side based on the partition key and order by key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JkSelf In this case it will go in else part as TopNRowNumber does the sorting based on partition and order keys passed. But as spark already adds a sort operator, we don't need sorting to be done by TopNRowNumber operator as you mentioned it in point 3 here #4836 (comment). In that case we will need the if part. Please let me know if I understood it incorrectly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ayushi-agarwal My previous understanding was incorrect. We indeed require this check to confirm that the input data for the Window operator is pre-sorted by the partition key and the order-by key.
@ayushi-agarwal Can you help to resolve the conflicts? Thanks. |
ad22534
to
e2dd23e
Compare
Run Gluten Clickhouse CI |
@JkSelf I have updated it. |
@ayushi-agarwal Can you help to fix the following compile error in clickhouse backend?
|
e2dd23e
to
b853e71
Compare
Run Gluten Clickhouse CI |
@JkSelf I have rebased it. The compile issue was fixed a day back ayushi-agarwal@b4641c9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for your great work.
===== Performance report for TPCH SF2000 with Velox backend, for reference only ====
|
…he#5398) * Add support for WindowGroupLimitExec in gluten --------- Co-authored-by: ayushi agarwal <ayaga@microsoft.com>
@@ -495,6 +504,7 @@ message Rel { | |||
GenerateRel generate = 17; | |||
WriteRel write = 18; | |||
TopNRel top_n = 19; | |||
WindowGroupLimitRel windowGroupLimit = 20; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Substrait already has a field #20. This means that your Substrait is not going to be compatible with any other Substrait consumers or tools. The Substrait project is open to adding new relations -- all it takes is a PR, issue, or email to start the discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@EpsilonPrime can you explain what you mean and if it's still an issue? Does any change to algebra.proto need to be updated in the Substrait project too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now the this copy differs in about a half dozen ways from the original project. A protobuf saved using this version will be loaded incorrectly since DdlRel has field number 20. What should happen is that the differences introduced here get applied back to the main project. I've started the process of the CSV text format there. The Substrait project introduced ConsistentPartitionWindowRel a while back (as field number 17) which may actually do what you want here.
As long as you only talk to other consumers using this version of Substrait your code will work. But you're missing out on the other tools. For instance, the Substrait Validator is great for checking that you've constructed a conforming plan. I run all of the plans generated by my end to end tests through it and catches issues all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, I'm working on a PR that also touches algebra.proto - https://github.com/apache/incubator-gluten/pull/5632/files#diff-632cd96e81af6938b453cb8ec69d66123284f17c6e47f3f16b8f08e8046afc39. Can the reconciliation happen in one shot? I can try to port these changes over with your guidance!
What changes were proposed in this pull request?
There is a new operator named WindowGroupLimitExec introduced in spark 3.5 for optimizing window with rank like function with filter on it. apache/spark#38799. This PR maps this operator with row number function to TopNRowNumberNode in velox. Currently velox doesn't support TopN for rank and dense_rank. There is an issue opened in velox for it facebookincubator/velox#9404. Once that support gets added in velox this new operator in Gluten can be extended to support those.
(Partially Fixes: #4836)
How was this patch tested?
Added new UT