Commit e072b32
authored
feat: Add list with backward checkpoint scan (delta-io#2174)
## 🥞 Stacked PR
Use this
[link](https://github.com/delta-io/delta-kernel-rs/pull/2174/files) to
review incremental changes.
-
[stack/refactor-list-new](delta-io#2173)
[[Files
changed](https://github.com/delta-io/delta-kernel-rs/pull/2173/files)]
[MERGED]
-
[**stack/backward-listing-new**](delta-io#2174)
[[Files
changed](https://github.com/delta-io/delta-kernel-rs/pull/2174/files)]
---------
## What changes are proposed in this pull request?
This PR improves snapshot loading for time travel by replacing the full
forward listing fallback with a backward checkpoint scan. Previously,
when a _last_checkpoint hint was unavailable or pointed past the
requested version, kernel fell back to listing the entire log from v0.
The new strategy lists from the filesystem from the target version in
1000-version windows backwards, stopping as soon as a complete
checkpoint is found. It keeps track of the files as it lists backwards
and once a window with a checkpoint is found, it calls the new
build_log_segment_files() function (refactored list() logic - added in
previous PR in the stack) with the files.
This PR introduces the following changes:
- New list_with_backward_checkpoint_scan() method on LogSegmentFiles:
scans backward from an end_version in 1000-version windows, stopping at
the window with the first complete checkpoint
- New has_complete_checkpoint_in() helper: given a slice of
ParsedLogPath files, returns true if at least one complete checkpoint is
present. This is used by the backward scan loop to decide whether to
stop.
- Updated for_snapshot_impl case dispatch
- Updated build_log_segment_files(): when called with start_version:
None, derives the lower bound from the most recent complete checkpoint
found during the filesystem phase rather than requiring the caller to
supply it explicitly. This allows list_with_backward_checkpoint_scan()
to pass all scanned files in a single call and have the
(checkpoint-derived) lower bound computed automatically.
## How was this change tested?
For new functions introduced in log_segment_files:
- Tests for list_with_backward_checkpoint_scan() behaviour
- Window loop arithmetic (for listing from file system 1000 versions at
a time)
- has_complete_checkpoint_in() edge cases
Existing and new tests that cover the new path/case in
for_snapshot_impl():
- build_snapshot_without_checkpoints (second sub-test, ttv=Some(2))
- build_snapshot_with_checkpoint_greater_than_time_travel_version
- build_snapshot_time_travel_no_checkpoint_falls_back_to_v0 (added with
this PR)
- build_snapshot_time_travel_no_hint_checkpoint_at_end_version_included
(added with this PR)
- test_compaction_in_version_range
- test_compaction_out_of_version_range
Initially opted for an [implementation similar to delta kernel
java](https://sourcegraph.prod.databricks-corp.com/delta-io/delta/-/blob/kernel/kernel-api/src/main/java/io/delta/kernel/internal/checkpoints/Checkpointer.java?L182),
where we have a function that finds the last complete checkpoint
version, returns the version, and then we call the normal list()
function from there (my [initial
implementation](delta-io#2118)).
This improves performance in the case where there is a nearby checkpoint
to find, but in the case that there are no checkpoints, this makes the
process of building a snapshot 2x slower (because we essentially list
from the filesystem the same files twice). Because of this, I opted for
an implementation that keeps track of the files as we list backwards.
Benchmarking results:
<img width="2266" height="838" alt="image"
src="https://github.com/user-attachments/assets/4ed1b7d5-f640-4f42-8324-3f83b21fadbb"
/>
The first row of this picture shows the current state of this code, the
second row is the initial implementation that causes a regression, and
the third row is the current implementation.1 parent f099eaf commit e072b32
4 files changed
Lines changed: 1095 additions & 491 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
298 | 298 | | |
299 | 299 | | |
300 | 300 | | |
301 | | - | |
302 | | - | |
303 | | - | |
304 | | - | |
305 | | - | |
306 | | - | |
307 | | - | |
308 | | - | |
309 | | - | |
310 | | - | |
311 | | - | |
312 | | - | |
313 | | - | |
314 | | - | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
| 331 | + | |
| 332 | + | |
315 | 333 | | |
316 | 334 | | |
317 | 335 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
829 | 829 | | |
830 | 830 | | |
831 | 831 | | |
| 832 | + | |
| 833 | + | |
| 834 | + | |
| 835 | + | |
| 836 | + | |
| 837 | + | |
| 838 | + | |
| 839 | + | |
| 840 | + | |
| 841 | + | |
| 842 | + | |
| 843 | + | |
| 844 | + | |
| 845 | + | |
| 846 | + | |
| 847 | + | |
| 848 | + | |
| 849 | + | |
| 850 | + | |
| 851 | + | |
| 852 | + | |
| 853 | + | |
| 854 | + | |
| 855 | + | |
| 856 | + | |
| 857 | + | |
| 858 | + | |
| 859 | + | |
| 860 | + | |
| 861 | + | |
| 862 | + | |
| 863 | + | |
| 864 | + | |
| 865 | + | |
| 866 | + | |
| 867 | + | |
| 868 | + | |
| 869 | + | |
| 870 | + | |
| 871 | + | |
| 872 | + | |
| 873 | + | |
| 874 | + | |
| 875 | + | |
| 876 | + | |
| 877 | + | |
| 878 | + | |
| 879 | + | |
| 880 | + | |
| 881 | + | |
| 882 | + | |
| 883 | + | |
| 884 | + | |
| 885 | + | |
| 886 | + | |
| 887 | + | |
832 | 888 | | |
833 | 889 | | |
834 | 890 | | |
| |||
0 commit comments