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.

Sign up for GitHub

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

Jump to bottom

[Data] Fix OutputBlockBuffer to avoid repeatedly copying remainder block #48266

Merged
merged 4 commits into from
Nov 2, 2024
Merged

[Data] Fix OutputBlockBuffer to avoid repeatedly copying remainder block #48266

merged 4 commits into from
Nov 2, 2024

Conversation

alexeykudinkin
Copy link
Contributor

Why are these changes needed?

Currently, inside OutputBlockBuffer we're

  1. Repeatedly copying remainder of the original block, bringing total # of bytes copied to O(N^2) (where N is the size of the original block)
  2. Creating potentially very large blocks (like in [Data] Cannot load large JSONL file #48236) that could overflow underlying Arrow data types.

This change addresses both of these issues, by establishing following protocol where

  1. Finalized target blocks are copied, while
  2. Remainder block is NOT (therefore continuing referencing original block)

Addresses #48236

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 :(

@alexeykudinkin alexeykudinkin added the go add ONLY when ready to merge, run all tests label Oct 25, 2024
@alexeykudinkin alexeykudinkin linked an issue Oct 25, 2024 that may be closed by this pull request
[Data] Cannot load large JSONL file #48236
Closed
@pcmoritz
Copy link
Contributor

Great find! So my understanding is that .slice here

ray/python/ray/data/_internal/arrow_block.py

Line 284 in 22e266a

view = _copy_table(view)
concatenated all the chunks in the ChunkedArray and that led to the overflow? :)

@pcmoritz
Copy link
Contributor

There are some test failure but this seems like the right fix :)

@alexeykudinkin
Copy link
Contributor Author

concatenated all the chunks in the ChunkedArray and that led to the overflow? :)

Correct. And we'd avoid copying here as well as it's absolutely unnecessary.

bveeramani
bveeramani reviewed Oct 28, 2024
View reviewed changes
python/ray/data/_internal/output_buffer.py Outdated Show resolved Hide resolved
python/ray/data/_internal/output_buffer.py Outdated Show resolved Hide resolved
python/ray/data/tests/test_dynamic_block_split.py Outdated Show resolved Hide resolved
@alexeykudinkin alexeykudinkin force-pushed the ak/blk-buf-arw-chnk-arr-fix branch 2 times, most recently from 2037198 to b4b407a Compare October 29, 2024 23:33
@alexeykudinkin alexeykudinkin mentioned this pull request Nov 1, 2024
Merged
8 tasks
@alexeykudinkin
Copy link
Contributor Author

Blocked on #47040

