Skip to content

branch-4.0:[feature](fe) Show compute group for MTMV refresh task (#63206)#63901

Open
seawinde wants to merge 1 commit into
apache:branch-4.0from
seawinde:pr_63206_to_branch-4.0
Open

branch-4.0:[feature](fe) Show compute group for MTMV refresh task (#63206)#63901
seawinde wants to merge 1 commit into
apache:branch-4.0from
seawinde:pr_63206_to_branch-4.0

Conversation

@seawinde
Copy link
Copy Markdown
Member

pr: #63206
commitId: 8ceff3b

Problem Summary:

Async materialized view refresh task status does not show which compute
group runs the refresh task. This is needed for cloud deployments where
users inspect a single MTMV refresh task and want to know the compute
group used by that task.

Root cause: In `MTMVJobManager.refreshMTMV()`, manual refresh only
creates `MTMVTaskContext` with trigger mode, partitions, and
complete-refresh flag. The refresh execution later creates a new
background `ConnectContext` in `MTMVTask.exec()`, so the foreground
connection's selected compute group is not explicitly carried into the
task context.

| File | Change Description |
|------|-------------------|
| `MTMVJobManager.java` | Resolves the current connection's compute
group in cloud mode and stores it in `MTMVTaskContext` for manual
refresh. |
| `MTMVTaskContext.java` | Adds a serialized `computeGroup` field. |
| `MTMVTask.java` | Applies the task compute group to the background
refresh `ConnectContext`, records it, and exposes `ComputeGroup` in
`tasks("type" = "mv")`. |
| `MTMVTaskTest.java` | Covers schema, TVF output, context recording,
task context application, and old task JSON compatibility. |
| `MTMVJobManagerTest.java` | Covers passing the current compute group
from manual refresh into `MTMVTaskContext`. |

```mermaid
graph TD
    A[User REFRESH MTMV] --> B[MTMVJobManager.refreshMTMV]
    B --> C[Resolve current ConnectContext compute group]
    C --> D[MTMVTaskContext.computeGroup]
    D --> E[MTMVTask.exec creates background ConnectContext]
    E --> F[Set cloud cluster on refresh ConnectContext]
    F --> G[Execute refresh SQL]
    F --> H[Expose ComputeGroup in tasks type mv]
```

Example:

After refreshing an async materialized view from compute group
`cg_analytics`:

```sql
REFRESH MATERIALIZED VIEW mv_sales;
```

Users can inspect the refresh task with `tasks("type" = "mv")` and read
the new `ComputeGroup` column:

```sql
SELECT
    TaskId,
    MvName,
    Status,
    RefreshMode,
    LastQueryId,
    ComputeGroup
FROM tasks("type" = "mv")
WHERE MvName = "mv_sales"
ORDER BY CreateTime DESC
LIMIT 1;
```

Example result:

```text
+--------+----------+---------+-------------+----------------------------------+--------------+
| TaskId | MvName   | Status  | RefreshMode | LastQueryId                      | ComputeGroup |
+--------+----------+---------+-------------+----------------------------------+--------------+
| 12003  | mv_sales | SUCCESS | COMPLETE    | 7f12c8d0f2a84b2b-9d8f2f4c1a5e6b7c | cg_analytics |
+--------+----------+---------+-------------+----------------------------------+--------------+
```

If the task has no recorded compute group, `ComputeGroup` is shown as
`\N`.

Expose ComputeGroup in tasks("type" = "mv") for asynchronous
materialized view refresh tasks.
@hello-stephen
Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@seawinde
Copy link
Copy Markdown
Member Author

run buildall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants