Flink开发-时间语义与窗口分类

1.Flink的三种时间语义

Flink实时计算划分窗口时，如果使用时间作为划分窗口的依据，时间有不同的类型，分为Event Time、Ingestion Time、Processing Time。Flink默认使用的是Processing Time，程序运行如果使用不同的时间类型，计算的结果完全不同，可以根据实际需求选择使用具体哪一种时间类型。

Flink默认使用的是Processing Time。

1.1 Event Time 事件时间

Event Time指的是数据流中每个元素或者每个事件自带的时间属性，一般是事件发生的时间。由于事件从发生到进入Flink时间算子之间有很多环节，一个较早发生的事件因为延迟可能较晚到达，因此使用Event Time意味着事件到达有可能是乱序的。

使用Event Time时，最理想的情况下，我们可以一直等待所有的事件到达后再进行时间窗口的处理。假设一个时间窗口内的所有数据都已经到达，基于Event Time的流处理会得到正确且一致的结果。无论我们是将同一个程序部署在不同的计算环境，还是在相同的环境下多次计算同一份数据，都能够得到同样的计算结果。我们根本不同担心乱序到达的问题。

但这只是理想情况，现实中无法实现，因为我们既不知道究竟要等多长时间才能确认所有事件都已经到达，更不可能无限地一直等待下去。在实际应用中，当涉及到对事件按照时间窗口进行统计时，Flink会将窗口内的事件缓存下来，直到接收到一个Watermark，Watermark假设不会有更晚数据的到达。Watermark意味着在一个时间窗口下，Flink会等待一个有限的时间，这在一定程度上降低了计算结果的绝对准确性，而且增加了系统的延迟。比起其他几种时间语义，使用Event Time的好处是某个事件的时间是确定的，这样能够保证计算结果在一定程度上的可预测性。

一个基于Event Time的Flink程序中必须定义：一、每条数据的Event Time时间戳作为Event Tme，二、如何生成Watermark。我们可以使用数据自带的时间作为Event Time，也可以在数据到达Flink后人为给Event Time赋值。

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

1.2 Processing Time 处理时间

对于某个算子来说，Processing Time指算子使用当前机器的系统时钟时间。在Processing Time的时间窗口场景下，无论事件什么时候发生，只要该事件在某个时间段到达了某个算子，就会被归结到该窗口下，不需要Watermark机制。对于一个程序，在同一个计算环境来说，每个算子都有一定的耗时，同一个事件的Processing Time，第n个算子和第n+1个算子不同。如果一个程序在不同的集群和环境下执行，限于软硬件因素，不同环境下前序算子处理速度不同，对于下游算子来说，事件的Processing Time也会不同，不同环境下时间窗口的计算结果会发生变化。因此，Processing Time在时间窗口下的计算会有不确定性。

Processing Time只依赖当前执行机器的系统时钟，不需要依赖Watermark，无需缓存。Processing Time是实现起来非常简单，也是延迟最小的一种时间语义。

1.3 Ingestion Time 进入时间

Ingestion Time是事件到达Flink Source的时间。从Source到下游各个算子中间可能有很多计算环节，任何一个算子的处理速度快慢可能影响到下游算子的Processing Time。而Ingestion Time定义的是数据流最早进入Flink的时间，因此不会被算子处理速度影响。

Ingestion Time通常是Event Time和Processing Time之间的一个折中方案。比起Event Time，Ingestion Time可以不需要设置复杂的Watermark，因此也不需要太多缓存，延迟较低。比起Processing Time，Ingestion Time的时间是Source赋值的，一个事件在整个处理过程从头至尾都使用这个时间，而且后续算子不受前序算子处理速度的影响，计算结果相对准确一些，但计算成本比Processing Time稍高。

1.4 设置时间标准

        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        //设置EventTime作为时间标准
        env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
        //设置IngestionTime作为时间标准
        env.setStreamTimeCharacteristic(TimeCharacteristic.IngestionTime);
        //设置ProcessingTime作为时间标准
        env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);

2.Window Assinger

当调用window或windowAll方法时，所传入的参数就是Window Assigner（窗口分配器），其作用是决定划分什么样类型的窗口，即以何种条件划分窗口，输入的数据以何种方式分配到窗口内，窗口如何触发等等。Flink提供了Tumbling windows（滚动窗口）、Sliding windows（滑动窗口）, Session windows（会话窗口）和Global windows（全局窗口，另外CountWindow属于Global windows）。这些自带的Window Assigner可以满足大多数的场景，如果有特殊需要可以继承WindowAssigner这个抽象类实现自己的Window Assigner。在以上四种内置Window Assigner中，除了Global windows，其他三种都属于时间类型的窗口，它们既可以按照ProcessingTime划分窗口，也可以按照EventTime划分窗口。

