EventTime, thus you don't need to call this method for enabling event-time support anymore. Explicitly using processing-time windows and timers works in event-time mode. If you need to disable watermarks, please use
ExecutionConfig.setAutoWatermarkInterval(long). If you are using
IngestionTime, please manually set an appropriate
WatermarkStrategy. If you are using generic "time window" operations (for example
KeyedStream.timeWindow(org.apache.flink.streaming.api.windowing.time.Time)that change behaviour based on the time characteristic, please use equivalent operations that explicitly specify processing time or event time.
@PublicEvolving @Deprecated public enum TimeCharacteristic extends Enum<TimeCharacteristic>
|Enum Constant and Description|
Event time means that the time of each individual element in the stream (also called event) is determined by the event's individual custom timestamp.
Ingestion time means that the time of each individual element in the stream is determined when the element enters the Flink streaming data flow.
Processing time for operators means that the operator uses the system clock of the machine to determine the current time of the data stream.
|Modifier and Type||Method and Description|
Returns the enum constant of this type with the specified name.
Returns an array containing the constants of this enum type, in the order they are declared.
clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf
public static final TimeCharacteristic ProcessingTime
Using processing time for window operations results in general in quite non-deterministic results, because the contents of the windows depends on the speed in which elements arrive. It is, however, the cheapest method of forming windows and the method that introduces the least latency.
public static final TimeCharacteristic IngestionTime
Ingestion time is often a good compromise between processing time and event time. It does not need any special manual form of watermark generation, and events are typically not too much out-or-order when they arrive at operators; in fact, out-of-orderness can only be introduced by streaming shuffles or split/join/union operations. The fact that elements are not very much out-of-order means that the latency increase is moderate, compared to event time.
public static final TimeCharacteristic EventTime
Operators that window or order data with respect to event time must buffer data until they can be sure that all timestamps for a certain time interval have been received. This is handled by the so called "time watermarks".
Operations based on event time are very predictable - the result of windowing operations is typically identical no matter when the window is executed and how fast the streams operate. At the same time, the buffering and tracking of event time is also costlier than operating with processing time, and typically also introduces more latency. The amount of extra cost depends mostly on how much out of order the elements arrive, i.e., how long the time span between the arrival of early and late elements is. With respect to the "time watermarks", this means that the cost typically depends on how early or late the watermarks can be generated for their timestamp.
In relation to
IngestionTime, the event time is similar, but refers the event's
original time, rather than the time assigned at the data source. Practically, that means that
event time has generally more meaning, but also that it takes longer to determine that all
elements for a certain time have arrived.
public static TimeCharacteristic values()
for (TimeCharacteristic c : TimeCharacteristic.values()) System.out.println(c);
public static TimeCharacteristic valueOf(String name)
Copyright © 2014–2022 The Apache Software Foundation. All rights reserved.