zhouyuan opened a new pull request, #12872:
URL: https://github.com/apache/gluten/pull/12872
<!--
Thank you for submitting a pull request! Here are some tips:
1. For first-time contributors, please read our contributing guide:
https://github.com/apache/gluten/blob/main/CONTRIBUTING.md
2. If necessary, create a GitHub issue for discussion beforehand to avoid
duplicate work.
3. If the PR is specific to a single backend, include [VL] or [CH] in the PR
title to indicate the
Velox or ClickHouse backend, respectively.
4. If the PR is not ready for review, please mark it as a draft.
-->
## What changes are proposed in this pull request?
Driver-side broadcast hash table build already caches the serialized hash
table, but it keys the cache by the BroadcastExchangeExec instance, so the
entry can only be reused by exchange reuse inside one query. Workloads that run
the same queries over and over, e.g. the concurrent streams of a TPC-DS
throughput run, collect, build, serialize and broadcast the very same hash
table again for every query.
Add a driver-side cache that keys the built relation by the canonicalized
build side plan plus everything the content of the hash table depends on: the
normalized build keys, the build schema, the substrait join type, the build
side, the filter build column ordinals, the null aware / existence join flags,
the bloom filter pushdown size and whether duplicates were dropped. Expression
ids are normalized against the build side output, so two instances of the same
query map to the same key.
The lookup happens before the build side is collected, so a hit skips the
collect job, the hash table build and the serialization, and replays the row
count and data size of the job that built the relation into the exchange
metrics. When the very same relation object is broadcast again, the broadcast
created the first time is handed out as well, which also skips re-serializing
and re-uploading the blocks.
Build sides with non-deterministic expressions or subqueries, including the
runtime filters of dynamic partition pruning, are never shared. Reuse assumes
the data behind a build side does not change while the application is running,
and cached relations hold driver memory until they are evicted, so the cache is
off by default and bounded by size:
spark.gluten.sql.columnar.backend.velox.driverSideBroadcastHashTableCache.enabled
spark.gluten.sql.columnar.backend.velox.driverSideBroadcastHashTableCache.maxSize
<!--
Provide a clear and concise description of the changes introduced in this PR.
Ensure the PR description aligns with the code changes, especially after
updates.
If applicable, include "Fixes #<GitHub_Issue_ID>" to automatically close the
corresponding issue
when the PR is merged.
-->
## How was this patch tested?
new tests
<!--
Describe how the changes were tested, if applicable.
Include new tests to validate the functionality, if necessary.
For UI-related changes, attach screenshots to demonstrate the updates.
-->
## Was this patch authored or co-authored using generative AI tooling?
Claude Opus
IBM Bob
<!--
If generative AI tooling has been used in the process of authoring this
patch, please include the
phrase: 'Generated-by: ' followed by the name of the tool and its version.
If no, write 'No'.
Please refer to the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) for details.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
