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][api] implement HudiDataSource #46273

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

xushiyan
Copy link

@xushiyan xushiyan commented Jun 26, 2024

Why are these changes needed?

Support read from Hudi table into Ray dataset.

Related issue number

Closes #46272

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

@xushiyan xushiyan force-pushed the add-hudi-datasource branch 5 times, most recently from 7bc3894 to 97f9de1 Compare June 28, 2024 18:11
@xushiyan xushiyan marked this pull request as ready for review June 28, 2024 18:20
@anyscalesam anyscalesam added data Ray Data-related issues @external-author-action-required Alternate tag for PRs where the author doesn't have labeling permission. triage Needs triage (eg: priority, bug/not-bug, and owning component) labels Jun 29, 2024
@xushiyan xushiyan force-pushed the add-hudi-datasource branch 3 times, most recently from e2f6704 to 557b887 Compare July 14, 2024 18:17
Copy link
Contributor

@omatthew98 omatthew98 left a comment

Choose a reason for hiding this comment

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

Took a first pass and left some mostly nit comments. Overall looks good, let us know / re-request a review when it is ready for a re-review!

python/ray/data/_internal/datasource/hudi_datasource.py Outdated Show resolved Hide resolved
python/ray/data/_internal/datasource/hudi_datasource.py Outdated Show resolved Hide resolved
return read_tasks

def estimate_inmemory_data_size(self) -> Optional[int]:
return None
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there any estimate that can be provided / returned here? Perhaps using the size_bytes from above? Maybe could cache that similar to what is done here.

Copy link
Author

Choose a reason for hiding this comment

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

agree to provide estimates here. However due to current impl, loading this info during init using HudiTable is not a lightweight operation, plus the size bytes are storage size without some translation to in-memory size. i've added a todo here to support this info through HudiTable API.

Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds reasonable!

0,
)
pytestmark = pytest.mark.skipif(
PYARROW_LE_8_0_0, reason="hudi only supported if pyarrow >= 8.0.0"
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens currently if a user tries to use pyarrow <8.0.0? Should we warn / error in the read_hudi_table or HudiDatasource if the user's pyarrow version is less than 8.0.0?

Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, we should raise an exception when using either read_hudi_table or HudiDatasource if the arrow version is not supported

Copy link
Author

@xushiyan xushiyan Jul 26, 2024

Choose a reason for hiding this comment

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

thanks for pointing out. i'll add a check and raise exception from within HudiTable API since this is internal to Hudi's implementation. This validation logic will be available in the upcoming hudi python 0.2.0. We can use another PR to integrate 0.2.0 with incremental read support, sounds good?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that sounds reasonable too. Just to make sure I understand the idea would be that in the creation of the HudiDatasource we would then get an exception from the from hudi import HudiTable if the version of pyarrow is unsupported?

Copy link
Author

Choose a reason for hiding this comment

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

@omatthew98 that's correct.

python/ray/data/_internal/datasource/hudi_datasource.py Outdated Show resolved Hide resolved
python/ray/data/_internal/datasource/hudi_datasource.py Outdated Show resolved Hide resolved
0,
)
pytestmark = pytest.mark.skipif(
PYARROW_LE_8_0_0, reason="hudi only supported if pyarrow >= 8.0.0"
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, we should raise an exception when using either read_hudi_table or HudiDatasource if the arrow version is not supported

Copy link
Contributor

@omatthew98 omatthew98 left a comment

Choose a reason for hiding this comment

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

Thanks for responding to the questions, had one more for my understanding. After that if you add some more assertions to the test_read_hudi_table it lgtm!

return read_tasks

def estimate_inmemory_data_size(self) -> Optional[int]:
return None
Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds reasonable!

0,
)
pytestmark = pytest.mark.skipif(
PYARROW_LE_8_0_0, reason="hudi only supported if pyarrow >= 8.0.0"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that sounds reasonable too. Just to make sure I understand the idea would be that in the creation of the HudiDatasource we would then get an exception from the from hudi import HudiTable if the version of pyarrow is unsupported?

@aslonnie aslonnie added go add ONLY when ready to merge, run all tests and removed go add ONLY when ready to merge, run all tests labels Jul 30, 2024
@aslonnie
Copy link
Collaborator

@omatthew98 omatthew98 added the go add ONLY when ready to merge, run all tests label Aug 5, 2024
@alexeykudinkin alexeykudinkin self-requested a review August 9, 2024 17:48
@xushiyan xushiyan force-pushed the add-hudi-datasource branch 8 times, most recently from fe1c93a to b76c200 Compare August 19, 2024 05:47
@MicroCheck //python:ray/data/tests/test_hudi

Signed-off-by: Shiyan Xu <[email protected]>
Signed-off-by: Shiyan Xu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data Ray Data-related issues @external-author-action-required Alternate tag for PRs where the author doesn't have labeling permission. go add ONLY when ready to merge, run all tests triage Needs triage (eg: priority, bug/not-bug, and owning component)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Data] Support read Hudi table as a DataSource
5 participants