窗口聚集和非窗口聚集

flink

其实这个之前的窗口使用经验中已经写明了，不过现在看到更好的一个总结，把他单独记录下。

窗口聚集（Window Aggregate）

窗口聚集就相当于前面说的，先分区，然后再分区上开窗，然后窗口触发需要满足一定条件，且只能触发一次，这就有延迟的问题，其本质上相当于批处理。

看这个用户点击量按时间统计，先按user字段分区，然后开窗，这里用的是根据event time开启滚动窗口，统计每个用户在1小时内的点击量，比如13:00-14:00 Mary的点击量为3。那么这个结果只能等到14点的时候才会输出，延迟了一个小时，其实相当于批处理。

tumble window

滚动窗口是特殊的滑动窗口，窗口的size=step。滚动窗口其实就是批处理，缺点是比较明显的。

滚动窗口的使用场景：

目前没想到，因为都可以用Group聚集代替，实时性还高，并且还没有超过watermark延迟数据的准确性问题，想不到有什么特别的使用场景。

sliding window

因为滑动窗口是重叠的，所有滑动窗口不支持与LAST_VALUE、FIRST_VALUE或TopN函数共同使用。

滑动窗口使用场景

滑动窗口适用于按一定的频率(step)统计过去一个时间段内(size)发生事件的聚合。
例如：每隔30s就输出一次过去一分钟内用户的点击次数

session window

session窗口不像滚动、滑动窗口，因为窗口的触发是根据session gap来决定的。
如果session gap设置的时间足够短，这样是可以保证实时性的，但是缺点是要频繁的开窗和窗口触发，不知道是否有性能问题。但是如果session gap设置的过长，又不能保证实时性了。

session窗口还有一个缺点是没办法决定窗口的开始和结束时间，所以碰到比如统计每隔10分钟成交金额，那么比如10:00-10:10,10:10-10:20 这两个时间段要输出结果，怎么根据session窗口的函数拿到开始时间呢？ 这是个问题。看上面滚动窗口的列子，通过tumble_end函数可以拿到窗口的结束时间，这个时间就是需求上要统计的结束时间。

如果使用Group聚合，然后在分区上再开session窗口，这样就失去意义了，没必要开了。

session窗口的应用场景：

就跟session窗口的定义一样，如果对用户在活跃的会话时间内的事件做聚合统计，用session窗口比较合适。
比如统计用户活跃会话时间内点击次数，什么叫活跃会话呢？如果超过30s用户没有操作，就当会话结束。用session窗口统计很方便。

over窗口

非窗口聚集（Group Aggregate）

非窗口聚集就是不用Flink中的窗口开窗，直接把时间作为分区的条件，其实以前在做flink开发的时候都是这样做的。

这里是统计每个用户的点击量统计，并没有加上时间，但是也可以按event time每个小时的点击量，只需要把event time作为group by的条件就可以了。Group Aggregate是在无限流上做统计，每个分区有新数据到来就立即输出一次结果更新，而Window Aggregate只输出一次，所以Group聚集输出的是更新流，而Window聚集输出的是追加流Append Stream。它们的区别可以用一下表格区分下。