Flink window机制

问题

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)的延迟数据过来,那么该怎么处理呢?

你可能感兴趣的:(Flink window机制)