AWS Kinesis提供了流窗口实施，可帮助“分析不一致时间到达的数据组”，stagger windows。
这样的窗口实现特别强大，因为它确保仅在接收到第一个事件（由事件分组定义）时才启动窗口，并在固定时间后完成，从而减少了紧接彼此接收的事件数量，最终出现在单独的窗口中。
Kinesis似乎是快速简便地实现流选择的绝佳选择，但为了回顾潜在的未来“锁定”，我们试图了解如何在必要时使用Kafka流重新创建类似的功能。
Kafka streams似乎支持以下窗口功能：
根据我们现有的研究，会话窗口可能是最接近 stagger 的选项。但是，我们注意到，即使延迟的事件到来，会话窗口仍可以被“更新”，否则该会话将被视为“过期/已发射”，并且会话可能直到将来的“流时间”事件才发出被记录？
因此，我想问一个问题：错开窗口的最接近实现是否在Kafka中，以及应该注意哪些潜在的“陷阱”。
答案 0 :(得分：2)
会话窗口可能有些相似，但是会话窗口没有固定的大小。窗口边界由“ gap”参数确定。以Amazon文档为例，前两个事件（分别称为A和B）相距10秒，第二个和第三个（C）相距35秒，第三个和第四个（D）相距10秒。如果将间隔指定为10秒，则将获得两个窗口A，B和C，D，这两个窗口分别不同于翻滚窗口和交错窗口。如果您在35秒内指定间隔，则将获得一个包含所有4个事件的窗口。
根据您的用例，它可能仍可以在会话窗口中使用。
但是我们注意到，即使迟到的事件到来，会话窗口仍可以“更新”，否则该会话将被视为“过期/发出”，
是的，这是正确处理乱序记录所必需的。我不确定Kinesis对事件时间的支持是什么-似乎它们的滚动窗口与ROWTIME（这是挂钟时间？）对齐。但是，使用separate_rows(all_faults,"Data",sep = ",")
，您可以在每个会话中仅获得一个结果（通过权衡一些处理延迟）。请查看此博客文章以了解更多详细信息：https://www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers
还有在记录将来的“流时间”事件之前可能不会发出会话吗？
是的。但是，只有在根本没有新数据到达的情况下，才会发生这种情况，对于具有连续数据流的流处理应用程序，情况就不会如此。
使用suppress()和窗口状态存储来实现自己想要的逻辑，您还可以做些什么。使用壁钟时间标点符号，即使没有新的输入数据到达，也可以确保发送数据。最具挑战性的部分将是处理此案的乱序记录。