问数据流滑动窗口与带有触发器的全球窗口？

EN

两个答案1-滑动窗口和2-全局窗口是不正确的

滑动窗口是不正确的，因为假设每个用户都有一个键，即使他们仍然在浏览，也会在他们第一次开始浏览30分钟后发送一条消息。

全局Windows是不正确的，因为-它将导致每30分钟发送一次消息给所有用户，而不管他们在当前会话的何处

在这种情况下，即使是固定的Windows也是不正确的，因为假设每个用户有一个键，每30分钟就会发送一条消息

正确的答案将是-使用一个间隔时间为30分钟的会话窗口()--这是正确的，因为它将在该用户不活动30分钟后发送消息给每个用户。

我认为从您所描述的情况来看，滑动窗口是正确的方法，而且我认为您不能用trigger+delay解决这个问题。如果从业务逻辑的角度来看，事件时间滑动窗口是有意义的，那么首先尝试使用它，这就是它的目的。

我的理解是，虽然您可以使用触发器来产生早期的结果，但不能保证在特定的(服务器/处理)时间或具有确切的元素数(到目前为止窗口接收到)时触发。触发器条件允许/取消阻止运行程序发出窗口内容，但它并不强制它这样做。

在事件时间的情况下，这是有意义的，因为事件何时到达或触发器何时触发并不重要，因为如果元素在窗口内有时间戳，那么无论何时到达，它都将被分配给正确的窗口。当触发器为窗口触发时，如果它已经到达，元素将被保证在该窗口中。

有了处理时间，你就不能这么做。如果事件到达晚了，它将在那个时候被记帐，并将在下一次触发的时候发出，基本上。而且，由于触发器不能保证触发的确切时刻，因此可能会得到属于意外发出的窗格的意外数据。一般来说，获得早期结果是有用的，但我不确定您是否可以在此基础上对窗口进行推理。

此外，触发延迟只会增加火灾延迟(例如，如果它应该在12点5分开火，而不是在12点05分开火)，但它不允许您可靠地错开多次触发触发，以便在特定的时间间隔内触发。

您可以在这里查看用于触发器的design：https://s.apache.org/beam-triggers，可能的延迟文档也可能与此相关：https://s.apache.org/beam-lateness

如果您感兴趣，可以在这里找到其他文档：https://beam.apache.org/contribute/design-documents/。

更新：

Rui指出，这个用例可能更复杂，而且很难通过滑动窗口解决。也许值得研究一下会话窗口或keys+state+timers上的手动逻辑

我发现Apache的state1和timer2文档，它们应该能够处理这个特定的用例，而无需在全局窗口中使用处理时间触发器。

假设传入的数据是用户操作的事件，每个事件(动作)都可以由user_id键控。

状态和计时器所具有的很好的属性是基于每个键和窗口的。因此，您可以为每个user_id积累状态，在这种情况下，状态是cart中的金额。当购物车中的数量超过50美元时，可以在第一时间设置定时器，当用户在处理时间的30分钟内仍然有购物动作时，可以重置计时器。

假设事务完成也是一个user_id键控事件。当看到事务完成事件时，定时器可以是deleted3。

最新情况：

这种思想完全是在处理时间域上的，因此根据系统中的延迟问题，会产生虚假的告警信息。因此，问题是如何将这一思想改进为事件时域，从而减少虚警。一种可能是基于事件时间的timer4。我不清楚基于事件时间的计时器在这一刻意味着什么。

1

2

3

4