StreamingSystem (Google 流式团队著)-c1.Streaming101-8
其他章节的内容可以点击作者头像在主页列表找到
Windowing by processing time
如果窗口是基于Processing time的，其实就是缓存数据知道窗口内的数据时间窗口达到后即可。
对于Processing time的窗口计算有一些优越的特质
- 简单：利用Processing time做窗口计算，只需要在固定的时间段打开窗口结束的时候直接将数据产出就可以了
- 判断窗口完整性很方便，不需要过多的关注"late"数据
- 如果想针对来源的数据进行一些推断和了解，利用Processing time是一个比较好的选择，例如对于监控系统。
上述介绍了利用Processing time的好处，简单总结一句就是简单直接。但是也存在着很明显的缺点： 如果要处理的问题是对于eventtime强一来的话，Processing time将很难适用，而且在现实的分布式系统当中，从eventtime角度来看数据都是乱序的。
（下面他介绍了几个例子，我们前面已经有类似的介绍了，如果想看可以往前面的文章看一下，大概就是强调实际生产环境下）
在目前的很多处理场景下，我们虽然很多场景期望用的是Processing time但是实际情况期望使用的是Eventtime，下面将详细介绍eventime的窗口。
Windowing by event time
在我们尝试处理数据的时候，很多时候基于事件时间的窗口是真正需要的。它能更好的反映实际情况，但是在2016年之前，大部分的数据处理系统，缺少对于事件时间窗口的支持。例如Hadoop和Spark 1.x，这一情况目前有所改变，更多的系统，例如Flink，Spark，Storm，Apex，原生的支持了事件时间的窗口。图1-10描述了，将无限的数据源划分为一个小时固定大小的窗口中
上图中能够的黑色箭头，便是将Processing time和event time不同的事件更好的迁移到了event time对应的窗口，如果只是简单的使用Processing time来处理，结果显然是不对。
另外一个event time 更加适用的场景是创建动态大小的窗口，比如session窗口。而且session 窗口不会因为时间的原因被分列。如图1-11
天下没有免费的午餐，强大的语义也是需要付出更多的代价，Event time 窗口有两个明显的缺点，究其原因，主要是很多时候窗口的存在时间要比实际窗口的大小要长很多。
缓存
由于需要存在更长时间，因为需要缓存更多的数据，但是相对而言，缓存所需要的硬件设备，要价格便宜很多。相对于需要强一致存储的数据系统或者其他的基于内存的缓存层，现在讨论的缓存要简单很多，。此外大部分的缓存不需要缓存整个数据，只是魂村一些中间的聚集结果即可。
Completeness（完整性）
通常情况下，没有太好的办法来确定当前窗口的数据已经完全到达了，在实际操作中，我们是如何实现呢？实际上在目前的很多系统中MillWheel，Cloud Dataflow和Flink，利用水印的形式，通过启发规则的方式来估算窗口应该关闭的时间。但是，在某些需要精确结果的情况下（例如订单系统），期望系统提供一种机制来通知进行窗口计算以及随着时间的变化来逼近真实的结果。对于这个事情，是一个值得探讨的话题，将在后文中进行详细介绍。
閱讀更多 北京IT民工 的文章
