1 三种时间语义

在实时流式计算中，"时间"是一个能影响计算结果的非常重要因素！

试想场景：每隔1分钟计算一次最近10分钟的活跃用户量：

①假设此刻的时间是13:10，要计算的活跃用户量时间段为：[ 13:00,13:10 )；

②有一条行为日志中记录的用户的行为时间是12:59，但到达flink计算程序时已是13:02；

那么，这个用户是否要纳入本次计算的结果中呢？看如何定义：

①如果时段 [13:00 , 13:10 ）定义的是用户行为的发生时间（数据中的业务时间），则不应纳入；

②如果时段 [13:00 , 13:10 ）定义的是计算时的时间，则应该纳入；

上面的问题是:数据的产生时间和数据的处理时间不一致

flink内部为了直观地统一计算时所用的时间标准，特制定了两种时间语义：

processing time 处理时间
event time 事件时间
Ingestion time 注入时间

时间语义主要影响 "窗口计算" ；

2 两种时间语义

时间语义，是flink中用于时间推进和时间判断的机制；

时间推进和时间判断，以什么为标准，就产出了两种不同的时间语义；

以 processing time为依据，则叫做处理时间语义
以 event time为依据，则叫做事件时间语义

时间语义的设计意义

process(EventLog eventlog){
Long  eventTime  =  eventLog.getTimestamp();
Long  processTime = System.currentMillimise()
      // 用户完全可以自己根据需求中的时间定义来进行相应的计算
}

Flink为什么还要搞出一个 “事件时间语义”：时间按数据中的业务时间戳来推进！

主要是，实时流式计算中，有大量跟时间相关的统计需求，比如：时间窗口计算，定时器等，而这些需求，如果都让用户像上面的代码那样自己去进行判断、处理，那么它觉得自己的api不够强大！

所以，flink想在api的层面，将两类时间定义的计算需求进行api层面的统一，它才搞出这么一种”事件时间语义“，有了这种语义，那么，处理时间和事件时间，都可以看成 ”时间”

用户在不同时间定义下，要进行一个定时动作时，就不需要再像上面的代码那种去进行各种判断，而是一个统一的动作： 到 xxx时间，给我做个什么事！

process(EventLog eventlog，TimeStamp timestamp){

// 不管需求是需要用哪种时间来计算，用户代码只需要看到一个timestamp了

}

代码中的timestamp到底是事件时间，还是处理时间，取决于环境中设置的“时间语义”

处理时间（processing time）语义

Processing Time是指数据被Operator处理时所在机器的系统时间。

处理时间遵循客观世界中时间的特性：单调递增，恒定速度，永不停滞，永不回退；

事件时间（event time）语义

Event Time是指在数据本身的业务时间（如用户行为日志中的用户行为时间戳）；

Event Time语义中，时间的推进完全由流入flink系统的数据来驱动：

数据中的业务时间推进到哪，flink就认为自己的时间推进到了哪

它可能停滞，也可能速度不恒定，但也一定是单调递增不可回退！

3 设置时间语义

1.12及以后，flink以event time作为默认的时间语义，在需要指定时间语义的相关操作（如时间窗口）时，可以通过显式的api来使用特定的时间语义；

上面我们介绍到 时间语义主要影响 "窗口计算" ；

API设置时间语义

keyedStream.window(SlidingEventTimeWindows.of(Time.seconds(5),Time.seconds(1)));

keyedStream.window(SlidingProcessingTimeWindows.of(Time.seconds(5),Time.seconds(1)));

keyedStream.window(TumblingEventTimeWindows.of(Time.seconds(5)));

keyedStream.window(TumblingProcessingTimeWindows.of(Time.seconds(5)));