大数据之Flink(6) | 时间语义和Wartermark

分手后的思念是犯贱 2022-12-17 00:30 99阅读 0赞

### 时间语义和Wartermark ###

*  一.Flink中的时间语义
 *  二.EventTime的引入
 *  三.Watermark
 *   *  基本概念
     *  Watermark的引入
 *  四.EvnetTime在window中的使用
 *   *  滚动窗口（TumblingEventTimeWindows）
     *  滑动窗口（SlidingEventTimeWindows）
     *  会话窗口（EventTimeSessionWindows）
 *  五.总结

# 一.Flink中的时间语义 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center]  
**Event Time**：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink通过时间戳分配器访问事件时间戳。  
**Ingestion Time**：是数据进入Flink的时间。  
**Processing Time**：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是Processing Time。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 1]  
例如，一条日志进入Flink的时间为2017-11-12 10:00:00.123，到达Window的系统时间为2017-11-12 10:00:01.234，日志的内容如下：

2017-11-02 18:37:15.624 INFO Fail over to rm2

对于业务来说，要统计1min内的故障日志个数，哪个时间是最有意义的？—— eventTime，因为我们要根据日志的生成时间进行统计。

# 二.EventTime的引入 #

**在Flink的流式处理中，绝大部分的业务都会使用eventTime**，一般只在eventTime无法使用时，才会被迫使用ProcessingTime或者IngestionTime。  
如果要使用EventTime，那么需要引入EventTime的时间属性，引入方式如下所示：

val env = StreamExecutionEnvironment.getExecutionEnvironment
    // 从调用时刻开始给env创建的每一个stream追加时间特征
    env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)

# 三.Watermark #

## 基本概念 ##

我们知道，流处理从事件产生，到流经source，再到operator，中间是有一个过程和时间的，虽然大部分情况下，流到operator的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、分布式等原因，导致乱序的产生，所谓乱序，就是指Flink接收到的事件的先后顺序不是严格按照事件的Event Time顺序排列的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 2]  
那么此时出现一个问题，一旦出现乱序，如果只根据eventTime决定window的运行，我们不能明确数据是否全部到位，但又不能无限期的等下去，此时必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了，这个特别的机制，就是Watermark。

*  Watermark是一种衡量Event Time进展的机制。
 *  Watermark是用于处理乱序事件的，而正确的处理乱序事件，通常用Watermark机制结合window来实现。
 *  数据流中的Watermark用于表示timestamp小于Watermark的数据，都已经到达了，因此，window的执行也是由Watermark触发的。
 *  Watermark可以理解成一个延迟触发机制，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的maxEventTime，然后认定eventTime小于maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。  
    **这里可以理解为5秒钟一个窗口函数**  
    有序流的Watermarker如下图所示：（Watermark设置为0）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 3]  
    乱序流的Watermarker如下图所示：（Watermark设置为2）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 4]
 *  当Flink接收到数据时，会按照一定的规则去生成Watermark，这条Watermark就等于当前所有到达数据中的maxEventTime - 延迟时长，也就是说，Watermark是基于数据携带的时间戳生成的，一旦Watermark比当前未触发的窗口的停止时间要晚，那么就会触发相应窗口的执行。由于event time是由数据携带的，因此，如果运行过程中无法获取新的数据，那么没有被触发的窗口将永远都不被触发。
 *  上图中，我们设置的允许最大延迟到达时间为2s，所以时间戳为7s的事件对应的Watermark是5s，时间戳为12s的事件的Watermark是10s，如果我们的窗口1是1s5s，窗口2是6s10s，那么时间戳为7s的事件到达时的Watermarker恰好触发窗口1，时间戳为12s的事件到达时的Watermark恰好触发窗口2。
 *  Watermark 就是触发前一窗口的“关窗时间”，一旦触发关门那么以当前时刻为准在窗口范围内的所有所有数据都会收入窗中。
 *  只要没有达到水位那么不管现实中的时间推进了多久都不会触发关窗。

## Watermark的引入 ##

watermark的引入很简单，对于乱序数据，最常见的引用方式如下：

.assignTimestampsAndWatermarks( new BoundedOutOfOrdernessTimestampExtractor[SensorReading](Time.milliseconds(1000)) { 
      override def extractTimestamp(element: SensorReading): Long = { 
        element.timestamp * 1000
      }
    } )

对于升序时间，最常见的引用方法如下

.assignAscendingTimestamps(_.timestamp * 1000L)

Event Time的使用一定要**指定数据源中的时间戳**。否则程序无法知道事件的事件时间是什么(数据源里的数据没有时间戳的话，就只能使用Processing Time了)。  
我们看到上面的例子中创建了一个看起来有点复杂的类，这个类实现的其实就是分配时间戳的接口。Flink暴露了TimestampAssigner接口供我们实现，使我们可以自定义如何从事件数据中抽取时间戳。

val env = StreamExecutionEnvironment.getExecutionEnvironment
    
    // 从调用时刻开始给env创建的每一个stream追加时间特性
    env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
    
    val readings: DataStream[SensorReading] = env
    .addSource(new SensorSource)
    .assignTimestampsAndWatermarks(new MyAssigner())

MyAssigner有两种类型

*  AssignerWithPeriodicWatermarks
 *  AssignerWithPunctuatedWatermarks  
    以上两个接口都继承自TimestampAssigner。  
    **Assigner with periodic watermarks**  
    周期性的生成watermark：系统会周期性的将watermark插入到流中(水位线也是一种特殊的事件!)。默认周期是200毫秒。可以使用ExecutionConfig.setAutoWatermarkInterval()方法进行设置。

