《Streaming Systems》第四章是第二章中窗口概念的引申和扩展。在这一章中,作者首先通过论证了处理时间窗口(processing-time windowing)和事件时间窗口(event-time windowing)的联系和区别,然后进一步探讨了会话窗口(Session Windows)的定义和处理细节,并在结尾给出了定制窗口(custom windowing)的概念,包括非对齐固定窗口(unaligned fixed windows), 基于Key值窗口(per-key fixed windows)和绑定会话窗口(bounded sessions windows)等。
《Streaming Systems》第四章相较于前三个章节更为复杂,倘若不是作者给出了大量的动图,恐怕大部分读者都会晕乎乎的了吧(所以强烈建议这一章观看Safari上的动图或者是Streaming 102)。
在第二章中,作者给出了滑动窗口、滚动窗口和会话窗口的概念。在第四章里,作者通过比较基于触发器的处理时间窗口、基于进入时间的处理时间窗口和事件时间窗口(有代码也有详细论证),得出了处理时间窗口是无法处理事件顺序的结论,也从反面论证了事件时间窗口存在的必要性和重要性。
会话窗口(Session Windows)是作者的最爱。与一般意义的窗口概念不同,会话窗口不使用size和location定义,而是一个动态的、由数据驱动的窗口类型。正是因为这样,会话窗口可以在数据分析领域大放异彩,比如会话窗口可以用来追踪某个特定的用户在某个特定时间段的活动情况。
对于会话窗口,我之前的理解是使用一个会话ID(session ID)来定义某个范围内的窗口,读完此章节后,发现想的太狭窄。作者是通过“a gap of inactivity”来定义会话窗口的范围,以及使用窗口合并策略让会话窗口的概念更为强大。
作者通过抽象出Window assignment和window merging两种策略让开发者可以根据业务情况自定义窗口,使其不仅仅受限于有限的几种窗口,拥有更大的自由度。文中例举有三个案例:非对齐固定窗口(unaligned fixed windows), 基于Key值窗口(per-key fixed windows)和绑定会话窗口(bounded sessions windows)以说明在一些特殊环境下,定制窗口类型是如何做到一般窗口类型所做不到的事情的
至此,书中对The Beam Model各个维度下的讨论就告一段落了,导读也暂时告一段落。接下来,我会花一定的时间去讨论Spark和Flink是如何践行The Beam Model,或者说The Beam Model是如何影响了Spark和Flink的设计和实现的。套用某位知乎大佬的话,那就是The Beam Model
升维了我们的思维模式,降维打击我们的复杂问题