CheckpointingMode
.@Public @Deprecated public enum CheckpointingMode extends Enum<CheckpointingMode>
When checkpointing is activated, the data streams are replayed such that lost parts of the
processing are repeated. For stateful operations and functions, the checkpointing mode defines
whether the system draws checkpoints such that a recovery behaves as if the operators/functions
see each record "exactly once" (EXACTLY_ONCE
), or whether the checkpoints are drawn in a
simpler fashion that typically encounters some duplicates upon recovery (AT_LEAST_ONCE
)
Enum Constant and Description |
---|
AT_LEAST_ONCE
Deprecated.
Sets the checkpointing mode to "at least once".
|
EXACTLY_ONCE
Deprecated.
Sets the checkpointing mode to "exactly once".
|
Modifier and Type | Method and Description |
---|---|
static CheckpointingMode |
convertFromCheckpointingMode(CheckpointingMode semantic)
Deprecated.
|
static CheckpointingMode |
convertToCheckpointingMode(CheckpointingMode semantic)
Deprecated.
|
static CheckpointingMode |
valueOf(String name)
Deprecated.
Returns the enum constant of this type with the specified name.
|
static CheckpointingMode[] |
values()
Deprecated.
Returns an array containing the constants of this enum type, in
the order they are declared.
|
public static final CheckpointingMode EXACTLY_ONCE
For example, if a user function counts the number of elements in a stream, this number will consistently be equal to the number of actual elements in the stream, regardless of failures and recovery.
Note that this does not mean that each record flows through the streaming data flow only once. It means that upon recovery, the state of operators/functions is restored such that the resumed data streams pick up exactly at after the last modification to the state.
Note that this mode does not guarantee exactly-once behavior in the interaction with external systems (only state in Flink's operators and user functions). The reason for that is that a certain level of "collaboration" is required between two systems to achieve exactly-once guarantees. However, for certain systems, connectors can be written that facilitate this collaboration.
This mode sustains high throughput. Depending on the data flow graph and operations, this mode may increase the record latency, because operators need to align their input streams, in order to create a consistent snapshot point. The latency increase for simple dataflows (no repartitioning) is negligible. For simple dataflows with repartitioning, the average latency remains small, but the slowest records typically have an increased latency.
public static final CheckpointingMode AT_LEAST_ONCE
For example, if a user function counts the number of elements in a stream, this number will equal to, or larger, than the actual number of elements in the stream, in the presence of failure and recovery.
This mode has minimal impact on latency and may be preferable in very-low latency scenarios, where a sustained very-low latency (such as few milliseconds) is needed, and where occasional duplicate messages (on recovery) do not matter.
public static CheckpointingMode[] values()
for (CheckpointingMode c : CheckpointingMode.values()) System.out.println(c);
public static CheckpointingMode valueOf(String name)
name
- the name of the enum constant to be returned.IllegalArgumentException
- if this enum type has no constant with the specified nameNullPointerException
- if the argument is nullpublic static CheckpointingMode convertToCheckpointingMode(CheckpointingMode semantic)
public static CheckpointingMode convertFromCheckpointingMode(CheckpointingMode semantic)
Copyright © 2014–2024 The Apache Software Foundation. All rights reserved.