Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Encode paneinfo with PaneInfoCoder. #34824

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

Merged
merged 5 commits into from
May 5, 2025

Conversation

claudevdm
Copy link
Collaborator

Please add a meaningful description for your change here


Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

  • Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
  • Update CHANGES.md with noteworthy changes.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

Build python source distribution and wheels
Python tests
Java tests
Go tests

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

@github-actions github-actions bot added the python label May 2, 2025
@claudevdm claudevdm force-pushed the fix-paneinfo-encoding branch from a51cee8 to 62b2c44 Compare May 2, 2025 22:55
Copy link
Contributor

github-actions bot commented May 3, 2025

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

Copy link
Contributor

github-actions bot commented May 3, 2025

Assigning reviewers. If you would like to opt out of this review, comment assign to next reviewer:

R: @liferoad for label python.

Available commands:

  • stop reviewer notifications - opt out of the automated review tooling
  • remind me after tests pass - tag the comment author after tests pass
  • waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

Copy link
Collaborator

@shunping shunping left a comment

Choose a reason for hiding this comment

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

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

@claudevdm
Copy link
Collaborator Author

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte.

@shunping
Copy link
Collaborator

shunping commented May 5, 2025

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte.

I don't get why we need to expose PaneInfoCoder because I don't think we want cx to use it (or mess with it). PaneInfoCoder should implicitly be part of WindowValueCoder according to runner api proto (

// pane - The first byte of the pane info determines which type of
).

I may be missing some important piece of background in #34348, but regarding

return key, (value, timestamp, pane_info)

can we do the following?

return key, window.GlobalWindows.windowed_value(value, timestamp, pane_info)

In this case, the coder of this output will be KVCoder[KeyCoder, WindowedValueCoder[GlobalWindowCoder, ValueCoder]], instead of KVCoder[KeyCoder, TupleCoder[ValueCoder, TimeStampCoder, PaneInfoCoder]].

@claudevdm
Copy link
Collaborator Author

claudevdm commented May 5, 2025

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte.

I don't get why we need to expose PaneInfoCoder because I don't think we want cx to use it (or mess with it). PaneInfoCoder should implicitly be part of WindowValueCoder according to runner api proto (

// pane - The first byte of the pane info determines which type of

).
I may be missing some important piece of background in #34348, but regarding

return key, (value, timestamp, pane_info)

can we do the following?

return key, window.GlobalWindows.windowed_value(value, timestamp, pane_info)

In this case, the coder of this output will be KVCoder[KeyCoder, WindowedValueCoder[GlobalWindowCoder, ValueCoder]], instead of KVCoder[KeyCoder, TupleCoder[ValueCoder, TimeStampCoder, PaneInfoCoder]].

That logic specifically avoids the window param for performance reasons #4933.

See the comments

# In this (common) case we can use a trivial trigger driver
# and avoid the (expensive) window param.

@liferoad liferoad merged commit ff9a22a into apache:master May 5, 2025
90 checks passed
@shunping
Copy link
Collaborator

shunping commented May 5, 2025

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte.

I don't get why we need to expose PaneInfoCoder because I don't think we want cx to use it (or mess with it). PaneInfoCoder should implicitly be part of WindowValueCoder according to runner api proto (

// pane - The first byte of the pane info determines which type of

).
I may be missing some important piece of background in #34348, but regarding

return key, (value, timestamp, pane_info)

can we do the following?

return key, window.GlobalWindows.windowed_value(value, timestamp, pane_info)

In this case, the coder of this output will be KVCoder[KeyCoder, WindowedValueCoder[GlobalWindowCoder, ValueCoder]], instead of KVCoder[KeyCoder, TupleCoder[ValueCoder, TimeStampCoder, PaneInfoCoder]].

That logic specifically avoids the window param for performance reasons #4933.

See the comments

# In this (common) case we can use a trivial trigger driver
# and avoid the (expensive) window param.

Hmmmm, my understanding of that comment is different. I think the optimization in #4933 is that for global windows we don't need to put WindowParam in the DoFn. Anyway, just want to call out here.

def reify_timestamps(element, timestamp=DoFn.TimestampParam):
   ...

@@ -92,6 +93,7 @@ def register_standard_coders(self, fallback_coder):
self._register_coder_internal(bytes, coders.BytesCoder)
self._register_coder_internal(bool, coders.BooleanCoder)
self._register_coder_internal(str, coders.StrUtf8Coder)
self._register_coder_internal(windowed_value.PaneInfo, coders.PaneInfoCoder)
Copy link
Contributor

Choose a reason for hiding this comment

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

This fix has a large blast radius. It changed registered standard coders which is default behavior globally. Shall we do this or just put a coder implementation in new ReShuffle?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Are you suggesting to define PaneInfoCoder here

and then use CoderRegistry.register_coder?

I don't have strong opinion, is there a disadvantage to doing it here? It seems like an 'internal' coder use case?

Copy link
Contributor

Choose a reason for hiding this comment

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

@kennknowles What do you think about this? We should use PaneInfoCoder but it could break the job update.

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 a disadvantage to doing it here

This introduces a breaking change such that windowed_value.PaneInfo has changed default coder. This is not limited to ReShuffle but also user pipeline.

Since test results shows PaneInfoCoder is much more efficient than FastPrimitiveCoder for PaneInfo, I am fine with the change, just need to know this is another breaking change introduced in 2.65.0

If we keep this change I recommend to also mention this in https://github.com/apache/beam/blob/master/CHANGES.md#breaking-changes-1

Copy link
Contributor

Choose a reason for hiding this comment

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

@shunping
Copy link
Collaborator

shunping commented May 5, 2025

Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work?

FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte.

I don't get why we need to expose PaneInfoCoder because I don't think we want cx to use it (or mess with it). PaneInfoCoder should implicitly be part of WindowValueCoder according to runner api proto (

// pane - The first byte of the pane info determines which type of

).
I may be missing some important piece of background in #34348, but regarding

return key, (value, timestamp, pane_info)

can we do the following?

return key, window.GlobalWindows.windowed_value(value, timestamp, pane_info)

In this case, the coder of this output will be KVCoder[KeyCoder, WindowedValueCoder[GlobalWindowCoder, ValueCoder]], instead of KVCoder[KeyCoder, TupleCoder[ValueCoder, TimeStampCoder, PaneInfoCoder]].

That logic specifically avoids the window param for performance reasons #4933.
See the comments

# In this (common) case we can use a trivial trigger driver
# and avoid the (expensive) window param.

Hmmmm, my understanding of that comment is different. I think the optimization in #4933 is that for global windows we don't need to put WindowParam in the DoFn. Anyway, just want to call out here.

def reify_timestamps(element, timestamp=DoFn.TimestampParam):
   ...

CC @robertwb (the author of $4933) regarding the WindowParam comment here.

claudevdm added a commit to claudevdm/beam that referenced this pull request May 6, 2025
* Encode paneinfo with PaneInfoCoder.

* Fix tests.

* Fix import.

* Add typecoder test.

* Implement eq and hash.

---------

Co-authored-by: Claude <[email protected]>
Abacn pushed a commit that referenced this pull request May 6, 2025
* Encode paneinfo with PaneInfoCoder.

* Fix tests.

* Fix import.

* Add typecoder test.

* Implement eq and hash.

---------

Co-authored-by: Claude <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants