[
https://issues.apache.org/jira/browse/FLINK-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15929730#comment-15929730
]
ASF GitHub Bot commented on FLINK-5991:
---------------------------------------
Github user aljoscha commented on the issue:
https://github.com/apache/flink/pull/3508
I would like us to take some time and think about the name. We are about to
introduce a thing called "broadcast state" somewhat soon in the effort to make
streaming joins possible. This broadcast state will provide an interface very
similar to the current keyed state (we'll probably reuse the descriptors and
state interfaces) but be checkpointed only on one operator because we only
allow modifications based on broadcast input.
I propose to rename the state we're talking about here to `UnionState` (or
something) similar because what it does is take the snapshotted state from all
operators and when restoring sends the union of that to all operators.
> Expose Broadcast Operator State through public APIs
> ---------------------------------------------------
>
> Key: FLINK-5991
> URL: https://issues.apache.org/jira/browse/FLINK-5991
> Project: Flink
> Issue Type: New Feature
> Components: DataStream API, State Backends, Checkpointing
> Reporter: Tzu-Li (Gordon) Tai
> Assignee: Tzu-Li (Gordon) Tai
> Fix For: 1.3.0
>
>
> The broadcast operator state functionality was added in FLINK-5265, it just
> hasn't been exposed through any public APIs yet.
> Currently, we have 2 streaming connector features for 1.3 that are pending on
> broadcast state: rescalable Kinesis / Kafka consumers with shard / partition
> discovery (FLINK-4821 & FLINK-4022). We should consider exposing broadcast
> state for the 1.3 release also.
> This JIRA also serves the purpose to discuss how we want to expose it.
> To initiate the discussion, I propose:
> 1. For the more powerful {{CheckpointedFunction}}, add the following to the
> {{OperatorStateStore}} interface:
> {code}
> <S> ListState<S> getBroadcastOperatorState(ListStateDescriptor<S>
> stateDescriptor);
> <T extends Serializable> ListState<T>
> getBroadcastSerializableListState(String stateName);
> {code}
> 2. For a simpler {{ListCheckpointed}} variant, we probably should have a
> separate {{BroadcastListCheckpointed}} interface.
> Extending {{ListCheckpointed}} to let the user define either the list state
> type of either {{PARTITIONABLE}} or {{BROADCAST}} might also be possible, if
> we can rely on a contract that the value doesn't change. Or we expose a
> defining method (e.g. {{getListStateType()}}) that is called only once in the
> operator. This would break user code, but can be considered because it is
> marked as {{PublicEvolving}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
