[GLUTEN-7548][VL] Optimize BHJ in velox backend

[JkSelf]

What changes were proposed in this pull request?

This PR implements the optimization from the CK backend in the BHJ to the Velox backend, ensuring that the hash table is built only once per executor. The detailed design document can be found here.

This PR enhances performance by 1.29x in 3TB TPC-DS Q23a when compared to using broadcast thresholds of 100MB and 10MB. Additionally, it addresses the out-of-memory (OOM) issue encountered in Q24a and Q24b with a 100MB threshold.
However, there is still potential for further optimization by implementing concurrent hash table building to mitigate the performance degradation observed in Q67. We will continue to pursue further optimizations in subsequent PRs.

Note: This PR eliminates the need for #5563

How was this patch tested?

Existing tests

[github-actions]

Thanks for opening a pull request!

Could you open an issue for this pull request on Github Issues?

https://github.com/apache/incubator-gluten/issues

Then could you also rename commit message and pull request title in the following format?

[GLUTEN-${ISSUES_ID}][COMPONENT]feat/fix: ${detailed message}

See also:

• Other pull requests

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

#7548

[github-actions]

Run Gluten Clickhouse CI on x86

[FelixYBW]

In long term, we need to implement the Spark way. Broadcast hashtable instead of raw table data.

[JkSelf]

In long term, we need to implement the Spark way. Broadcast hashtable instead of raw table data.

@FelixYBW Yes, we will support broadcasting the hash table approach after adding serialization/deserialization support to Velox's HashTable.

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[FelixYBW]

@zhztheplayer Is there memory management issue in this solution? Is the memory allocated in storage memory?

@JkSelf will this solution helpful to the final solution?

[JkSelf]

@JkSelf will this solution helpful to the final solution?

@FelixYBW Yes, the primary difference between Design 1 and Design 2 is the need for serialization and deserialization of Velox's hash table. Most of the remaining code can be shared between the two designs. We will evaluate the TPCH performance after addressing the result mismatch issue. If the performance does not meet expectations, we will proceed with implementing Design 2.

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[zhztheplayer]

Any test code to cover all of our changes to broadcast code? Given the tests are mostly based on Spark local mode where no broadcasting will actually happen.

cc @zjuwangg

[JkSelf]

@zhztheplayer Thank you for your review. It appears that the existing tests cover the broadcast changes introduced in this PR. I have added logging to the native broadcast hash table build code, and these logs will be printed during the CI process.

[github-actions]

Run Gluten Clickhouse CI on x86

[JkSelf]

@jinchengchenghh @liujiayi771 @zhztheplayer I'm merging this PR now to unblock our internal tests. I'll follow up with another PR to resolve your remaining comments. Thanks for the comments!

[zhztheplayer]

Some non-blocking comments.

[zhztheplayer]

defaultLeafVeloxMemoryPool should already be counted into off-heap memory pool, but I suggest to verify it if you'd like to.