时间类型的窗口，都有窗口的起始时间和结束时间，时间的类型是timestamp格式（timestamp的值是指从1970年1月1日0时0分0秒到现在的long类型毫秒数）。窗口的起始时间、结束时间是前闭后开的，即包括起始时间，不包括结束时间，并且窗口的起始时间和结束时间必须是窗口长度的整数倍。例如一个滚动窗口的长度为10秒，起始时间是2020-01-01 00:00:00，那么对应的timestamp格式就是[1577808000000, 1577808010000)。窗口的start就是1577808000000，窗口的end就是1577808010000，窗口的maxTimestamp就是窗口的end减1即1577808009999。

2.1 滚动窗口（Tumbling Windows）

将数据依据固定的窗口长度对数据进行切片。滚动窗口分配器将每个元素分配到一个指定窗口大小的窗口中，滚动窗口有一个固定的大小，并且不会出现重叠。

特点：时间对齐，窗口长度固定，没有重叠。

2.2 滑动窗口（Sliding Windows）

滑动窗口时固定窗口的更广义的一种新式，滑动窗口由固定的窗口长度和滑动间隔组成，滑动窗口分配器将元素分配到固定长度的窗口中，与滚动窗口类似，窗口的大小由窗口大小参数来配置，另一个窗口滑动参数控制滑动窗口开始的频率。因此，滑动窗口如果滑动参数小于窗口大小的话，窗口是可以重叠的，在这种情况下元素会被分配到多个窗口中。

特点：时间对齐，窗口长度固定，有重叠。

2.3 会话窗口（Session Windows）

由一系列时间组合一个指定时间长度的timeout间隙组成，类似于web应用的session，也就是一段时间没有接收到新数据就会生成新的窗口。session窗口分配器通过session活动来对元素进行分组，session窗口跟滚动窗口和滑动窗口相比，不会有重叠和固定的开始时间和结束时间的情况，相反，当它在一个固定的时间周期内不再收到元素，即非活动间隔产生，那这个窗口就会关闭。一个session窗口通过一个session间隔来配置，那这个session间隔定义了非活跃周期的长度，但这个非活跃周期产生，那么当前的session将关闭并且后续的元素将被分配到新的session窗口中去。

特点：时间无对齐。

2.4 GlobalWindow

按照指定的数据条数生成一个Window，与时间无关。

3.窗口程序的骨架

在划分Window之前，首先要确定该DataStream是否调用了key算子将数据按照key进行分组了。如果没有调用keyBy算子，可以调用windowAll方法的返回一个AllWindowedStream，这种window叫做Non-Keyed Windows（未分组的Widnows）；如果事先已经调用了keyBy算子，即对KeyedStream可以调用window方法返回一个WindowedStream，这种window叫做Keyed Windows（分组的Widnows）。由于调用windowAll/window算子后会生成会生成新WindowedStream/WindowedStream，所以窗口算也是属于Transformation。

3.1 Non-Keyed Windows

未分组的Widonws，即DataSteam直接调用windowAll算子得到的Windows，Non-Keyed Windows的特点是，在某一个具体的窗口，所有的数据都会被窗口算子路由到一个subtask中进行运算，如果并行度大于1，下一次生成的window的数据会被路由到其他的subtask中进行运算。

下面是Non-Keyed Windows的方法调用顺序和方法说明：

stream.windowAll(…)//<-  必选方法: 划分Non-Keyed Windows，参数为指定的Window Assinger
        [.trigger(…)]//<-  可选方法: 指定触发器，如果不指定有默认的触发器
        [.evictor(…)]//<-  可选方法: 指定剔除器，如果不指定有默认的剔除器
        [.allowedLateness(…)]//<-  可选方法: 指定延迟触发时间，如果不指定，默认为0
        [.sideOutputLateData(…)]//<-  可选方法: 指定延迟数据的侧流输出的Tag， 用来筛选出打上指定tag的迟到数据
        .sum/reduce/aggregate/fold/apply()//<-  必选方法: 指定窗口函数
        [.getSideOutput(…)]//<-  可选方法: 指定侧流数据的Tag，筛选出指定tag类型的数据

3.2 Keyed Windows

分组的Widonws，即KeyedStream直接调用window算子得到的Windows。Keyed Windows

的特点是：窗口中的数据会根据key进行分组，key相同的数据一定会被分到同一个组内，并被路由到同一个subtask中，一个key对应一个组，一个subtask中可以有零到多个组。窗口触发会对每个组进行计算，每个组都会得到一个结果。

下面是Keyed Windows的方法调用顺序和方法说明：

stream.keyKey(…)//<-  先对DataStream调用keyBy得到keyedStream
        .window(…)//<-  必选方法: 指定相应的窗口分配器       
        [.trigger(…)]//<-  可选方法: 指定触发器，如果不指定有默认的触发器       
        [.evictor(…)]//<-  可选方法: 指定剔除器，如果不指定有默认的剔除器       
        [.allowedLateness(…)]//<-  可选方法: 指定延迟触发时间，如果不指定，默认为0       
        [.sideOutputLateData(…)]//<-  可选方法: 指定延迟数据的测流输出的Tag        
        .sum/reduce/aggregate/fold/apply()//<-  必选方法: 指定窗口函数       
        [.getSideOutput(…)]//<-  可选方法: 指定测流数据的Tag