问题
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)的延迟数据过来，那么该怎么处理呢？