Github user aljoscha commented on a diff in the pull request:
https://github.com/apache/flink/pull/3184#discussion_r98240527
--- Diff: docs/dev/stream/state.md ---
@@ -39,40 +39,247 @@ if necessary) to allow applications to hold very large
state.
This document explains how to use Flink's state abstractions when
developing an application.
-## Keyed State and Operator state
+## Operator State and Keyed State
-There are two basic state backends: `Keyed State` and `Operator State`.
+There are two basic kinds of state in Flink: `Operator State` and `Keyed
State`.
-#### Keyed State
+### Operator State
-*Keyed State* is always relative to keys and can only be used in functions
and operators on a `KeyedStream`.
-Examples of keyed state are the `ValueState` or `ListState` that one can
create in a function on a `KeyedStream`, as
-well as the state of a keyed window operator.
-
-Keyed State is organized in so called *Key Groups*. Key Groups are the
unit by which keyed state can be redistributed and
-there are as many key groups as the defined maximum parallelism.
-During execution each parallel instance of an operator gets one or more
key groups.
+With *Operator State* (or *non-keyed state*), each operator state is
+bound to one parallel operator instance.
+The Kafka source connector is a good motivating example for the use of
Operator State
+in Flink. Each parallel instance of this Kafka consumer maintains a map
+of topic partitions and offsets as its Operator State.
-#### Operator State
+New interfaces in Flink 1.2 subsume the `Checkpointed` interface in Flink
1.0 and
--- End diff --
I think we should document this without referring to old versions because
that will quickly become outdated.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
