Flink事件时间处理和水印

最近找到这个对事件时间处理和水印说的比较好的文章，所以转载一下，供大家分享，原文连接：https://blog.csdn.net/a6822342/article/details/78064815     http://vishnuviswanath.com/flink_eventtime.html
本文用途纯粹是为了分享，如若有侵权，请与我联系~

下面是原文：
如果您正在构建实时流媒体应用程序，则事件时间处理是您必须迟早使用的功能之一。由于在大多数现实世界的用例中，消息到达无序，应该有一些方法，您建立的系统了解消息可能迟到并且相应地处理的事实。在这篇博文中，我们将看到为什么我们需要事件时间处理，以及我们如何在ApacheFlink中启用它。

EventTime是事件在现实世界中发生的时间，ProcessingTime是Flink系统处理该事件的时间。要了解事件时间处理的重要性，我们首先要建立一个基于处理时间的系统，看看它的缺点。

我们将创建一个大小为10秒的SlidingWindow，每5秒滑动一次，在窗口结束时，系统将发出在此期间收到的消息数。一旦了解EventTime处理如何与SlidingWindow相关的工作，那么了解如何在TumblingWindow中工作也不难。所以让我们开始吧。
#基于处理时间的系统
对于这个例子，我们期望消息具有格式值，timestamp，其中value是消息，timestamp是在源生成此消息的时间。由于我们正在构建基于处理时间的系统，因此以下代码忽略了时间戳部分。

了解消息应包含生成时间的信息是一个重要的方面。Flink或任何其他系统不是一个魔术盒，可以以某种方式自己形成这个。稍后我们将看到，事件时间处理提取此时间戳信息以处理较晚的消息。

val text = senv.socketTextStream("localhost", 9999)
val counts = text.map {(m: String) => (m.split(",")(0), 1) }
    .keyBy(0)
    .timeWindow(Time.seconds(10), Time.seconds(5))
    .sum(1)
counts.print
senv.execute("ProcessingTime processing example")

##情况1：消息到达不间断
假设源分别在时间13秒，第13秒和第16秒产生类型a的三个消息。（小时和分钟不重要，因为窗口大小只有10秒）。

这些消息将落入Windows中，如下所示。在第13秒产生的前两个消息将落入窗口1 [5s-15s]和window2 [10s-20s]，第16个时间生成的第三个消息将落入window2 [ 10s-20s]和window3 [15s-25s] ]。每个窗口发出的最终计数分别为（a，2），（a，3）和（a，1）。

该输出可以被认为是预期的行为。现在我们将看看当一个消息到达系统的时候会发生什么。
##情况2：消息到达延迟
现在假设其中一条消息（在第13秒生成）到达延迟6秒（第19秒），可能是由于某些网络拥塞。你能猜测这个消息会落入哪个窗口？

延迟的消息落入窗口2和3，因为19在10-20和15-25之间。在window2中计算没有任何问题（因为消息应该落入该窗口），但是它影响了window1和window3的结果。我们现在将尝试使用EventTime处理来解决这个问题。
##基于EventTime的系统
要启用EventTime处理，我们需要一个时间戳提取器，从消息中提取事件时间信息。请记住，消息是格式值，时间戳。该extractTimestamp方法获取时间戳部分并将其作为一个长期。现在忽略getCurrentWatermark方法，我们稍后再回来。

class TimestampExtractor extends AssignerWithPeriodicWatermarks[String] with Serializable {
  override def extractTimestamp(e: String, prevElementTimestamp: Long) = {
    e.split(",")(1).toLong 
  }
  override def getCurrentWatermark(): Watermark = { 
      new Watermark(System.currentTimeMillis)
  }
}

我们现在需要设置这个时间戳提取器，并将TimeCharactersistic设置为EventTime。其余的代码与ProcessingTime的情况保持一致。

senv.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
val text = senv.socketTextStream("localhost", 9999)
                .assignTimestampsAndWatermarks(new TimestampExtractor) 
val counts = text.map {(m: String) => (m.split(",")(0), 1) }
      .keyBy(0)
      .timeWindow(Time.seconds(10), Time.seconds(5))
      .sum(1)
counts.print
senv.execute("EventTime processing example")

运行上述代码的结果如下图所示。

结果看起来更好，窗口2和3现在发出正确的结果，但是window1仍然是错误的。Flink没有将延迟的消息分配给窗口3，因为它现在检查了消息的事件时间，并且理解它不在该窗口中。但是为什么没有将消息分配给窗口1？原因是在延迟的信息到达系统时（第19秒），窗口1的评估已经完成了（第15秒）。现在让我们尝试通过使用水印来解决这个问题。

ps:请注意，在窗口2中，延迟的消息仍然位于第19秒，而不是第13秒（事件时间）。该图中的描述是故意表示窗口中的消息不会根据事件时间进行排序。（这可能会在将来改变）
#水印
水印是一个非常重要和有趣的想法，我将尽力给您一个简短的概述。如果您有兴趣了解更多信息，您可以从Google 观看这个令人敬畏的演讲，还可以从dataArtisans那里阅读此博客。水印本质上是一个时间戳。当Flink中的运算符接收到水印时，它明白（假设）它不会看到比该时间戳更早的消息。
（ 原文：A Watermark is essentially a timestamp. When an Operator in Flink receives a watermark, it understands(assumes) that it is not going to see any message older than that timestamp.我这里理解是翻译为更早的信息或者更晚的信息都可以，因为从时间上来说，1990年比1994年要老，但是1990年比1994年也是可以说是早的，那么就是它看不到更早/老的信息）
因此，在“EventTime”中，水印也可以被认为是一种告诉Flink它有多远的一种方式。

为了这个例子的目的，把它看作是一种告诉Flink一个消息延迟多少的方式。在最后一次尝试中，我们将水印设置为当前系统时间。因此，不要指望任何延迟的消息。我们现在将水印设置为当前时间-5秒，这告诉Flink希望消息最多有5s的延迟，这是因为每个窗口仅在水印通过时被评估。由于我们的水印是当前时间-5秒，所以第一个窗口[5s-15s]将仅在第20秒被评估。类似地，窗口[10s-20s]将在第25秒进行评估，依此类推。

override def getCurrentWatermark(): Watermark = { 
      new Watermark(System.currentTimeMillis - 5000)
  }

通常最好保持接收到的最大时间戳，并创建具有最大预期延迟的水印，而不是从当前系统时间减去。
进行上述更改后运行代码的结果是：

最后我们得到了正确的结果，所有这三个窗口现在都按照预期的方式发射计数，这是（a，2），（a，3）和（a，1）。

更新：我们也可以使用AllowedLateness功能设置消息的最大允许时间来解决这个问题。

结论:
实时流处理系统的重要性日益增长，必须处理延迟的消息是您构建的任何此类系统的一部分。在这篇博文中，我们看到到达的消息迟到会影响系统的结果，以及如何使用ApacheFlink的事件时间处理功能来解决它​​们。谢谢你的阅读！