Flink原理,实战与性能优化读书笔记(三) 三种时间&水位线机制

第四章

时间概念与Watermark

flink根据时间产生的位置不同，把时间区分为三种时间概念

• 事件生成时间(event Time)
  数据从终端产生，或者从系统中产生的时间
• 事件接入时间(Ingestion Time)
  数据经过中间件传入到flink之后，在dataSource中接入的时候会生成时间接入时间。
• 事件处理时间(Processing Time)
  数据在各个算子实例执行转换操作过程中，算子实例所在系统的时间为数据处理时间。

解决问题：为什么要区分这三种时间？与流式计算有何关系？

事件时间

可以在flink系统中指定事件时间属性或者设定时间提取器来提取事件时间。

所有进入到flink流式系统处理的事件，时间都是在外部系统中产生，然后经过网络进入到flink系统内处理的。所以所有进入到flink系统的事件，时间都是在外部系统中产生，经过网络进入到flink内部进行处理的。在理论情况下，事件时间对应的时间戳一定会早于在flink系统中产生的时间戳，但在实际情况中往往会出现数据记录乱序，延迟到达等问题。
eventTime的意义就在于，能够借助于时间产生时候的时间来还原事件的先后关系。

接入时间

数据进入flink系统的时间。

依赖于source operator所在主机的系统时钟。

Ingestion Time 介于Event Time 和 Process Time之间，相对于Process Time,其生成的代价相对高。后续数据处理Operator所在机器的时钟没有关系，从而不会因为某台机器时钟不同步或网络时延而导致计算结果不准确的问题。

相比于Event Time，Ingestion Time不能处理乱序事件，所以也就不用生成对应的Watermarks。

处理时间

数据在操作算子计算过程中获取到的所在主机时间。用户选择用Processing Time,所有和时间相关的计算算子，例如windows计算，会直接使用其所在主机的系统时间。

processing time定义的目的：flink程序性能比较高，延时也相对比较低，对接入到系统中的数据时间相关计算完全交给算子内部决定。窗口计算依赖的时间都是在具体算子运行的过程中产生，不需要做时间上的对比与协调。

但是processing time不擅长处理数据乱序情况。在分布式系统中，数据本身不乱序，如果每台机器的时间不同步，可能导致数据处理过程中数据乱序的问题。

应用：对时间计算精度要求不高的场景。例如统计某些延时非常高的日志数据。

 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);
//env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
//env.setStreamTimeCharacteristic(TimeCharacteristic.IngestionTime);
       

eventTime和watermark

水位线究竟有什么作用？

通常由于网络等影响࿰