【问题标题】：Sliding processing time window computes inconsistent results滑动处理时间窗口计算不一致的结果
【发布时间】：2016-12-14 13:10:41
【问题描述】：
在 Flink 中，我正在使用 readTextFile 读取文件并应用 60 毫秒的 SlidingProcessingTimeWindows.of(Time.milliseconds(60), Time.milliseconds(60)) 和 60 毫秒的幻灯片。在窗口流上，我正在计算元组第二个字段的平均值。我的文本文件包含 1100 行，每行都是元组（字符串，整数）。我已将并行度设置为 1，并将消息键入元组的第一个字段。
当我运行代码时，每次都会得到不同的答案。我的意思是，有时它会读取整个文件，有时它会先读取文件的某些行。它与滑动量的窗口大小有关系吗？如何找出这种关系，以便我可以决定窗口的大小和滑动量？
【问题讨论】：
-
在处理时间方面，您不能期望得到一致、可重复的结果。在您的情况下，这只是在 60 毫秒内可以处理多少文件的问题，这将取决于系统负载等。有时它能够处理整个文件，有时它不能；这很正常。查看data-artisans.com/… 了解更多信息。
标签：
apache-flink
flink-streaming
【解决方案1】：
AlpineGizmo 评论中的答案是正确的。我将在此处添加更多详细信息。
Flink 将时间窗口对齐到 epoch 的开始 (1970-01-01-00:00:00)。这意味着具有 1 小时窗口的窗口运算符在每个新小时开始一个新窗口（即，00:00、01:00、02:00，...）而不是第一个到达的记录。
处理时间窗口根据系统的当前时间进行评估。
正如上面评论中所说，这意味着可以处理的数据量取决于操作员运行的机器的处理资源（硬件、CPU/IO 负载……）。因此，处理时间窗口不能产生可靠和一致的结果。
在你的情况下，两种描述的效果都可能导致不同工作的结果不一致。根据您开始作业的时间，数据将被分配到不同的窗口（如果第一条记录在前 60 毫秒窗口关闭之前到达，则只有该元素会在窗口中）。根据机器的 IO 负载，访问和读取文件可能需要更多或更少的时间。
如果你想得到一致的结果，你需要使用事件时间。在这种情况下，记录是根据编码在数据中的时间进行处理的，即结果仅取决于数据，而不取决于外部影响，例如作业的开始时间或处理机器的负载。