[
https://issues.apache.org/jira/browse/BEAM-10475?focusedWorklogId=500365&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-500365
]
ASF GitHub Bot logged work on BEAM-10475:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 14/Oct/20 01:05
Start Date: 14/Oct/20 01:05
Worklog Time Spent: 10m
Work Description: nehsyc commented on pull request #13069:
URL: https://github.com/apache/beam/pull/13069#issuecomment-708092225
> > On empty key vs. marker, sorry for going back and forth--let's settle
this before you change the code again.
> > Taking a step back, the question we want to answer is "do all
ShardedKeys have a shard id" or is the shard id optional. If the former, I
think representing it as a `(bytes, K)` tuple makes sense, but if we ever want
to talk about "not having" a shard id than it should, logically, be
`(Optional[bytes], K)` and we should use an explicit bit rather than have a
"special" value of bytes that means "not there".
>
> Since we expect ShardedKey to be produced by the runner we don't expect
the SDK/user to care so making it required simplifies user & SDK code. The
runner is the only one that may care to differentiate unsharded vs sharded and
can use any representation it wants to do so (e.g. by encoding Optional[bytes]
into the bytes blob). The runners type doesn't have to match the user/SDK type.
> > On empty key vs. marker, sorry for going back and forth--let's settle
this before you change the code again.
> > Taking a step back, the question we want to answer is "do all
ShardedKeys have a shard id" or is the shard id optional. If the former, I
think representing it as a `(bytes, K)` tuple makes sense, but if we ever want
to talk about "not having" a shard id than it should, logically, be
`(Optional[bytes], K)` and we should use an explicit bit rather than have a
"special" value of bytes that means "not there".
>
> Since we expect ShardedKey to be produced by the runner we don't expect
the SDK/user to care so making it required simplifies user & SDK code. The
runner is the only one that may care to differentiate unsharded vs sharded and
can use any representation it wants to do so (e.g. by encoding Optional[bytes]
into the bytes blob). The runners type doesn't have to match the user/SDK type.
There doesn't seem to be a reason for end users to not have shard id set if
they want to use a ShardedKey (otherwise why not just using the key?) For
runners, shard id being non-existing could be meaningful so they can
differentiate whether the shard has been set (during auto-sharding for
example). But I think Luke made a good point that it's up to the runner to use
any marker within the shard id bytes to do such checks.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 500365)
Time Spent: 9.5h (was: 9h 20m)
> GroupIntoBatches with Runner-determined Sharding
> ------------------------------------------------
>
> Key: BEAM-10475
> URL: https://issues.apache.org/jira/browse/BEAM-10475
> Project: Beam
> Issue Type: Improvement
> Components: runner-dataflow
> Reporter: Siyuan Chen
> Assignee: Siyuan Chen
> Priority: P2
> Labels: GCP, performance
> Time Spent: 9.5h
> Remaining Estimate: 0h
>
> [https://s.apache.org/sharded-group-into-batches|https://s.apache.org/sharded-group-into-batches__]
> Improve the existing Beam transform, GroupIntoBatches, to allow runners to
> choose different sharding strategies depending on how the data needs to be
> grouped. The goal is to help with the situation where the elements to process
> need to be co-located to reduce the overhead that would otherwise be incurred
> per element, while not losing the ability to scale the parallelism. The
> essential idea is to build a stateful DoFn with shardable states.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
