Gluten Plan Optimization

[ted-jenks]

In our usage of Gluten we have noticed to key patterns where we feel like we miss out on performance.

The first of these are Spark jobs where a built-in function that is not supported is used, but the plan could be expressed in functions that can be offloaded. For instance to_timestamp is not supported, but to_unix_timestamp is and with a cast, these are equivalent.

I have also seen issues where a query plan is nearly convertible to Velox, but not quite, leading to nothing getting offloaded to native.

Project [cast(to_unix_timestamp(col1#86, yyyy-MM-dd, Some(UTC), false) as timestamp) AS col1#89]   
   +- RelationV2[col1#86] csv ...

Building on the to_timestamp example, we still probably would not see offloading because the CollapseProject rule will ensure that the cast and to_unix_timestamp expressions are in a single operator. If it were just the to_unix_timestamp in this operator, it would have been offloaded. While this will become less of an issue with time as more of the Spark expressions are supported, it will remain true for all custom expressions and UDFs.

These observations give me the idea to write Gluten-aware optimizer rules that adapt the plan to improve its offloadability. Crucially, we could. Optimise for separation of offloadable and not offloadable expressions on an operator by operator basis. Obviously this would have to be done in a way to not introduce a bunch of serialization overhead.

Is this something anyone has thought about before? Do you think potentially introducing additional serialization overheads could hurt overall perf?

[ted-jenks]

cc @ulysses-you @zhouyuan @PHILO-HE

[ulysses-you]

thank you @ted-jenks. Do you mean to seperate project into twos, one run on native and the other run on vanilla spark ? If so, the idea looks good to me, it is similar with what we did recently that pull out project from aggregate/sort/topk etc. We can add one more rule to pull out a project from a project.

[ulysses-you]

By the way, these days are Chinese holiday, we may reply late.

[ted-jenks]

No worries! Hope you are having happy holidays! I will take a look into doing this over the coming days.

[ted-jenks]

cc @liujiayi771 as I think this is similar to your work in #4663 and others.

[liujiayi771]

Your idea is good to me. We should try to minimize the number of expressions that fallback to evaluation in vanilla Spark. But how do you plan to break down the expressions within Project? Do we need to traverse each expression for validation individually, or is there a way to validate them in batch?

[ted-jenks]

Currently I do not know a way to avoid traversing each expression, which would look like mapping over the expressions in the Project, and the content of the children of those expressions.

[PHILO-HE]

While this will become less of an issue with time as more of the Spark expressions are supported, it will remain true for all custom expressions and UDFs.

I agree. @ted-jenks, do you plan to implement this feature?

[ted-jenks]

I wanted to but have been unable to find the time to commit to it. Cannot promise it too soon.