我正在为一家电子商务公司设计一个购物篮放弃系统。系统将根据以下规则向用户发送消息：
我使用Google Cloud Dataflow来处理数据并决定是否发送消息。我在下面有几个选择：
我认为“滑动窗口”可能在这里起作用。但是我的问题是，是否存在一种基于全局窗口的解决方案，该全局窗口具有基于处理时间的触发器和该用例的延迟？ 据我了解基于Apache Beam文档的触发器=> 触发器允许Beam在给定窗口关闭之前发出早期结果。例如，在经过一定时间后或在到达一定数量的元素之后进行发射。 触发器允许通过在事件时间水印通过窗口结束后进行触发来处理后期数据。
因此，就我的用例而言，按照上述触发概念，我不认为可以在为每个用户设置延迟后触发该触发（在上文中已提及-仅在一定数量后才能发出上面提到的元素，但不确定是否可以为1）。你能确认吗？
答案 0 :(得分：1)
我认为滑动窗口是您所描述的正确方法，并且我认为您无法通过触发器+延迟解决此问题。如果从业务逻辑的角度来看事件时间滑动窗口是有意义的，请尝试首先使用它，这就是它的用途。
我的理解是，尽管可以使用触发器来产生早期结果，但不能保证在特定的（服务器/处理）时间或确切数量的元素（到目前为止，对于窗口而言）触发。触发条件允许/取消阻止跑步者发出窗口内容，但并不强制这样做。
在事件时间的情况下这很有意义，因为事件何时到达或触发器何时触发都没有关系，因为如果元素在窗口中具有时间戳，则无论该元素是否分配给正确的窗口当它到达时。并且当触发器为窗口触发时，如果元素已经到达，则将保证该元素位于该窗口中。
处理时间有限，您无法执行此操作。如果事件迟到，则将在该时间进行处理，并且基本上在触发器下次触发时发出。而且由于触发器不能保证触发的确切时间，您可能最终会获得属于意外发出的窗格的意外数据。一般而言，获得早期结果很有用，但是我不确定是否可以基于此来进行窗口化。
此外，触发延迟只会增加触发延迟（例如，如果应该在中午12点触发，则不会在中午12.05触发），但是它不允许您可靠地错开多个触发，以使其触发时间为具体间隔。
您可以在此处查看触发器的设计文档：https://s.apache.org/beam-triggers，并且可能与延迟文档也相关：https://s.apache.org/beam-lateness
如果您有兴趣，可以在这里找到其他文档：https://beam.apache.org/contribute/design-documents/。
更新：
Rui指出，此用例可能更复杂，并且可能无法通过滑动窗口解决。也许值得研究会话窗口或按键+状态+计时器之上的手动逻辑
答案 1 :(得分：1)
我找到状态[1]和计时器[2]的Apache梁，它应该能够在不全球窗口中使用的处理时间触发来处理这个特定使用情况下的文档。
假定传入数据是用户操作的事件，并且每个事件（操作）都可以由user_id键入。
state和timer具有的不错的属性是基于每个键和窗口的。因此，您可以为每个user_id累积状态，在这种情况下，状态为购物车中的金额。可以在购物车中的金额超过$ 50时第一次设置计时器，并且在处理时间30分钟内用户仍然有购物操作时可以重置计时器。
假定事务完成也是user_id键控事件。当看到事务完成事件时，可以删除计时器[3]。
更新：
此想法是在处理时间域完全所以它将具有假警报消息取决于系统迟到问题。因此，问题是如何将该思想改进到事件时域，以减少误报。一种可能性是基于事件时间的计时器[4]。目前尚不清楚基于事件时间的计时器是什么意思。
[1] https://beam.apache.org/blog/2017/02/13/stateful-processing.html
[2] https://docs.google.com/document/d/1zf9TxIOsZf_fz86TGaiAQqdNI5OO7Sc6qFsxZlBAMiA/edit#
答案 2 :(得分：1)
两个答案1-滑动窗口和2-全局窗口都不正确
滑动窗口不正确，因为-假设每个用户只有一个按键，即使他们仍在浏览，消息也会在他们第一次开始浏览30分钟后发送出去
全球Windows不正确，因为-它将导致每30分钟向所有用户发送一条消息，无论他们在当前会话中处于什么位置
在这种情况下，即使固定Windows也将是不正确的，因为假设每个用户只有一个密钥，则每30分钟将发送一条消息
正确的答案是-使用间隔时间为30分钟的会话窗口 这是正确的，因为它将在该用户不活动30分钟后向该用户发送一条消息