feat: Rename OnDemandTransformations to Transformations

[franciscojavierarceo]

What this PR does / why we need it:

This PR renames:

• Re-introoduces the user_defined_function proto object and deprecates it
• renames
  • OnDemandPandasTransformation -> PandasTransformation
  • OnDemandSubstraitTransformation -> SubstraitTransformation
• Reverts/blends some of the changes from feat: Add Substrait-based ODFV transformation #3969 and feat: Decouple transformation types from ODFVs #3949
• Incorporates feat: Updating protos to separate transformation #4018

Which issue(s) this PR fixes:

This PR is a follow up to #4018

Fixes #

[tokoko]

This to_dict method really annoys me, always complicates proto changes 😄 Do we actually need it anywhere? Let me look through the project to see if it's being used. Why can't we just convert the whole proto message to json and be done with it?

[franciscojavierarceo]

For services that are python backed, they will likely use it. We do at Affirm.

[tokoko]

I know this isn't ready, but let me suggest some names. What if we call this PythonTransformation instead of UserDefinedFunctionV2. We could reuse that message type both for pandas_transformation and upcoming python_transformation fields and V2 in the naming (I think) will no longer be necessary. wdyt?

[franciscojavierarceo]

I tend to like stating V2 so that people understand it's a replacement for the deprecated proto. Are you thinking of making PythonTransformation an enum as well with Pandas and Python as elements? Feel free to suggest what you're thinking to make it a little more concret if you want.

My guess is something like

message FeatureTransformationV2 {
    oneof PythonTransformation {
        NativePython native_python = 1;
        Pandas pandas = 2;
    }
    SubstraitTransformationV2 substrait_transformation = 3;
}

Or something else?

[tokoko]

No, that would leave the possibility of having both python and substrait fields set, so probably not the best approach. I was thinking more like this (I'll omit V2s here just for brevity).

message FeatureTransformation {
    oneof transformation {
        PythonTransformation pandas_transformation  = 1;
        SubstraitTransformation substrait_transformation = 2;
        PythonTransformation python_transformation  = 3;
    }
}

note that pandas_transformation and python_transformation fields share the message type but that's just incidental because it just so happens that they need same type of information. If in the future we see that that's no longer the case, we could introduce PandasTransformation message as well and the first field of transformation will become PandasTransformation pandas_transformation = 1;

[franciscojavierarceo]

I like the UDF structure as it's a common industry pattern/convention especially for Spark.

@HaoXuAI any thoughts?

[tokoko]

I'm not specifically against UDFs, but the way I like to think about it all these options are sort of udfs anyway, so calling the message just UDF without any quilifier seems redundant, if it was called PythonUserDefinedFunction then it would be okay. I guess what I'm saying is I'm equally okay with the trio of (PythonTransformation, SubstraitTransformation, PandasTransformation) and with that of (PythonUDF, SubstraitUDF and PandasUDF).

[franciscojavierarceo]

@jeremyary @etirelli any opinions here? I am in favor of user_defined_function and the code for this PR is ready otherwise.

[franciscojavierarceo]

Lazy consensus will win here. I'm going to merge as is since everything's covered now.

[HaoXuAI]

LGTM

[HaoXuAI]

also can update the document now :)