[Python] Speed up ApproximateUnique accumulator merging - #39921
[Python] Speed up ApproximateUnique accumulator merging#39921sliortega295-ops wants to merge 1 commit into
Conversation
Generated-by: OpenAI Codex (GPT-5)
|
Assigning reviewers: R: @damccorm for label python. Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
| raise RuntimeError("Runtime exception: %s" % e) | ||
|
|
||
| # created an issue https://github.com/apache/beam/issues/19459 to speed up | ||
| # merge process. |
There was a problem hiding this comment.
While this is an improvement, I'll note that it does not actually address the core issue in #19459
This PR avoids creating an extra accumulator and doing one additional merge operation, but it doesn't handle the efficient merging of 2 accumulators.
With that said, I don't think a fast merge is possible here because of the uniqueness constraint, so we can still probably call it fixed
| self.assertEqual( | ||
| later_accumulator_states, | ||
| [( | ||
| list(accumulator._sample_heap), | ||
| set(accumulator._sample_set), | ||
| accumulator._min_hash) for accumulator in accumulators[1:]]) |
There was a problem hiding this comment.
What is this assert checking? Isn't this just running against our test data that we constructed?
|
|
||
| merged_accumulator = combine_fn.merge_accumulators(iter(accumulators)) | ||
|
|
||
| self.assertIs(merged_accumulator, accumulators[0]) |
There was a problem hiding this comment.
This is testing our specific implementation, not correctness. For example, it would be equally valid (and maybe better) to use the largest accumulator available as our starting point.
Let's update this test to just test correctness instead of the specific behavior we've baked in.
| self.assertEqual(set(range(24, 40)), merged_accumulator._sample_set) | ||
| self.assertEqual(24, merged_accumulator._min_hash) |
There was a problem hiding this comment.
Both of these asserts would succeed if the only accumulator merged was the last one. Can we update to avoid this? An easy way to do so would be to make the sample size 30 (and update the asserts)
| for accumulator in accumulators: | ||
| accumulator_iter = iter(accumulators) | ||
| try: | ||
| merged_accumulator = next(accumulator_iter) |
There was a problem hiding this comment.
I mentioned this below, but it would likely be more efficient to find the largest accumulator and use that as the starting point.
Ideally, we'd look for the accumulator with the largest _sample_heap size. If 2 are tied, then we'd look for the one with the larger _min_hash
2 participants
Summary
ApproximateUniqueaccumulator instead of allocating an empty heap and reinserting every sampled hashCHANGES.mdThis brings the Python merge path in line with the existing Java implementation and removes one accumulator's worth of heap insertions from every merge.
Fixes #19459.
Validation
pytest apache_beam/transforms/stats_test.py: 87 passed with the source implementationgit diff --check: passedNo GPU was used or required.
AI disclosure
The implementation, tests, benchmark, and this description were generated with OpenAI Codex at the account owner's request. Codex re-checked the final diff against the repository code and ran the validations listed above. No separate human line-by-line code review was performed before submission.