-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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] Add concurrency and deprecate parallelism for read_parquet APIs #42849
Conversation
ds = ray.data.read_parquet(data_path, filesystem=fs, concurrency=1) | ||
values = [s["one"] for s in ds.take()] | ||
assert sorted(values) == [1, 2, 3, 4, 5, 6] |
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.
read_parquet
could launch more than one concurrent read task and this assertion would still pass. Is there any easy way to test that the concurrency is enforced?
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.
Yes, planning to add some test similar to est_backpressure_policies.py:test_basic
. But good callout.
Signed-off-by: Cheng Su <scnju13@gmail.com>
Signed-off-by: Cheng Su <scnju13@gmail.com>
Signed-off-by: Cheng Su <scnju13@gmail.com>
Just realized that we also need to update unit tests that use |
Yes, those are okay and won't be broken. We can change in another PR. |
ray-project#42849) This PR is to add a new `concurrency` parameter for read APIs. The motivation is to allow users to control concurrency for read operator as well, other than map operators. TODO: Add `concurrency` parameter for all read APIs besides `read_parquet` once we agree on the change. Otherwise too many documentation change needs to make. Signed-off-by: Cheng Su <scnju13@gmail.com> Signed-off-by: Ratnopam Chakrabarti <ratnopamc@yahoo.com>
ray-project#42849) This PR is to add a new `concurrency` parameter for read APIs. The motivation is to allow users to control concurrency for read operator as well, other than map operators. TODO: Add `concurrency` parameter for all read APIs besides `read_parquet` once we agree on the change. Otherwise too many documentation change needs to make. Signed-off-by: Cheng Su <scnju13@gmail.com> Signed-off-by: tterrysun <terry@anyscale.com>
Why are these changes needed?
This PR is to add a new
concurrency
parameter for read APIs. The motivation is to allow users to control concurrency for read operator as well, other than map operators.TODO: Add
concurrency
parameter for all read APIs besidesread_parquet
once we agree on the change. Otherwise too many documentation change needs to make.Related issue number
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.