val env = StreamExecutionEnvironment.getExecutionEnvironment
    env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
    
    // 每隔5秒产生一个watermark
    env.getConfig.setAutoWatermarkInterval(5000)

产生watermark的逻辑：每隔5秒钟，Flink会调用AssignerWithPeriodicWatermarks的getCurrentWatermark()方法。如果方法返回一个时间戳大于之前水位的时间戳，新的watermark会被插入到流中。这个检查保证了水位线是单调递增的。如果方法返回的时间戳小于等于之前水位的时间戳，则不会产生新的watermark。  
例子，自定义一个周期性的时间戳抽取：

class PeriodicAssigner extends AssignerWithPeriodicWatermarks[SensorReading] { 
    val bound: Long = 60 * 1000 // 延时为1分钟
    var maxTs: Long = Long.MinValue // 观察到的最大时间戳
    
    override def getCurrentWatermark: Watermark = { 
    new Watermark(maxTs - bound)
    }
    
    override def extractTimestamp(r: SensorReading, previousTS: Long) = { 
    maxTs = maxTs.max(r.timestamp)
    r.timestamp
    }
    }

一种简单的特殊情况是，如果我们事先得知数据流的时间戳是单调递增的，也就是说没有乱序，那我们可以使用assignAscendingTimestamps，这个方法会直接使用数据的时间戳生成watermark。

.assignAscendingTimestamps(_.timestamp * 1000L)

而对于乱序数据流，如果我们能大致估算出数据流中的事件的最大延迟时间，就可以使用如下代码：

val stream: DataStream[SensorReading] = ...
    val withTimestampsAndWatermarks = stream.assignTimestampsAndWatermarks(
    new SensorTimeAssigner
    )
    
    class SensorTimeAssigner extends BoundedOutOfOrdernessTimestampExtractor[SensorReading](Time.seconds(5)) { 
    // 抽取时间戳
    override def extractTimestamp(r: SensorReading): Long = r.timestamp
    }

**Assigner with punctuated watermarks**

class PunctuatedAssigner extends AssignerWithPunctuatedWatermarks[SensorReading] { 
    val bound: Long = 60 * 1000
    
    override def checkAndGetNextWatermark(r: SensorReading, extractedTS: Long): Watermark = { 
    if (r.id == "sensor_1") { 
    new Watermark(extractedTS - bound)
    } else { 
    null
    }
    }
    override def extractTimestamp(r: SensorReading, previousTS: Long): Long = { 
    r.timestamp
    }
    }

# 四.EvnetTime在window中的使用 #

## 滚动窗口（TumblingEventTimeWindows） ##

.window(TumblingProcessingTimeWindows.of(Time.hours(1),Time.hours(-8)))

## 滑动窗口（SlidingEventTimeWindows） ##

.window(SlidingEventTimeWindows.of(Time.seconds(2),Time.milliseconds(500)))

## 会话窗口（EventTimeSessionWindows） ##

.window(EventTimeSessionWindows.withGap(Time.minutes(1)))

# 五.总结 #

window

1.window操作两个主要步骤：
    窗口分配器(.window),窗口函数(reduce,aggregate,apply,process)
    2.window类型
    通过窗口分配器来决定，时间窗口和计数窗口
    按照窗口起止时间(个数)的定义，可以有滚动窗口，滑动窗口，会话窗口
    滑动窗口中，每条数据可以属于多个窗口，属于size/sli的个窗口
    会话窗口，窗口长度不固定，需要指定间隔时间
    3.窗口函数
    窗口函数是基于当前窗口内的数据，是有界数据集的计算，通常只在窗口关闭时输出一次
    增量聚合函数：ReduceFunction，AggregateFunction
    全窗口函数：WindowFunction，ProcessWindowFunction，类似于批处理过程
    4.程序默认的时间语义 是Processing Time

watermark

1.Watermark就是事件事件，代表当前时间的进展
    
    2.Watermark主要用来处理乱序数据，一般就是直接定义一个延迟时间，延迟触发窗口操作
    这里的延迟，指的是当前收到的数据内的时间戳
    
    3.Watermark延迟时间的设置，一般要根据数据的乱序情况来定，通常设置成最大的乱序程度
    如果按照最大乱序程度，那么就能保证所有窗口的数据是正确的
    要权衡正确性和实时性的话，可以不按最大乱序程度，而是给一个相对较小的watermark延迟
    watermark延迟时间，完全是程序自定义的，可以拍脑袋给一个数
    最好的处理方式，是先了解数据的分布情况(抽样，或者根据经验，机器学习算法)
    
    4.关窗操作，必须是时间进展到窗口关闭时间，事件时间语义下就是watermark达到关闭时间
    当前Ts最大时间戳-延迟时间=watermark，如果现在的watermark大于等于窗口结束时间，就关闭窗口
    
    5.watermark代表的含义是，之后就不会再来时间戳比watermark里面的数值小的数据
    如果有不同的上游分区，当前任务会对他们创建各个的分区watermark，当前任务的事件时间就是最小的那个
    
    6.处理乱序数据，Flink有三重保证
    watermark可以设置延迟时间
    window的allowedLateness方法，可以设置窗口允许处理迟到数据的时间
    window的sideOutputLateData方法，可以将迟到的数据写入侧输出流
    
    窗口有两个重要操作：触发计算，清空状态(关闭窗口)

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/8acd66fb87814618801c02613a8cf1f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/85b548470c864a748f3d2262167a6742.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/b5a17335e70b4445960b0572f608b7bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/3e91d12e08c84e91a9b7736217995b7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/1f556336dc1a4bdab87ee1113b7c744d.png