morningman opened a new pull request, #68965:
URL: https://github.com/apache/doris/pull/68965
### What problem does this PR solve?
Issue Number: None
Related PR: #67479, #67687
Problem Summary:
**In short.** On master, a scan of an Iceberg snapshot or tag taken before a
column rename or drop is not reported to the table's metrics reporter, so a
REST catalog with metrics reporting receives no ScanReport for it. This PR
makes such scans inherit the table's scan context, as branch-4.x does since
#67479. Query results do not change.
**Background.** Iceberg reports each scan's metrics (planning time,
manifests and files scanned) through the `MetricsReporter` in the scan's
context. `BaseTable.newScan()` puts the table's reporter into that context, and
catalogs such as REST forward the reports to their server. To read a historical
schema correctly, master builds the scan with `SchemaAwareDataTableScan`
(#67687, the master port of #67479), which binds the partition specs to the
snapshot's schema; branch-4.x does the same through
`DorisDataTableScan.wrap(table.newScan())`, which keeps the context of the
table's scan.
**The problem, and what it cost.**
| Scan | master | with this PR |
|---|---|---|
| Current schema | reported to the table's reporter | unchanged |
| Historical schema (a snapshot or tag from before a rename or drop) | built
from `TableScanContext.empty()`, whose reporter is `LoggingMetricsReporter`:
the catalog's reporter gets nothing, and the FE log gets a "Received metrics
report" INFO line | reported to the table's reporter |
**How this PR fixes it.** `SchemaAwareDataTableScan.newScan()` takes the
context of `table.newScan()`, which carries the table's reporter, and binds the
partition specs as before. A catalog-specific table whose own scan is not a
`DataTableScan` keeps the plain context it had.
**Results.** The new unit test puts a recording reporter on an in-memory
table: a current-schema scan and a historical-schema scan each send one
ScanReport, the second with the snapshot's id and schema id. Without the fix
the historical scan sends none. All fe-connector-iceberg tests pass (1525).
Original author of the branch-4.x behavior: @Gabriel39 (#67479)
### Release note
Scans of a historical Iceberg schema (an old snapshot or tag read after a
column rename or drop) are reported to the catalog's metrics reporter, like
scans of the current schema.
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [x] Unit Test
-
`IcebergScanPlanProviderTest#historicalSchemaScanReportsToTheTableMetricsReporter`
fails without the fix and passes with it; all fe-connector-iceberg tests
(1525) pass.
- [ ] 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.
- [x] Yes. <!-- Explain the behavior change -->
- The table's metrics reporter receives scan reports for historical
schema scans.
- Does this need documentation?
- [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/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 -->
--
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]
