feat(udf): support multiprocess pool for CPU-bound Python UDFs

[wangrunji0408]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

partially-resolve #13744

This PR adds a multiprocess pool to run CPU bound Python functions. Users can add the workers option in @udf or @udtf to enable parallel execution:

# a function that takes a long time to execute
@udf(input_types=["BIGINT"], result_type="BIGINT", workers=10)
def square(x: int) -> int:
    sum = 0
    for _ in range(x):
        sum += x
    return sum

Timing results:

dev=> select square(x::int8) from generate_series(10000, 11000) t(x);
time：245.066 ms (single)
time：294.942 ms (workers=10)

dev=> select square(x::int8) from generate_series(100000, 101000) t(x);
time：2377.646 ms (single)
time： 377.491 ms (workers=10)

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

Python UDFs now support multiple workers to run CPU-bound functions.

[xxchan]

I'm pondering whether io_threads can also be replaced by this...

[wangrunji0408]

Yes. But using threads is more efficient than processes, because multiprocess needs pickling (serializing code) and data transfer between processes. That's why it's even slower than single thread mode for not very computationally heavy functions. 🤪

[xxchan]

Can you explain a bit about the "Timing results"? Why the first one is slower with worker=10 🤪

BTW, might also trying compare throughputs, like #11508 (comment) does with nexmark generator

[wangrunji0408]

The overhead of data exchange between processes looks too large. I'm looking for some other ways, like spawning separate Arrow Flight servers on each process and enabling the SO_REUSEADDR option to allow them listening on the same port. apache/arrow-cookbook#236 (comment)

[wangrunji0408]

Closed this PR as the overhead of multiprocessing is too large. We would like to recommend another approach to scale Python UDF server: start a server on each CPU core and use a proxy such as Nginx to do load balance.

See: https://github.com/risingwavelabs/risingwave-docs/pull/1680