aws kinesis提供了一个流窗口实现，帮助“分析到达不一致时间的数据组”，错开窗口。
这样的窗口实现特别强大，因为它确保窗口仅在接收到第一个事件（由事件分组定义）时启动，并在一个固定的时间之后完成，从而减少了事件的数量，这些事件是在一个事件之后很快接收到的，最终出现在不同的窗口中。
对于快速简单的流实现选择，kinesis似乎是一个很好的选择，但为了回顾未来潜在的“锁定”，我们正在尝试了解如何使用kafka流重新创建类似的功能（如果需要）。
kafka streams似乎支持以下窗口功能：
翻滚（vs动觉翻滚）
跳跃（与无运动实现相比）
滑动（vs运动滑动）
会话（vs？）
根据我们现有的研究会议窗口可能是最接近的选择错开。但是，我们注意到，如果延迟事件到达，即使在该会话之后，会话窗口仍然可以“更新”，否则将被视为“过期/已发出”，并且在记录未来的“流时间”事件之前，会话可能不会发出？
因此，我想问什么/如果交错窗口的最接近的实现可能是在Kafka和什么潜在的“陷阱”是重要的注意。
1条答案
按热度按时间hrysbysz1#
会话窗口可能有些类似，但是会话窗口没有固定的大小。窗口边界由“间隙”参数确定。以amazon文档为例，前两个事件（我们称它们为a和b）相隔10秒，第二个和第三个（c）相隔35秒，第三个和第四个（d）相隔10秒。如果你指定一个10秒的间隔，你会得到两个不同于翻滚和错开窗口的a，b和c，d窗口。如果指定间隔为35秒，则得到一个包含所有4个事件的窗口。
根据您的用例，它可能仍然可以使用会话窗口。
但是，我们注意到，如果延迟事件在会话之后到达，会话窗口仍然可以“更新”，否则会被视为“过期/已发出”，
是的，这是正确处理故障记录所必需的。我不确定动觉中对活动时间的支持是什么——它们的滚动窗口似乎与行时对齐（这是挂钟时间吗？）。但是，使用
suppress()，则每个会话只能得到一个结果（通过折衷一些处理延迟）。查看此博客文章了解更多详细信息：https://www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers而且在未来的“流时间”事件被记录之前会话可能不会被发出？
没错。但这种情况只会在没有新数据到达的情况下发生，对于具有连续数据流的流处理应用程序来说，情况就不应该是这样了。
你还可以做什么，实现你自己想要的逻辑，使用
transform()有一个窗口状态存储。使用挂钟时间标点，您还可以确保即使没有新的输入数据到达，也会发出数据。最具挑战性的部分将是处理本案的无序记录。