1.时间语义
1.时间语义
image.png
- Event Time：
- 是事件发生的时间。
- 事件时间
- 它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink 通过时间戳分配器访问事件时间戳。
- 是事件发生的时间。
- Ingestion Time：
- 是数据进入 Flink 的时间。
- 涉入时间
- Processing Time：
- 是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是 Processing Time。
- 处理时间
1.1 例子
image.png
- 电影发行时间就是 事件时间
- 我们发现这个电影的时间就是 摄入时间
- 不同的时间语义有不同的应用场合
- 我们往往更关心事件时间（Event Time）
1.2 数据处理系统中的时间语义
- 在计算机系统中，考虑数据处理的“时代变化”是没什么意义的，我们更关心的，显然是数据本身产生的时间。
- 比如我们计算网站的 PV、UV 等指标，要统计每天的访问量。
- 如果某个用户在 23 点 59分 59 秒有一次访问，但我们的任务处理这条数据的时间已经是第二天 0 点 0 分 01 秒了；那么这条数据，是应该算作当天的访问，还是第二天的访问呢？
- 很明显，统计用户行为，****需要考虑行为本身发生的时间，所以我们应该把这条数据统计入当天的访问量。
- 这时我们用到的窗口，就是以事件时间作为划分标准的，跟处理时间无关。
- 所以在实际应用中，事件时间语义会更为常见。
- 一般情况下，业务日志数据中都会记录数据生成的时间戳（timestamp），它就可以作为事件时间的判断基础。
1.3 Event Time、Processing Time、Ingestion Time
- 实际应用中，数据产生的时间和处理的时间可能是完全不同的。
- 很长时间收集起来的数据，处理或许只要一瞬间；
- 也有可能数据量过大、处理能力不足，短时间堆了大量数据处理不完，产生“背压”（back pressure）。
- 通常来说，处理时间是我们计算效率的衡量标准，而事件时间会更符合我们的业务计算逻辑。
- 所以更多时候我们使用事件时间；
- 不过处理时间也不是一无是处。
- 对于处理时间而言，由于没有任何附加考虑，数据一来就直接处理，因此这种方式可以让我们的流处理延迟降到最低，效率达到最高。
- 但是我们前面提到过，在分布式环境中，处理时间其实是不确定的，各个并行任务时钟不统一；
- 而且由于网络延迟，导致数据到达各个算子任务的时间有快有慢，对于窗口操作就可能收集不到正确的数据了，数据处理的顺序也会被打乱。这就会影响到计算结果的正确性。
- 所以处理时间语义，一般用在对实时性要求极高、而对计算准确性要求不太高的场景。
- 而且由于网络延迟，导致数据到达各个算子任务的时间有快有慢，对于窗口操作就可能收集不到正确的数据了，数据处理的顺序也会被打乱。这就会影响到计算结果的正确性。
- 而在事件时间语义下，水位线成为了时钟，可以统一控制时间的进度。
- 这就保证了我们总可以将数据划分到正确的窗口中，比如 8 点 59 分 59 秒产生的数据，无论网络传输的延迟是多少，它永远属于 8 点~9 点的窗口，不会错分。
- 但我们知道数据还可能是乱序的，要想让窗口正确地收集到所有数据，就必须等这些错乱的数据都到齐，这就需要一定的等待时间。
- 所以整体上看，事件时间语义是以一定延迟为代价，换来了处理结果的正确性。
- 由于网络延迟一般只有毫秒级，所以即使是事件时间语义，同样可以完成低延迟实时流处理的任务。
- 另外，除了事件时间和处理时间，Flink 还有一个“摄入时间”（Ingestion Time）的概念，它是指数据进入 Flink 数据流的时间，也就是 Source 算子读入数据的时间。
- 摄入时间相当于是事件时间和处理时间的一个中和，它是把 Source 任务的处理时间，当作了数据的产生时间添加到数据里。这样一来，水位线（watermark）也就基于这个时间直接生成，不需要单独指定了。
- 这种时间语义可以保证比较好的正确性，同时又不会引入太大的延迟。它的具体行为跟事件时间非常像，可以当作特殊的事件时间来处理。
- 在 Flink 中，由于处理时间比较简单，早期版本默认的时间语义是处理时间；而考虑到事件时间在实际应用中更为广泛，从 1.12 版本开始，Flink 已经将事件时间作为了默认的时间语义。
