[
https://issues.apache.org/jira/browse/FLINK-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315494#comment-15315494
]
Tzu-Li (Gordon) Tai edited comment on FLINK-3231 at 6/4/16 1:04 PM:
--------------------------------------------------------------------
Hi [~StephanEwen],
Finally reached the point where we could start working on this. I'm currently
in the designing phase for this feature.
Merged state on restore sounds interesting (is there currently any doc / thread
/ JIRA that's issuing this merged states feature?).
However, I don't think it will be able to fully solve the described problem for
this JIRA, unless we are expecting the streaming job to fail and restore every
time resharding happens. We still need coordination between the subtasks to
gracefully handle the resharding.
On the other hand, if the merged state feature also provides access (including
incomplete checkpoints) from subtasks during job execution, then it might be
possible to figure out an implementation.
was (Author: tzulitai):
Hi Stephan,
Finally reached the point where we could start working on this. I'm currently
in the designing phase for this feature.
Merged state on restore sounds interesting (is there currently any doc / thread
/ JIRA that's issuing this merged states feature?).
However, I don't think it will be able to fully solve the described problem for
this JIRA, unless we are expecting the streaming job to fail and restore every
time resharding happens. We still need coordination between the subtasks to
gracefully handle the resharding.
On the other hand, if the merged state feature also provides access (including
incomplete checkpoints) from subtasks during job execution, then it might be
possible to figure out an implementation.
> Handle Kinesis-side resharding in Kinesis streaming consumer
> ------------------------------------------------------------
>
> Key: FLINK-3231
> URL: https://issues.apache.org/jira/browse/FLINK-3231
> Project: Flink
> Issue Type: Sub-task
> Components: Streaming Connectors
> Affects Versions: 1.1.0
> Reporter: Tzu-Li (Gordon) Tai
>
> A big difference between Kinesis shards and Kafka partitions is that Kinesis
> users can choose to "merge" and "split" shards at any time for adjustable
> stream throughput capacity. This article explains this quite clearly:
> https://brandur.org/kinesis-by-example.
> This will break the static shard-to-task mapping implemented in the basic
> version of the Kinesis consumer
> (https://issues.apache.org/jira/browse/FLINK-3229). The static shard-to-task
> mapping is done in a simple round-robin-like distribution which can be
> locally determined at each Flink consumer task (Flink Kafka consumer does
> this too).
> To handle Kinesis resharding, we will need some way to let the Flink consumer
> tasks coordinate which shards they are currently handling, and allow the
> tasks to ask the coordinator for a shards reassignment when the task finds
> out it has found a closed shard at runtime (shards will be closed by Kinesis
> when it is merged and split).
> We need a centralized coordinator state store which is visible to all Flink
> consumer tasks. Tasks can use this state store to locally determine what
> shards it can be reassigned. Amazon KCL uses a DynamoDB table for the
> coordination, but as described in
> https://issues.apache.org/jira/browse/FLINK-3211, we unfortunately can't use
> KCL for the implementation of the consumer if we want to leverage Flink's
> checkpointing mechanics. For our own implementation, Zookeeper can be used
> for this state store, but that means it would require the user to set up ZK
> to work.
> Since this feature introduces extensive work, it is opened as a separate
> sub-task from the basic implementation
> https://issues.apache.org/jira/browse/FLINK-3229.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
