feat(udf): add initial support for WASM-based Rust UDF

[wangrunji0408]

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

What's changed and what's your intention?

This PR adds an initial support for Rust UDF, based on @xxchan's #10910.

Please see src/expr/udf/README.md for usage and current limitations.

The core implementation of UDF is maintained in an independent crate arrow-udf. It depends on arrow-rs only and is intended to be shared by the Rust community. However, its API design is mostly inherited from our built-in functions and will be kept as consistent as possible. Example:

#[function("gcd(int, int) -> int")]
fn gcd(mut a: i32, mut b: i32) -> i32 {
    while b != 0 {
        (a, b) = (b, a % b);
    }
    a
}

On RW side, we provide two ways to create functions from WASM module:

1. You can embed WASM binaries into SQL using base64 encoding. RW will upload the binary into object store with the path defined in the parameter wasm_storage_url.

CREATE FUNCTION gcd(int, int) RETURNS int LANGUAGE wasm
USING BASE64 '$encoded';

2. You can also directly specify a path in object store, if you want to reuse a previous uploaded module or upload it by yourself.

CREATE FUNCTION gcd(int, int) RETURNS int LANGUAGE wasm
USING LINK 's3://bucket/path/to/wasm';

You may have noticed that AS <identifier> is no longer required. Because this time we define a unique identifier for each combination of function name and data types. These identifiers are base64 encoded as function symbols, and can be decoded by UDF runtime when loading WASM modules.

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

Add experimental support for Rust UDF.

See src/expr/udf/README.md for a draft document.

[wangrunji0408]

I have no idea what the default path should be in a production environment. 🤔

[xxchan]

default to none?

[BugenZhao]

The path .risingwave/data should be specific to RiseDev. 🤔 Maybe you want to set it with risedev d?

[BugenZhao]

Are we essentially trying to reuse the same runtime for different actors/tasks for the same job? BTW, what's the benefits or overheads for reusing or not?

[wangrunji0408]

Yes. The runtime supports parallel calls from multiple threads. A WASM instance can only be called from a single thread (for now, multi-thread support is on the way), but we can use an instance pool to share and recycle instances across threads. The benefits of reuse are primarily saving memory, reducing the overhead of duplicate JITs and repeated downloads from object store.

[TennyZhuang]

I prefer to merge it without documenting it now.

[wangrunji0408]

I prefer to merge it without documenting it now.

So we will maintain the doc inside this repo but won't publish it into risingwave.dev?

[fuyufjh]

You can embed WASM binaries into SQL using base64 encoding. RW will upload the binary into object store with the path defined in the parameter wasm_storage_url.

Why not just storing them in meta store? In most cases the WASM won't be very big and meta store (will be migrated to RDBMS e.g. PostgresQL) should be good enough. I prefer to make it simple and avoid introduce new dependent systems.

A related discussion: #12982. Also recommend meta store for it in my opinion.

[wangrunji0408]

The wasm binary in e2e test is about 1.5MB after strip, 400KB after compression. It sounds okay to store them into meta.

[fuyufjh]

The wasm binary in e2e test is about 1.5MB after strip, 400KB after compression. It sounds okay to store them into meta.

Let me note it down as an issue as a reminder.

[xxchan]

Why didn't we use DataType's Display? 🤪

[wangrunji0408]

The type names defined in WASM module are slightly different than RW's type names, as the former follows Arrow specification while the latter follows postgres'.

[xxchan]

But I think arrow doesn't specified things like T[], and thus the "string representation of a datatype" is still kind of arbitrary IMO.

So does the signature matter in the arrow-udf-wasm crate, or it can be decided by the caller?

[wangrunji0408]

But I think arrow doesn't specified things like T[], and thus the "string representation of a datatype" is still kind of arbitrary IMO.

Sure. T[] is still pg style and should be changed to list<T> in my opinion.

So does the signature matter in the arrow-udf-wasm crate, or it can be decided by the caller?

The signature format is a part of arrow-udf API and may vary between versions. (e.g. from API version 2 to 3, the type name of bigint was changed from int8 to int64, in order to be consistent with Arrow and avoid ambiguity) The caller needs to use the correct name according to the API version declared by the WASM module.