Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CELEBORN-1858] Support DfsPartitionReader read partition by chunkOffsets when enable optimize skew partition read #3115

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

Z1Wu
Copy link
Contributor

@Z1Wu Z1Wu commented Feb 24, 2025

What changes were proposed in this pull request?

Support DfsPartitionReader read partition by chunkOffsets when enable optimize skew partition read

Why are the changes needed?

Follow-up of #2373

Does this PR introduce any user-facing change?

no

How was this patch tested?

test in test-cluster

@Z1Wu Z1Wu changed the title [CELEBORN-1319] Support DfsPartitionReader read partition by chunkOffsets when enable optimize skew partition read [CELEBORN-1858] Support DfsPartitionReader read partition by chunkOffsets when enable optimize skew partition read Feb 24, 2025
@@ -122,7 +126,7 @@ public DfsPartitionReader(
e);
}

if (endMapIndex != Integer.MAX_VALUE) {
if (endMapIndex != Integer.MAX_VALUE && endMapIndex != -1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the feature of optimizing skew partition read has been enabled, there will be no more sort. So here should not read the sorted DFS file.
The condition should be the condition startMapIndex > endMapIndex to be true and read chunk range from DFS shuffle file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my understanding, currently celeborn supports both sort-based skew-handling and the sort-free skew-handling introduced in #2373. If we change the condition to startMapIndex > endMapIndex, then it will no longer support sort-based skew-handling at all.
There are some other sort-based skew-handling code in current codebase, such as PartitionFilesSorter. If we want to completely remove the code related to sort-based skew-handling, would it be more appropriate to do it in a new PR after #3118 is merged into the main branch?
Please correct me if there's anything I haven't understood correctly.

@@ -197,7 +211,7 @@ public ByteBuf next() throws IOException, InterruptedException {
fetchThread.submit(
() -> {
try {
Copy link
Contributor

@wangshengjie123 wangshengjie123 Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this catch case, we could avoid to fallback to read SortedPath when optimizing skew partition read is enabled , code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, PTAL @wangshengjie123

Copy link

codecov bot commented Feb 25, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 32.69%. Comparing base (2097fcd) to head (125abd1).
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3115      +/-   ##
==========================================
+ Coverage   32.69%   32.69%   +0.01%     
==========================================
  Files         337      338       +1     
  Lines       20155    20277     +122     
  Branches     1804     1812       +8     
==========================================
+ Hits         6588     6628      +40     
- Misses      13201    13281      +80     
- Partials      366      368       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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.

3 participants