aws kinesis提供了一个流窗口实现，可以帮助"分析到达不一致的数据组"，trangger Windows。
这样的窗口实现特别强大，因为它仅在接收到第一个事件(按事件分组定义(并在固定的时间后完成，减少事件的数量，并互相收到的事件数量，相互收到很快收到，最终在单独的窗口中。
kinesis似乎是快速简便的流实施选择的绝佳选择，但是为了查看潜在的未来"锁定"，我们试图了解如何使用KAFKA流启用类似的功能(如果需要(。
Kafka流似乎支持以下窗口功能：
- 翻滚(vs kinesis tunpling(
- 跳跃(vs no Kinesis实施(
- 滑动(VS Kinesis滑动(
- 会议(VS？(
基于我们现有的研究会话Windows 可能是 stagger 的最接近选择。但是，我们注意到的是，即使在该会话之后到达延迟事件，也可以"更新"会话窗口，否则将被视为"过期/发射"，并且直到将来的"流时间"事件之前，可能不会发出会话记录了吗？
因此，我很想问什么/是否在卡夫卡(Kafka(可能是最接近的错窗口的实现，以及什么潜在的" gotchas"很重要。
会话窗口可能有些相似，但是，会话窗口没有固定的大小。窗口边界由"差距"参数确定。以亚马逊文档为例，前两个事件(我们称它们为a和b(相距10秒，第二和第三(c(35秒以及第三和第四(d(10秒。如果指定10秒钟的间隙，则将获得两个与翻滚且与交错窗户不同的a，b和c，d的窗口。如果您指定差距，则如果35秒，则获得一个带有所有4个事件的窗口。
根据您的用例，它可能仍使用Session Windows。
我们已经注意到的是，即使在该会话之后，会话窗口仍可以"更新"，否则将被视为"过期/发射"，
是的，这是正确处理顺序记录所必需的。我不确定Kinesis在活动时间的支持是什么 - 似乎他们翻滚的窗户与Rowtime保持一致(这是墙上的时间？(。但是，使用suppress()，您可以每次会话完全获得一个结果(通过交易某些处理延迟(。查看此博客文章以获取更多详细信息：https：//www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers
，并且在记录"流时间"事件之前可能不会发出会话？
是正确的。但这只有在根本没有新数据到达的情况下才会发生，对于具有连续数据流的流处理应用程序，情况并非如此。
您还可以做什么，以实现自己想要的逻辑，并使用窗口服务商店使用transform()。使用壁挂时间标点符号，即使没有新的输入数据到达，您也可以确保发射数据。最具挑战性的部分将是处理此案的序列记录。