Tracking: User-Defined Function(UDF) Support

[wangrunji0408]

This issue tracks the progress of UDF support in RisingWave kernel.

We plan to support UDF in two ways:

1. External process which implements Apache Arrow Flight protocol (external Python, Java process)
2. Embedded execution on WASM or Python interpreter. (inline Python, JavaScript)

Any ideas and suggestions are welcome!

Related RFC: risingwavelabs/rfcs#12

Progress

Frontend:

• feat(frontend): support basic CREATE / DROP FUNCTION #7265
• fix(frontend): support drop function without arguments #9561
• udf: support SHOW FUNCTIONS #9276
• support implicit cast for UDF arguments #9998

Aggregate function:

• Tracking: User-defined Aggregate Function (UDAF) #11045

SQL UDF:

• Support SQL UDF #10151

Python UDF:

• Test and improve the compatibility between array mod and Apache Arrow format #6394
• feat(udf): python external function #7178
• feat(udf): minimal Python UDF SDK #7943
• feat(udf): support user-defined table function (UDTF) #8255
• feat(udf): support function that returns multiple columns #8644
• udf: support jsonb type #8801
• udf: support async python functions #8820

Java UDF:

• Java UDF #9981
• feat(udf): Java UDF SDK #10095
• Observability for java udf. #10321
• Provide java udf server instead of libs. #10322
• Create mvn project template for java udf. #10323
• More type inference approaches for java udf. #10324

WASM UDF:

• feat: WASM UDF MVP #10910 -> feat(udf): add initial support for WASM-based Rust UDF #14271

Problems

• feat: defensive measures in UDF servers #9002
• UDF panics if the function signature was modified discreetly.  #10828
• bug: Decimal processing is incorrect when using external. #11823
• Java UDF OOM easily #11508
• avoid calling UDF when the row being updated to is the same as existing row #12201
• Support schema (namespace) of functions #12422

[jon-chuang]

What is the interface for WASM? :) We can probably leverage arrow SDK too?

[wangrunji0408]

What is the interface for WASM? :) We can probably leverage arrow SDK too?

Yeah, the data exchange format will be arrow too. But the specific user interface has not been decided yet. For example, we may allow user to upload a compiled wasm object file, or we can help user compile their Python/JS code to wasm. The latter sounds more convenience.

[jon-chuang]

#7410 Seems like a good case.

My concern with WASM kernel is

1. whether we will embed the VM into the compute node
2. how we will handle errors, including the VM errors like out of bounds

Not sure how the user-defined errors can be propagated, however. I believe we should implement a wrapper type for such errors? So the response from external UDFs and response for WASM UDFs will be wrapped in this error type.

It seems that if we do not do 1., it is as good as an external function. Because if we do 1., then we get errors directly from the WASM VM, we can control the fault-tolerance/scaling story more meaningfully within the risingwave compute node than with external UDF and the user does not need to host the external UDF elsewhere.

[wangrunji0408]

Not sure how the user-defined errors can be propagated, however. I believe we should implement a wrapper type for such errors? So the response from external UDFs and response for WASM UDFs will be wrapped in this error type.

Sure. No matter whether we embed the VM or put it as an external function, there will be a lot kinds of errors to deal with. And I don't think there is anything we can do other than report them directly to users.

For question 1., I think it should be embedded into the compute node, because we can take advantage of the VM to avoid communication latency between processes and even nodes.

[xiangjinwu]

Do we intend to support implicit cast of arguments or require explicit cast? For example, given a builtin sind(double precision) -> double precision, we can write sind(30). But if that was a udf we have to write sind_udf(30::double precision) right now.

[wangrunji0408]

Do we intend to support implicit cast of arguments or require explicit cast?

Yes, we should support implicit cast for UDF as postgres does. This is not yet implemented and I'll create an issue to track it.