To achieve one of the original purpose of ras: to make Gluten's rule simpler, and to make the rule list cleaner, some kind of migrations on our current rule code will be suggested.
The following is what I could assume:
RAS=on vs RAS=off
I'd raise a new approach around current entrance of RAS. Will be inclined to having two individual source code files (or folders) for RAS=on and RAS=off, to store the rule list of the each way. By doing this, it would be easier for developers to know what and how RAS actually does.
Worth noting that the migration would not remove rules from RAS=off as of now. We only doing code refactors to make RAS=on cover more columnar optimizations in RAS=off.
The gap of CH backend
CH backend doesn't currently support RAS=on. We should eliminate the following gaps as far as I know to make them compatible:
In CH backend there is some other plan nodes that are coupled with others, for example AFAIK the broadcast exchange doesn't work with C2R / R2C.
Ideally we'll migrate most of columnar rules that are not 100% heuristic. The following is a initial list and since I may not be the writer of these rules, so please correct me if I get anything wrong.
FallbackOnANSIMode
Will keep this in heuristics since it's a global switch.
FallbackMultiCodegens
choice 1: In RAS, tune cost model to slightly increase Velox's BHJ to larger than Vanilla Spark's BHJ. Then optimizer will fallback consecutive Gluten BHJs when it sees some.
choice 2: Keep as heuristic
PlanOneRowRelation
Will keep this in heuristics since it's a global switch.
FallbackEmptySchemaRelation
Will keep this in heuristics since it's a global switch.
MergeTwoPhasesHashBaseAggregate (CH only)
choice 1: Could add a RAS rule to merge aggregates.
choice 2: Keep as heuristic
Spark rewrite rules: RewriteIn, RewriteMultiChildrenCount, RewriteCollect, RewriteTypedImperativeAggregate, PullOutPreProject, PullOutPostProject:
Move them to RAS. RAS would naturally do such "tentative" transformations better than RBO. RAS could enumerate the possible plans then try to find the one that is executable and have lowest cost. For example, if the transformation yields too many of C2Rs/R2Cs, or just an inexecutable plan, optimizer will not choose it.
AddTransformHintRule
In RAS, merge this main validation rule together with transformation rule. Which means, RAS should validate the plan before it does each tentative transformation.
FallbackBloomFilterAggIfNeeded
choice 1: In RAS, add an independent physical property to indicate if the bloom filter buffer data is vanilla or Gluten/Velox. Then
optimizer would only choose plans that have consistent buffer data format.
choice 2: Keep as heuristic
ImplementFilter, ImplementAggregate, ImplementExchange, ImplementJoin, ImplementOthers
Can be moved to RAS, to do transformation.
RemoveNativeWriteFilesSortAndProject
The "remove sort and project" part can be perfectly done by RAS by property requirements. The other Empty2Null looks like some kind of validation that can be moved into RAS's transformation rule. Confirmation required.
RewriteTransformer
RAS could directly use the plugged rules, ideally.
EnsureLocalSortRequirements
It's RAS's natural job. Though we just need to add ordering property to property model.
CollapseProjectExecTransformer
RAS can use that rule.
genExtendedColumnarTransformRules (Velox only)
Currently only flushable agg rule. Can move to RAS's agg transformation rule.
GlutenConfig.getConf.extendedColumnarTransformRules
Keep it at the end of heuristic rule list to allow user defined rewrites. Will not add to RAS.
ExpandFallbackPolicy (whole stage fallback)
This can be done by RAS by setting more reasonable costs to C2R / R2C. Then optimizer would consider the cost of a plan with a lot of C2Rs / R2Cs higher then will not choose it.
InsertTransitions, TransformPostOverrides, InsertColumnarToColumnarTransitions, RemoveGlutenTableCacheColumnarToRow
RAS doesn't need these rules. C2Rs / R2Cs can be added via property enforcement.
RemoveTopmostColumnarToRow
Since this one is for compatible with Spark, will keep it in heuristics.
genExtendedColumnarPostRules
Probably keep in heuristics.
ColumnarCollapseTransformStages
Probably keep in heuristics.
extendedColumnarRules
Keep in heuristics.
GlutenFallbackReporter
Keep in heuristics.
RemoveTransformHintRule
Keep in heuristics.
Removal of RAS=off
This can be one of the final goal if all goes well as expected. But we will not take this action in short term.
Note
This topic would not only be related to code quality and maintenance. After we have a cleaner rule list and plan node definitions that are fully compatible to RAS, then we can decide whether to move on from RAS's current responsibility (fallback processing) to more advanced optimizations that could be powered by RAS.
Description
To achieve one of the original purpose of ras: to make Gluten's rule simpler, and to make the rule list cleaner, some kind of migrations on our current rule code will be suggested.
The following is what I could assume:
RAS=on vs RAS=off
I'd raise a new approach around current entrance of RAS. Will be inclined to having two individual source code files (or folders) for RAS=on and RAS=off, to store the rule list of the each way. By doing this, it would be easier for developers to know what and how RAS actually does.
Worth noting that the migration would not remove rules from
RAS=off
as of now. We only doing code refactors to makeRAS=on
cover more columnar optimizations inRAS=off
.The gap of CH backend
CH backend doesn't currently support RAS=on. We should eliminate the following gaps as far as I know to make them compatible:
There is a PR https://github.com/apache/incubator-gluten/pull/5101 to verify CH backend and TPC-H, we can make it pass asap.
Rules to migrate
Ideally we'll migrate most of columnar rules that are not 100% heuristic. The following is a initial list and since I may not be the writer of these rules, so please correct me if I get anything wrong.
FallbackOnANSIMode
Will keep this in heuristics since it's a global switch.FallbackMultiCodegens
PlanOneRowRelation
Will keep this in heuristics since it's a global switch.FallbackEmptySchemaRelation
Will keep this in heuristics since it's a global switch.MergeTwoPhasesHashBaseAggregate
(CH only)RewriteIn
,RewriteMultiChildrenCount
,RewriteCollect
,RewriteTypedImperativeAggregate
,PullOutPreProject
,PullOutPostProject
: Move them to RAS. RAS would naturally do such "tentative" transformations better than RBO. RAS could enumerate the possible plans then try to find the one that is executable and have lowest cost. For example, if the transformation yields too many of C2Rs/R2Cs, or just an inexecutable plan, optimizer will not choose it.AddTransformHintRule
In RAS, merge this main validation rule together with transformation rule. Which means, RAS should validate the plan before it does each tentative transformation.FallbackBloomFilterAggIfNeeded
ImplementFilter
,ImplementAggregate
,ImplementExchange
,ImplementJoin
,ImplementOthers
Can be moved to RAS, to do transformation.RemoveNativeWriteFilesSortAndProject
The "remove sort and project" part can be perfectly done by RAS by property requirements. The otherEmpty2Null
looks like some kind of validation that can be moved into RAS's transformation rule. Confirmation required.RewriteTransformer
RAS could directly use the plugged rules, ideally.EnsureLocalSortRequirements
It's RAS's natural job. Though we just need to add ordering property to property model.CollapseProjectExecTransformer
RAS can use that rule.genExtendedColumnarTransformRules
(Velox only) Currently only flushable agg rule. Can move to RAS's agg transformation rule.GlutenConfig.getConf.extendedColumnarTransformRules
Keep it at the end of heuristic rule list to allow user defined rewrites. Will not add to RAS.ExpandFallbackPolicy
(whole stage fallback) This can be done by RAS by setting more reasonable costs to C2R / R2C. Then optimizer would consider the cost of a plan with a lot of C2Rs / R2Cs higher then will not choose it.InsertTransitions
,TransformPostOverrides
,InsertColumnarToColumnarTransitions
,RemoveGlutenTableCacheColumnarToRow
RAS doesn't need these rules. C2Rs / R2Cs can be added via property enforcement.RemoveTopmostColumnarToRow
Since this one is for compatible with Spark, will keep it in heuristics.genExtendedColumnarPostRules
Probably keep in heuristics.ColumnarCollapseTransformStages
Probably keep in heuristics.extendedColumnarRules
Keep in heuristics.GlutenFallbackReporter
Keep in heuristics.RemoveTransformHintRule
Keep in heuristics.Removal of RAS=off
This can be one of the final goal if all goes well as expected. But we will not take this action in short term.
Note
This topic would not only be related to code quality and maintenance. After we have a cleaner rule list and plan node definitions that are fully compatible to RAS, then we can decide whether to move on from RAS's current responsibility (fallback processing) to more advanced optimizations that could be powered by RAS.