我正在阅读https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/event_timestamp_extractors.html#fixed-延迟量,看起来是在说,如果t_eventime < t_watermark
(小于(,则事件被确定为延迟。
事件时间等于水印的时间如何?如果是t_eventime = t_waterwark
,那么此事件是否未延迟?
我以前一直认为,如果t_eventime<=
t_watermark,那么事件就确定为晚。
你能给我看看决定发生的代码吗,谢谢。
事实上,在这种情况下,确定事件是否延迟的代码似乎是使用<=
比较的,因此,如果事件的时间戳+允许的延迟在水印之前或等于水印,即如果其延迟为>=
0:,则视为事件延迟
protected boolean isElementLate(StreamRecord<IN> element) {
return (windowAssigner.isEventTime())
&& (element.getTimestamp() + allowedLateness
<= internalTimerService.currentWatermark());
}
现在为了完整起见,请注意,您所指的策略的水印本身的值被计算为有史以来最新的时间戳,减去"0";"无序";,减去1。
public void onPeriodicEmit(WatermarkOutput output) {
output.emitWatermark(new Watermark(maxTimestamp - outOfOrdernessMillis - 1));
}
这意味着,在上面的第一个片段中,用于比较的实际延迟比直觉可能告诉我们的要多1毫秒,s.t.lateness > 0
实际上可能是我们人类需要阅读的内容,以了解发生了什么。
现在,这些参数是对我们认为我们的数据在现实世界中可能有多无序的估计,可能是由于网络竞争条件或不对齐的时钟等原因,而我们在进行估计时通常比1 ms
精确得多。因此,这一切应该没有那么重要:希望在我们的数据中这种情况很少发生,尽管由于数据本身的原因,发生的次数通常有点随机。