Uh oh!
There was an error while loading. Please reload this page.
[feat](load) alias compute_group to cloud_cluster - #53031
Conversation
Thearas
commented
Jul 10, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
kaijchen
commented
Jul 10, 2025
run buildall |
doris-robot
commented
Jul 10, 2025
TPC-H: Total hot run time: 33434 ms |
doris-robot
commented
Jul 10, 2025
TPC-DS: Total hot run time: 186354 ms |
doris-robot
commented
Jul 10, 2025
ClickBench: Total hot run time: 29.7 s |
doris-robot
commented
Jul 10, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
kaijchen
commented
Jul 10, 2025
run buildall |
doris-robot
commented
Jul 10, 2025
TPC-H: Total hot run time: 33323 ms |
doris-robot
commented
Jul 10, 2025
TPC-DS: Total hot run time: 185359 ms |
doris-robot
commented
Jul 10, 2025
ClickBench: Total hot run time: 29.57 s |
hello-stephen
commented
Jul 10, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
kaijchen
commented
Sep 19, 2025
run buildall |
doris-robot
commented
Sep 19, 2025
TPC-H: Total hot run time: 1501 ms |
doris-robot
commented
Sep 19, 2025
TPC-DS: Total hot run time: 2806 ms |
doris-robot
commented
Sep 19, 2025
ClickBench: Total hot run time: 0.11 s |
hello-stephen
commented
Sep 19, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 19, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 19, 2025
FE Regression Coverage ReportIncrement line coverage |
kaijchen
commented
Sep 20, 2025
run buildall |
hello-stephen
commented
Sep 20, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 20, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 20, 2025
FE Regression Coverage ReportIncrement line coverage |
kaijchen
commented
Sep 21, 2025
run buildall |
hello-stephen
commented
Sep 21, 2025
FE UT Coverage ReportIncrement line coverage |
hello-stephen
commented
Sep 21, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 21, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 21, 2025
FE Regression Coverage ReportIncrement line coverage |
kaijchen
commented
Sep 22, 2025
run buildall |
9e98bbc to
57bb077Comparekaijchen
commented
Sep 25, 2025
run buildall |
doris-robot
commented
Sep 25, 2025
ClickBench: Total hot run time: 30.68 s |
doris-robot
commented
Sep 25, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 25, 2025
FE UT Coverage ReportIncrement line coverage |
hello-stephen
commented
Sep 25, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 25, 2025
FE Regression Coverage ReportIncrement line coverage |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
### What problem does this PR solve? Problem Summary: To unify terminology, the session variable `compute_group` is now an alias for `cloud_cluster`. For stream loads, a new `compute_group` HTTP header is also added. It takes precedence over the existing `cloud_cluster` header to allow for a gradual migration. ### Release note None ### Check List (For Author) - Test <!-- At least one of them must be included. --> - [ ] Regression test - [ ] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason <!-- Add your reason? --> - Behavior changed: - [ ] No. - [ ] Yes. <!-- Explain the behavior change --> - Does this need documentation? - [ ] No. - [ ] Yes. <!-- Add document PR link here. eg: apache/doris-website#1214 --> ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label <!-- Add branch pick label that this PR should merge into -->
…ing (#65571) ### What problem does this PR solve? PR #53031 added support for the `compute_group` header on the BE side, but the FE Stream Load redirect path still only recognized the legacy `cloud_cluster` header. As a result, clients sending Stream Load requests through FE could not use `compute_group` to select the target compute group. There was also an ambiguity during planning: if a request was sent directly to a BE in compute group A while specifying compute group B in the header, propagating the header to the planning request could make the receiving BE and the execution compute group inconsistent. ### What is changed? This PR adds `compute_group` support to the FE Stream Load redirect path and defines the planning behavior based on the receiving BE. - Make FE recognize the `compute_group` header when selecting the Stream Load redirect target. - Give `compute_group` precedence over the legacy `cloud_cluster` header. - Keep `cloud_cluster` as a compatibility fallback. - Make ordinary Stream Load pass the receiving BE's `backend_id` to FE. - Resolve the planning compute group from the receiving BE's `backend_id`. - Override the planning request's `cloud_cluster` with the receiving BE's compute group. - Keep the existing fallback behavior when `backend_id` is unavailable. HTTP Stream already passes the receiving BE's `backend_id`, so no additional BE-side behavior change is required for HTTP Stream. ### Behavior - Request through FE with `compute_group=B`: - FE redirects the request to a BE in B. - The receiving BE passes its `backend_id` to FE. - The load is planned and executed in B. - Request sent directly to a BE in A with `compute_group=B`: - The receiving BE passes its own `backend_id` to FE. - The load is planned and executed in A. - The conflicting `compute_group` header does not change the planning compute group. ### Tests - Added FE unit tests for: - `compute_group` header precedence during redirect. - Fallback to the legacy `cloud_cluster` header. - Resolving the planning compute group from `backend_id`. - Added cloud regression coverage for: - FE Stream Load redirect using `compute_group`. - Direct-to-BE Stream Load with a conflicting `compute_group` header.
…ing (#65571) ### What problem does this PR solve? PR #53031 added support for the `compute_group` header on the BE side, but the FE Stream Load redirect path still only recognized the legacy `cloud_cluster` header. As a result, clients sending Stream Load requests through FE could not use `compute_group` to select the target compute group. There was also an ambiguity during planning: if a request was sent directly to a BE in compute group A while specifying compute group B in the header, propagating the header to the planning request could make the receiving BE and the execution compute group inconsistent. ### What is changed? This PR adds `compute_group` support to the FE Stream Load redirect path and defines the planning behavior based on the receiving BE. - Make FE recognize the `compute_group` header when selecting the Stream Load redirect target. - Give `compute_group` precedence over the legacy `cloud_cluster` header. - Keep `cloud_cluster` as a compatibility fallback. - Make ordinary Stream Load pass the receiving BE's `backend_id` to FE. - Resolve the planning compute group from the receiving BE's `backend_id`. - Override the planning request's `cloud_cluster` with the receiving BE's compute group. - Keep the existing fallback behavior when `backend_id` is unavailable. HTTP Stream already passes the receiving BE's `backend_id`, so no additional BE-side behavior change is required for HTTP Stream. ### Behavior - Request through FE with `compute_group=B`: - FE redirects the request to a BE in B. - The receiving BE passes its `backend_id` to FE. - The load is planned and executed in B. - Request sent directly to a BE in A with `compute_group=B`: - The receiving BE passes its own `backend_id` to FE. - The load is planned and executed in A. - The conflicting `compute_group` header does not change the planning compute group. ### Tests - Added FE unit tests for: - `compute_group` header precedence during redirect. - Fallback to the legacy `cloud_cluster` header. - Resolving the planning compute group from `backend_id`. - Added cloud regression coverage for: - FE Stream Load redirect using `compute_group`. - Direct-to-BE Stream Load with a conflicting `compute_group` header.
…ing (apache#65571) ### What problem does this PR solve? PR apache#53031 added support for the `compute_group` header on the BE side, but the FE Stream Load redirect path still only recognized the legacy `cloud_cluster` header. As a result, clients sending Stream Load requests through FE could not use `compute_group` to select the target compute group. There was also an ambiguity during planning: if a request was sent directly to a BE in compute group A while specifying compute group B in the header, propagating the header to the planning request could make the receiving BE and the execution compute group inconsistent. ### What is changed? This PR adds `compute_group` support to the FE Stream Load redirect path and defines the planning behavior based on the receiving BE. - Make FE recognize the `compute_group` header when selecting the Stream Load redirect target. - Give `compute_group` precedence over the legacy `cloud_cluster` header. - Keep `cloud_cluster` as a compatibility fallback. - Make ordinary Stream Load pass the receiving BE's `backend_id` to FE. - Resolve the planning compute group from the receiving BE's `backend_id`. - Override the planning request's `cloud_cluster` with the receiving BE's compute group. - Keep the existing fallback behavior when `backend_id` is unavailable. HTTP Stream already passes the receiving BE's `backend_id`, so no additional BE-side behavior change is required for HTTP Stream. ### Behavior - Request through FE with `compute_group=B`: - FE redirects the request to a BE in B. - The receiving BE passes its `backend_id` to FE. - The load is planned and executed in B. - Request sent directly to a BE in A with `compute_group=B`: - The receiving BE passes its own `backend_id` to FE. - The load is planned and executed in A. - The conflicting `compute_group` header does not change the planning compute group. ### Tests - Added FE unit tests for: - `compute_group` header precedence during redirect. - Fallback to the legacy `cloud_cluster` header. - Resolving the planning compute group from `backend_id`. - Added cloud regression coverage for: - FE Stream Load redirect using `compute_group`. - Direct-to-BE Stream Load with a conflicting `compute_group` header.
What problem does this PR solve?
Problem Summary:
To unify terminology, the session variable
compute_groupis now an alias forcloud_cluster.For stream loads, a new
compute_groupHTTP header is also added. It takes precedence over the existingcloud_clusterheader to allow for a gradual migration.Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)