前言

本文隶属于专栏《1000个问题搞定大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

在这里插入图片描述

在专栏前面我们已经介绍过
可以通过window窗口来统计每一段时间或者每多少条数据的一些数值统计。

请参考我的这篇博客——一篇文章搞懂 Flink 的 Window

但是也存在另外一个问题,就是如果数据有延迟该如何解决,例如一个窗口定义的是每隔五分钟统计一次,我们应该在上午九点至九点零五分这段时间统计一次数据的结果值,但是由于某一条数据由于网络延迟,数据产生时间是在九点零三分,数据到达我们的flink框架已经是在十点零三分了,这种问题怎么解决?

再例如:
原始日志如下:
日志自带时间

2020-10-10 10:00:01,134 INFO executor.Executor: Finished task in state 0.0

数据进入flink框架时间:
这条数据进入Flink的时间是2020-10-10 20:00:00,102
数据被window窗口处理时间:
到达window处理的时间为2020-10-10 20:00:01,100

Time 三兄弟是什么?

为了解决这个问题,flink在实时处理当中,对数据当中的时间规划为以下三个类型
针对stream数据中的时间,可以分为以下三种
Event Time:事件产生的时间,它通常由事件中的时间戳描述。
Ingestion time:事件进入Flink的时间
Processing Time:事件被处理时当前系统的时间

可以参考我的这篇博客——什么是事件时间和处理时间?

在这里插入图片描述

1、EventTime详解

  1. 事件生成时的时间,在进入Flink之前就已经存在,可以从event的字段中抽取。
  2. 必须指定watermarks(水位线)的生成方式。
  3. 优势:确定性,乱序、延时、或者数据重放等情况,都能给出正确的结果
  4. 弱点:处理无序事件时性能和延迟受到影响

2、IngestTime

  1. 事件进入flink的时间,即在source里获取的当前系统的时间,后续操作统一使用该时间。
  2. 不需要指定watermarks的生成方式(自动生成)
  3. 弱点:不能处理无序事件和延迟数据

3、ProcessingTime

  1. 执行操作的机器的当前系统时间(每个算子都不一样)
  2. 不需要流和机器之间的协调
  3. 优势:最佳的性能和最低的延迟
  4. 弱点:不确定性 ,容易受到各种因素影响(event产生的速度、到达flink的速度、在算子之间传输速度等),压根就不管顺序和延迟

4、三种时间的综合比较

性能: ProcessingTime> IngestTime> EventTime
延迟: ProcessingTime< IngestTime< EventTime
确定性: EventTime> IngestTime> ProcessingTime

5、如何设置time类型

在我们创建StreamExecutionEnvironment的时候可以设置time类型,不设置time类型,默认是processingTime,如果设置time类型为eventTime,那么必须要在我们的source之后明确指定Timestamp Assigner & Watermark Generator

// 设置时间特性
val environment: StreamExecutionEnvironment = StreamExecutionEnvironment.getExecutionEnvironment
// 不设置Time 类型,默认是processingTime。
// 如果使用EventTime则需要在source之后明确指定Timestamp Assigner & Watermark Generator
environment.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime)
上一篇 下一篇