我们抛开计数窗口，先看时间窗口

对于时间窗口最主要的就是时间，比如1分钟的窗口长度，那么这个1分钟是如何定义呢？

Flink中针对时间有3种类型

• EventTime[事件时间]

事件发生的时间，例如：点击网站上的某个链接的时间

• IngestionTime[摄入时间]

某个Flink节点的source operator接收到数据的时间，例如：某个source消费到kafka中的数据

• ProcessingTime[处理时间]

某个Flink节点执行某个operation的时间，例如：timeWindow接收到数据的时间

• 事件时间 event time

事件真实发生的时间。Flink1.12版本起默认事件时间。

• 处理时间 process time

Flink处理start-log中这条数据时的设备时间。Flink1.12之前默认处理时间。

Flink1.12版本之前，如何指定为事件时间呢？

EventTime

在大数据领域，日志服务器生成的一条数据也可以称为一个事件。EventTime是指在数据产生时该设备上对应的时间，这个时间在进入Flink之前已经存在于数据记录中了。

以后数据被Flink处理数据，如果使用EventTime作为时间标准，那么数据并不是按照EventTime的先后顺序被处理的，由于数据可能产生在多个不同的日志服务器，然后通常是再将数据写入到分布性消息中间件，然后被被Flink拉取进行处理时，处理的实际时间相对于数据产生的实际肯定有一定的延迟，并且EventTime可能也是乱序的。

那么为什么还要使用EventTime呢？

是因为使用EventTime时，Flink程序可以处理乱序事件和延迟数据。并且最重要的功能就是可以统计在数据产生时，对应时间的数据指标。

总之，使用EventTime的优势是结果的可预测性，缺点是缓存较大，增加了延迟，且调试和定位问题更复杂。

ProcessingTime

ProcessingTime是指事件数据被Operator处理时所在机器的系统时间，它提供了最好的性能和最低的延迟。

但是，Flink是一个在分布式的计算框架，数据从产生到被处理会有一定的延迟（例如从消息队列拉取数据到Source，Source再到处理的Operator会有一定的延迟），所以ProcessingTime无法精准的体现出数据在产生的那个时刻的变化情况。

IngestionTime

IngestionTime指的是事件数据进入到Flink的时间。每条数据的IngestionTime就是进入到SourceOperator时所在机器的系统时间。比如Flink从Kafka消息中间件消费数据，每一条数据的IngestionTime就是FlinkKafkaConsumer拉取数据进入到TaskManager对应的时间。

IngestionTime介于EventTime和ProcessingTime之间，与EventTime相比，IngestionTime程序无法处理任何无序事件或延迟数据，并且程序不必指定如何生成水，Flink会自动分配时间戳和自动生成水位线。