Apache Flink 漫谈系列 - 时间

Apache Flink 为什么需要时间

Apache Flink 在进行Streaming计算时为什么需要时间？谈系回答这个问题我们先看看Streaming和Batch的一个明显区别，即 从数据集的谈系角度看，Streaming是谈系一个Unbounded的数据集，Batch是谈系一个Bounded的数据集。那么我们如何对一个UnBounded的谈系数据集上面进行计算呢？我们总不能等数据都流完在计算结果吧？当然不能，因为流是谈系UnBounded的，永远没有结束。谈系那怎么办？谈系业界一个通用的解决手段就是Window机制。将Streaming的谈系数据看做是一系列的events，每一个event都是谈系一条Streaming数据记录，都有自己产生的谈系时间，也有在Streaming的谈系算子处理的时间，那么Window就可以根据event产生时间或者event被处理的谈系时间进行分组。所以 Time 是谈系Steaming计算必不可少的服务器租用数据属性。

在大多数Streaming处理场景中，谈系Event的顺序很重要，并且通常Event到达数据处理算子的顺序与这些Event在现实世界中实际发生的时间不同。那么记录Event在设备中产生的时间将为在Apache Flink中如实的按照Event的产生时间的顺序进行数据处理提供了机会。

时间类型

如上图所示按照Event的产生时间、进入Apache Flink系统时间和被处理的时间三个时间点划分，在Blink系统中同一个时间或者说是数据流上的数据可以有的时间属性有三种：

Event Time 是每个Event在其生产设备上发生的时间。这段时间通常嵌入记录中，然后进入Apache Flink，并且可以从记录中提取事件时间戳。

Event Time即使在无序事件，延迟事件或从备份或持久性日志中重放数据时，也能提供正确的结果。在Streaming数据处理期间，时间的进度取决于数据，而不是企商汇挂在任何系统时钟上。后续章节要介绍的Watermark就是基于Event Time产生的，Apache Flink系统正是利用Event Time和Watermark机制处理数据乱序问题的(后续章节会详细介绍).

Processing Time 是指执行相应操作的机器的系统时间。

当Streaming计算基于Processing Time时候，所有基于时间的操作（如Time Window）将使用运行相应算子的机器的系统时钟。

Processing Time是最简单的时间概念，它提供了最佳的性能和最低的延迟。然而，在分布式和异步环境中，Processing Time并不能提供确定性，因为它容易受到Event到达系统的速度（例如来自消息队列）以及记录在Apache Flink系统内部的处理先后顺序的影响.

Ingestion time是事件进入Apache Flink的时间。在Source算子处产生，每个记录都将源的服务器托管当前时间作为时间戳记，而基于时间的算子（如Time Window）会引用该时间戳记。

Ingestion Time在概念上位于Event Time和Processing Time之间。

Ingestion Time与Processing Time相比，它的成本稍高一些，但可提供更可预测的结果：由于摄取时间使用稳定的时间戳(在源处分配一次),不受系统内部处理Event的先后顺序和数据传输的延时所影响.

Ingestion Time与Event Time相比，Ingestion Time方式无法处理任何乱序事件或迟后数据，Ingestion Time 在Apache Flink内部机制上与Event Time非常相似，具有自动时间戳分配和自动水印生成功能。

目前Apache Flink SQL 层面向用户开发的时间类型是 Event Time和Processing Time.

小结

本篇介绍了Apache Flink的内部的时间概念，在Apache Flink内部有Event Time , Processing Time和Ingestion time三种时间类型，目前向用户开放的是Event Time和Processing Time 两种。时间在Streaming计算中至关重要，时间是数据分组的主要依据，时间也是Streaming计算中处理数据延时和数据乱序的核心元素。

作者介绍

孙金城，51CTO社区编辑，Apache Flink PMC 成员，Apache Beam Committer，Apache IoTDB PMC 成员，ALC Beijing 成员，Apache ShenYu 导师，Apache 软件基金会成员。关注技术领域流计算和时序数据存储。

最新评论