Interface StateBackend

  • All Superinterfaces:
    Serializable
    All Known Subinterfaces:
    ConfigurableStateBackend, DelegatingStateBackend
    All Known Implementing Classes:
    AbstractChangelogStateBackend, AbstractFileStateBackend, AbstractManagedMemoryStateBackend, AbstractStateBackend, BatchExecutionStateBackend, ChangelogStateBackend, DeactivatedChangelogStateBackend, EmbeddedRocksDBStateBackend, EmbeddedRocksDBStateBackend, ForStStateBackend, HashMapStateBackend

    @PublicEvolving
    public interface StateBackend
    extends Serializable
    A State Backend defines how the state of a streaming application is stored locally within the cluster. Different State Backends store their state in different fashions, and use different data structures to hold the state of a running application.

    For example, the hashmap state backend keeps working state in the memory of the TaskManager. The backend is lightweight and without additional dependencies.

    The EmbeddedRocksDBStateBackend stores working state in an embedded RocksDB and is able to scale working state to many terabytes in size, only limited by available disk space across all task managers.

    Raw Bytes Storage and Backends

    The StateBackend creates services for keyed state and operator state.

    The CheckpointableKeyedStateBackend and OperatorStateBackend created by this state backend define how to hold the working state for keys and operators. They also define how to checkpoint that state, frequently using the raw bytes storage (via the CheckpointStreamFactory). However, it is also possible that for example a keyed state backend simply implements the bridge to a key/value store, and that it does not need to store anything in the raw byte storage upon a checkpoint.

    Serializability

    State Backends need to be serializable, because they distributed across parallel processes (for distributed execution) together with the streaming application code.

    Because of that, StateBackend implementations (typically subclasses of AbstractStateBackend) are meant to be like factories that create the proper states stores that provide access to the persistent storage and hold the keyed- and operator state data structures. That way, the State Backend can be very lightweight (contain only configurations) which makes it easier to be serializable.

    Thread Safety

    State backend implementations have to be thread-safe. Multiple threads may be creating keyed-/operator state backends concurrently.