首先，我是流处理框架的新手。我想对其中一些进行基准测试，所以我从 Flink 开始。
对于我的用例，我需要将窗口 t 中的事件与窗口 t-1 中的事件进行比较，两者都大小为 15 分钟，然后进行一些聚合。
这是我用例的简化版本：
我们将分析的事件视为形式的元组。 在窗口 1 中有：(A，1)、(B，2)、(C，3)，在窗口 2 中有：(D，6) 和 (B，7)。 然后，我需要将当前窗口中的事件与上一个窗口中的事件进行比较，并保留验证以下条件的事件：Win2(K) - Win1(K)> 5。因此，在前面的例子中，我们得到 (B，5)。(如果有 2 个具有相同键的事件，我需要将它们相加。
我真的不知道如何将两个窗口都保存在内存中。我正在考虑制作一个 15 分钟的翻转窗口(窗口 t)和一个滑动 15 分钟的 30 分钟滑动窗口，并对它们进行减号运算以计算窗口 t-1。
这是一个好的解决方案还是有更好的方法？
您提出的 30 分钟滑动窗口的替代方案是使用ProcessFunction.这是 Apache Flink 自 1.2 版以来提供的低级操作，它结合了状态、每个元素处理和计时器。对于密钥流，状态和计时器会根据每个密钥自动限定范围。以下是其工作原理的概述：
状态：
存储最新的值和时间戳(隐式地，这将针对每个键)
当每个元素到达时：
1. 如果状态(对于此键)包含前一个元素并且差值大于 5，则发出适当的
内容 2. 更新存储的值和时间戳
3. 将计时器设置为在 16 分钟后触发
当计时器触发时：
如果存储状态> 15 分钟前，请清除它
如果密钥空间很小，您可能会决定不打扰计时器 - 它们在那里，这样您就不会保留与陈旧密钥相关的潜在无限存储量。
有关详细信息，请参阅有关进程函数和使用状态的文档。
在这个提案中，我忽略了你所说的具有相同键的多个元素，但为此进行调整应该不难。(我还假设，当数据到达管道的这一部分时，它是按顺序排列的(wrt 到时间)，至少在每个键的基础上。
我并不是说ProcessFunction比你的30分钟滑动窗口提案更简单，但它可能更灵活/适应性更强。另一种更简单的方法是使用 Flink 的复杂事件处理库。在 Flink 1.3 中，我认为可以使用 CEP 表达您正在做的事情，但请注意，版本 1.3 还要几周才会发布。您可以在此处找到 1.3 的文档。