Flink-sql三个时间的定义

flinksql是不存储数据的，数据依赖自外部存储系统如 mysql，kafka等
因为动态表只是一个逻辑概念，所以Flink并不拥有数据本身。相反，动态表的内容存储在外部系统（例如数据库，键值存储，消息队列）或文件中。

Flink sql时间概念

Time

一共有三种时间类型：Processing Time、Event Time 和 Ingestion Time。

Processing Time 处理时间

proctime：是指事件正在被执行时的当前机器时间。
Processing Time 是最简单的时间概念，不需要流和机器之间的协调。它提供了最佳的性能和最低的延迟。但是，在分布式和异步环境中，Processing Time 不能提供确定性，因为它容易受到记录到达系统（例如从消息队列）的速度，记录在系统内部操作员之间流动的速度的影响，以及中断（计划的或其他方式）。

Event Time 事件时间

event Time 是每个事件在其生产设备 Event producer 上发生的时间。
该时间通常在它们进入 Flink 之前嵌入到记录中，并且可以从每个记录中提取事件时间戳。 （可以想象成它是数据本身的一个属性，它的值保存的是时间）
在 Event Time 中，时间值取决于数据，而不取决于系统时间。 Event Time 程序必须指定如何生成 Event Time 的 Watermark，这是表示 Event Time 进度的机制。

Ingestion Time 摄取时间

Ingestion Time 是事件进入Flink的时间。
在源操作处，每条记录都将源的当前时间作为时间戳记，并且基于时间的操作（例如时间窗口）引用该时间戳记。
Ingestion Time 从概念上讲介于事件时间和处理时间之间

Event Time and Watermarks

在为什么使用事件时间和 Watermark 这个问题上，引用了参考资料三的描述

在进行 window 计算时，使用摄入时间或处理时间的消息都是以系统的墙上时间（wall clocks）为标准，因此事件都是按序到达的。
然而如果使用更为有意义的事件时间则会需要面对乱序事件问题（out-of-order events）和迟到事件问题（late events）。
针对这两个问题，Flink 主要采用了以水位线（watermark）为核心的机制来应对。

通过上面的描述，应该能对 Watermark 要解决的问题有个清晰的了解：解决乱序事件
如果数据源是 kafka 消息数据源，按照事件时间 Event Time 来统计，在理想情况下，消息按照事件顺序依次到达，时间窗口刚好收集的该时间段的事件，但很可惜，由于不可预估的外力阻挠，导致消息延迟，时间窗口内的数据将会少了延迟到达的事件。
所以使用 Watermark 来记录事件进行的进度，用收集到的消息来评估事件进度，判断还有没有事件没有到达，只有 Watermark 越过了时间窗口设定的时间，才认为窗口已经收集好数据
watermark=当前窗口最大时间-延迟时间，如果分布式情况下的话则所有流中最小的那个时间为watermark。
watermark有俩种标记方法：其一是按照时间间隔轮询标记，其二是根据对业务的理解打点标记。