问题

window是解决流计算中的什么问题？

怎么划分window？有哪几种window？window与时间属性之间的关系？

window里面的数据何时被计算？

window 何时被清除？

第一个问题

window是解决流计算中的什么问题？

熟悉google dataflow模型的同学应该清楚，流计算被抽象成四个问题，what，where，when，how？

那么window解决的是where，也就是将无界数据划分成有界数据。

第二个问题

在说明如何划分window之前，我们先看下流计算中有哪几种时间概念

event time：记录发生的时间，比如你点击某个网站当时产生的时间

ingest time：log 进入系统的时间，比如从系统从kafka读进记录的时间

process time：处理时间，记录被处理时的系统时间。

那么window是如何划分的呢？

答案是：

每一条记录来了以后会根据时间属性值采用不同的window assinger 方法分配给一个或者多个窗口。

那么有几种window assinger方式呢，目前来看是每种时间属性对应三种（flink没有基于注入时间的窗口）

1）固定窗口分配：一条记录只属于一个窗口

2）滑动窗口分配：一条记录属于多个窗口

3）会话窗口：一条记录一个窗口

例子：

固定窗口：窗口大小是5s，key为A的数据分别在0,4999ms，5000s产生了数据，那么形成的window如下，窗口允许等待时间为5s

滑动窗口：窗口大小为5s，滑动间隔为1s，key为A的数据分别在0,4999ms，5000s产生了数据，那么形成的window为

session窗口： 间隔5s中，key为A的数据分别在0,4999ms，5000s产生了数据，那么形成的window为

第三个问题，window的数据何时被计算，也就是四个问题中的第三个问题when？

解决这个问题用的方式是watermark和trigger，watermark用来标记窗口的完整性，trigger用来设计窗口数据触发条件。一般的trigger实现是当watermark处于某种时间条件下或者窗口数据达到一定条件，窗口的数据开始计算。

举个常见的trigger实现方式：当watermark越过window边界，触发窗口计算，对第一个固定窗口的三条数据。

基础条件是：watermark和数据本身一样作为正常的消息在流中流动。

1）windowoperator接到消息以后，首先存到state（本文使用rocksdb），存放的格式为k,v,key的格式是key + window,value是key和window对应的数据

2）注册一个timer，timer的数据结构为【key，window，window边界 - 1】，将timer放到集合中去。

3）当windowoperator收到watermark以后，取出集合中小于watermark的timer，触发其window。触发的过程中将state里面对应key及window的数据取出来，这里要经过序列化的过程，发送给windowfunction计算。

4）数据发送给windowfunction，实现windowfunction的window数据计算逻辑

对于固定窗口，当watermark大于5000的时候，(A,0),(A,4999)会被计算，当watermark大于9999的时候，（A，5000）会被计算

最后一个问题。如果window一直存在，那么势必会造成不必要的内存和磁盘浪费

那么window什么时候被清除呢？

每个window都会注册一个cleantime，cleantime代表这个window的存活时间，cleantime = window maxtime + 窗口允许的最大延迟

当watermark > cleanTime的时候，该窗口会被清除，对应的状态也会被清除。对于固定窗口的例子，形成的cleantimer为

当5000 < watermark < 9999的时候，窗口timewindow(0,5000)会被计算不会被清除

当9999 < watermark < 14999的时候，窗口timewindow(5000,10000)会被计算但是不会被清除，清除timewindow(0,5000)

只有watermark 》 14999的时候，清除timewindow(5000,10000)

最后有几个问题？

假如5000 < watermark < 9999，又有timewindow(0, 5000)的延迟数据过来，那么该怎么处理呢？