-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-6627] Some clean-up in shuffle code. #5286
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
Conversation
Before diving into review apache#4450 I did a look through the existing shuffle code. Unfortunately, there are some very confusing things in this code. This patch makes a few small changes to simplify things. It is not easily to concisely describe the changes because of how convoluted the issues were: 1. There was a trait named ShuffleBlockManager that only deals with one logical function which is retrieving shuffle block data given shuffle block coordinates. This trait has two implementors FileShuffleBlockManager and IndexShuffleBlockManager. Confusingly the vast majority of those implementations have nothing to do with this particular functionality. So I've renamed the trait to ShuffleBlockResolver and documented it. 2. The aformentioned trait had two almost identical methods, for no good reason. I removed one method (getBytes) and modified callers to use the other one. I think the behavior is preserved in all cases. 3. The sort shuffle code uses an identifier "0" in the reduce slot of a BlockID as a placeholder. I made it into a constant since it needs to be consistent across multiple places. I think for (3) there is actually a better solution that would avoid the need to do this type of workaround/hack in the first place, but it's more complex so I'm punting it for now.
|
Test build #29456 has started for PR 5286 at commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This behavior is kind of lame (just wrapping this in a Some), but it preserves what was there before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you change Some -> Option, just in case nioByteBuffer returns null?
|
Test build #29456 has finished for PR 5286 at commit
|
|
Test FAILed. |
|
Why is this a HOTFIX? |
|
We have to put that whenever we don't create a JIRA or else the scripts we use get messed up. I can just make a JIRA for the overall clean-up. |
|
At a high level LGTM |
|
Test build #29458 has started for PR 5286 at commit |
|
Test build #29458 has finished for PR 5286 at commit
|
|
Test FAILed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please continue
|
LGTM too |
|
Test build #29491 has started for PR 5286 at commit |
|
Test build #29491 has finished for PR 5286 at commit
|
|
Test FAILed. |
|
Jenkins, retest this pleas.e |
|
Jenkins, retest this please. |
|
Test build #29576 has started for PR 5286 at commit |
|
Test build #29576 has finished for PR 5286 at commit
|
|
Test FAILed. |
|
Jenkins, retest this please. |
|
/cc @brennonyork - this is giving me strange dependency messages even though the patch doesn't touch any pom files. |
|
Test build #29585 has started for PR 5286 at commit |
|
Test build #29585 has finished for PR 5286 at commit
|
|
Test PASSed. |
Before diving into review #4450 I did a look through the existing shuffle
code to learn how it works. Unfortunately, there are some very
confusing things in this code. This patch makes a few small changes
to simplify things. It is not easily to concisely describe the changes
because of how convoluted the issues were, but they are fairly small
logically:
ShuffleBlockManagerthat only deals withone logical function which is retrieving shuffle block data given shuffle
block coordinates. This trait has two implementors FileShuffleBlockManager
and IndexShuffleBlockManager. Confusingly the vast majority of those
implementations have nothing to do with this particular functionality.
So I've renamed the trait to ShuffleBlockResolver and documented it.
reason. I removed one method (getBytes) and modified callers to use the
other one. I think the behavior is preserved in all cases.
BlockID as a placeholder. I made it into a constant since it needs to
be consistent across multiple places.
I think for (3) there is actually a better solution that would avoid the
need to do this type of workaround/hack in the first place, but it's more
complex so I'm punting it for now.