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

[data] fix split read output blocks #41070

Merged
merged 2 commits into from
Nov 16, 2023

Conversation

Zandew
Copy link
Contributor

@Zandew Zandew commented Nov 10, 2023

Why are these changes needed?

I'm not sure why we were calling _set_num_output_blocks on the upstream input operator when we were splitting blocks for the downstream read map operator. The split happens in the read map operator, which shouldn't affect the input operator.

Also adds a test for estimating output blocks with additional split factor.

Related issue number

Checks

  • I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
    • I've added any new APIs to the API Reference. For example, if I added a
      method in Tune, I've added it in doc/source/tune/api/ under the
      corresponding .rst file.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

Comment on lines 38 to 39
if cur_additional_split_factor:
size_based_splits *= cur_additional_split_factor
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, i feel like we still need to keep this logic and cur_additional_split_factor as a parameter in this function. @stephanie-wang as original author to confirm?

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, this seems still useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sounds good, I'll add it back

@@ -921,6 +921,28 @@ def yield_five(block_iter: Iterable[Block], ctx) -> Iterable[Block]:
# 100 inputs -> 100 / 10 = 10 tasks -> 10 * 5 = 50 output blocks
assert op._estimated_output_blocks == 50

# Test read output splitting
Copy link
Contributor

Choose a reason for hiding this comment

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

let's make it a standalone test?

Comment on lines 38 to 39
if cur_additional_split_factor:
size_based_splits *= cur_additional_split_factor
Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, this seems still useful.

Signed-off-by: Andrew Xue <andewzxue@gmail.com>
Signed-off-by: Andrew Xue <andewzxue@gmail.com>
@raulchen raulchen merged commit 2a72e5a into ray-project:master Nov 16, 2023
15 of 19 checks passed
ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Nov 29, 2023
I'm not sure why we were calling `_set_num_output_blocks` on the upstream input operator when we were splitting blocks for the downstream read map operator. The split happens in the read map operator, which shouldn't affect the input operator.

Also adds a test for estimating output blocks with additional split factor.
---------

Signed-off-by: Andrew Xue <andewzxue@gmail.com>
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.

None yet

3 participants