wombatu-kun opened a new pull request, #19021: URL: https://github.com/apache/hudi/pull/19021
### Describe the issue this Pull Request addresses The native HFile reader's `HFileDataBlock.seekTo` is the hottest inner loop on the metadata-table read path (record-level index, bloom filter and column-stats point lookups, which run on essentially every write). For each entry it scanned it allocated a `KeyValue` and its `Key` just to compare the entry key against the lookup key and to compute the stride to the next entry, producing two short-lived objects per scanned entry and avoidable GC pressure under point-lookup workloads. ### Summary and Changelog `HFileDataBlock.seekTo` now compares the entry key directly against the backing block buffer and computes the stride from the on-disk length fields, instead of materializing a `KeyValue`/`Key` for every scanned entry. A `KeyValue` is materialized only on an exact match. For the "in range" and end-of-block cases the cursor is pointed at the previous offset and the read is deferred, which `getKeyValue()` already performs lazily. The lookup key may be a `UTF8StringKey`, so its polymorphic content accessors are used for the comparison. The entry key's content offset and length come from two package-private static helpers on `Key`, which `Key`'s own content accessors now delegate to, so the serialized key layout keeps a single owner. The original `Option`-based cursor is unchanged. ### Impact No public API or on-disk format change. Lower-allocation, faster point lookups on the metadata-table read path. JMH microbenchmark over an uncompressed HFile fixture (5000 entries, 625 sorted point lookups; `forks(0)`; `gc.alloc.rate.norm`): | Workload | Metric | Before | After | Delta | | --- | --- | --- | --- | --- | | Point lookups | allocation (B/op) | 677,729 | 363,721 | -46% | | Point lookups | throughput (ops/ms) | 5.25 | 6.16 | +17% | | Full scan (not on the seekTo path) | allocation (B/op) | 643,705 | 643,681 | unchanged | ### Risk Level low. The behavior change is confined to `HFileDataBlock.seekTo`, and `Key` only gains the two layout helpers that its accessors delegate to. All seekTo return codes and the cursor's lazy-read semantics are preserved. It is exercised by the existing HFile reader suite (point, prefix, non-unique and fake-first-key seeks, sequential reads, empty file, and HBase read/write compatibility) and by a new multi-entry-block seek test that looks keys up both as a `UTF8StringKey` and as a serialized `Key` at a non-zero offset. The full hudi-io module test suite (160 tests) and checkstyle pass. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- 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]