aslonnie pushed a commit that referenced this pull request Nov 1, 2024
@bveeramani
[Data] Bump min version of PyArrow from 6.0 to 9.0 (#47040)
0a779ad 
Dropping Ray Data internal support for Arrow < 9.0.0 as of Ray 2.39.

This is necessary in avoiding over-compensating for issues resolved in old Arrow versions, like the ones surfacing in #48266.
@alexeykudinkin
Avoid copying remainder block
ea71247 
Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
@alexeykudinkin
Tidying up
7c2b829 
Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
@alexeykudinkin
lint
85ae249 
Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
@alexeykudinkin
Tidying up docs
aade112 
Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
@pcmoritz pcmoritz merged commit 9b92557 into master Nov 2, 2024
5 checks passed
@pcmoritz pcmoritz deleted the ak/blk-buf-arw-chnk-arr-fix branch November 2, 2024 01:39
@alexeykudinkin alexeykudinkin mentioned this pull request Nov 2, 2024
Closed
Jay-ju pushed a commit to Jay-ju/ray that referenced this pull request Nov 5, 2024
@bveeramani @Jay-ju
[Data] Bump min version of PyArrow from 6.0 to 9.0 (ray-project#47040)
edbd920 
Dropping Ray Data internal support for Arrow < 9.0.0 as of Ray 2.39.

This is necessary in avoiding over-compensating for issues resolved in old Arrow versions, like the ones surfacing in ray-project#48266.
Jay-ju pushed a commit to Jay-ju/ray that referenced this pull request Nov 5, 2024
@alexeykudinkin @Jay-ju
[Data] Fix OutputBlockBuffer to avoid repeatedly copying remainder …
5cb8d02 
…block (ray-project#48266)

<!-- Thank you for your contribution! Please review
https://github.com/ray-project/ray/blob/master/CONTRIBUTING.rst before
opening a pull request. -->

<!-- Please add a reviewer to the assignee section when you create a PR.
If you don't have the access to it, we will shortly find a reviewer and
assign them to your PR. -->

## Why are these changes needed?

Currently, inside `OutputBlockBuffer` we're

1. Repeatedly copying remainder of the original block, bringing total #
of bytes copied to O(N^2) (where N is the size of the original block)
2. Creating potentially very large blocks (like in
ray-project#48236) that could overflow
underlying Arrow data types.

This change addresses both of these issues, by establishing following
protocol where

1. Finalized target blocks *are* copied, while
2. Remainder block is NOT (therefore continuing referencing original
block)

Addresses ray-project#48236

<!-- Please give a short summary of the change and the problem this
solves. -->

## Related issue number

<!-- For example: "Closes ray-project#1234" -->

## 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 :(

---------

Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
JP-sDEV pushed a commit to JP-sDEV/ray that referenced this pull request Nov 14, 2024
@bveeramani @JP-sDEV
[Data] Bump min version of PyArrow from 6.0 to 9.0 (ray-project#47040)
fb30b01 
Dropping Ray Data internal support for Arrow < 9.0.0 as of Ray 2.39.

This is necessary in avoiding over-compensating for issues resolved in old Arrow versions, like the ones surfacing in ray-project#48266.
Signed-off-by: JP-sDEV <jon.pablo80@gmail.com>
JP-sDEV pushed a commit to JP-sDEV/ray that referenced this pull request Nov 14, 2024
@alexeykudinkin @JP-sDEV
[Data] Fix OutputBlockBuffer to avoid repeatedly copying remainder …
cd5a388 
…block (ray-project#48266)

<!-- Thank you for your contribution! Please review
https://github.com/ray-project/ray/blob/master/CONTRIBUTING.rst before
opening a pull request. -->

<!-- Please add a reviewer to the assignee section when you create a PR.
If you don't have the access to it, we will shortly find a reviewer and
assign them to your PR. -->

## Why are these changes needed?

Currently, inside `OutputBlockBuffer` we're

1. Repeatedly copying remainder of the original block, bringing total #
of bytes copied to O(N^2) (where N is the size of the original block)
2. Creating potentially very large blocks (like in
ray-project#48236) that could overflow
underlying Arrow data types.

This change addresses both of these issues, by establishing following
protocol where

1. Finalized target blocks *are* copied, while
2. Remainder block is NOT (therefore continuing referencing original
block)

Addresses ray-project#48236

<!-- Please give a short summary of the change and the problem this
solves. -->

## Related issue number

<!-- For example: "Closes ray-project#1234" -->

## 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 :(

---------

Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
mohitjain2504 pushed a commit to mohitjain2504/ray that referenced this pull request Nov 15, 2024
@bveeramani @mohitjain2504
[Data] Bump min version of PyArrow from 6.0 to 9.0 (ray-project#47040)
d2b23d6 
Dropping Ray Data internal support for Arrow < 9.0.0 as of Ray 2.39.

This is necessary in avoiding over-compensating for issues resolved in old Arrow versions, like the ones surfacing in ray-project#48266.

Signed-off-by: mohitjain2504 <mohit.jain@dream11.com>
mohitjain2504 pushed a commit to mohitjain2504/ray that referenced this pull request Nov 15, 2024
@alexeykudinkin @mohitjain2504
[Data] Fix OutputBlockBuffer to avoid repeatedly copying remainder …
82617ea 
…block (ray-project#48266)

<!-- Thank you for your contribution! Please review
https://github.com/ray-project/ray/blob/master/CONTRIBUTING.rst before
opening a pull request. -->

<!-- Please add a reviewer to the assignee section when you create a PR.
If you don't have the access to it, we will shortly find a reviewer and
assign them to your PR. -->

## Why are these changes needed?

Currently, inside `OutputBlockBuffer` we're

1. Repeatedly copying remainder of the original block, bringing total #
of bytes copied to O(N^2) (where N is the size of the original block)
2. Creating potentially very large blocks (like in
ray-project#48236) that could overflow
underlying Arrow data types.

This change addresses both of these issues, by establishing following
protocol where

1. Finalized target blocks *are* copied, while
2. Remainder block is NOT (therefore continuing referencing original
block)

Addresses ray-project#48236

<!-- Please give a short summary of the change and the problem this
solves. -->

## Related issue number

<!-- For example: "Closes ray-project#1234" -->

## 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 :(

---------

Signed-off-by: Alexey Kudinkin <ak@anyscale.com>
Signed-off-by: mohitjain2504 <mohit.jain@dream11.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bveeramani bveeramani bveeramani left review comments

@pcmoritz pcmoritz pcmoritz approved these changes

@scottjlee scottjlee Awaiting requested review from scottjlee scottjlee is a code owner

@raulchen raulchen Awaiting requested review from raulchen raulchen is a code owner

@stephanie-wang stephanie-wang Awaiting requested review from stephanie-wang stephanie-wang is a code owner

@omatthew98 omatthew98 Awaiting requested review from omatthew98 omatthew98 is a code owner

Assignees

@pcmoritz pcmoritz

Labels
go add ONLY when ready to merge, run all tests
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[Data] Cannot load large JSONL file
3 participants
@alexeykudinkin @pcmoritz @bveeramani