ApacheFlink为什么ApacheFlink需要时间为什么ApacheFlink在进行Streaming计算时需要时间？要回答这个问题，我们先来看一下Streaming和Batch的一个明显区别。从数据集的角度来看，Streaming是Unbounded数据集，Batch是Bounded数据集。那么我们如何在UnBounded数据集上进行计算呢？总不能等数据流出来了再算结果吧？当然不是，因为流是无界的并且永无止境。那么该怎么办？业界常见的解决方案是Window机制。把Streaming数据看成是一系列的事件，每个事件都是一条Streaming数据记录，有自己的产生时间，也有Streaming算子处理的时间，那么Window就可以根据事件产生时间或者事件被处理处理时间被分组。所以Time是Steaming计算必不可少的数据属性。在大多数流处理场景中，事件的顺序很重要，而且事件到达数据处理算子的顺序往往与这些事件在现实世界中实际发生的时间不同。然后在设备中记录Event产生的时间，为ApacheFlink中的数据处理提供一个机会，忠实的按照Event产生时间的顺序进行。如上图所示，时间类型分为三个时间点：事件产生时间、进入ApacheFlink系统时间、处理时间。在Blink系统中，数据可以同时或在数据流上具有三种时间属性。:EventTimeIngestionTimeProcessingTimeEventTimeEventTime是每个事件在其生产设备上发生的时间。这个时间通常是嵌入在记录中，然后进入ApacheFlink，可以从记录中提取事件时间戳。EventTime提供正确的结果，即使是乱序事件、延迟事件，或者从备份或持久日志中重放数据时也是如此。在流式数据处理过程中，时间的进展取决于数据，而不是任何系统时钟。后续章节要介绍的Watermark是根据EventTime生成的。ApacheFlink系统使用EventTime和Watermark机制来处理数据乱序问题（后续章节会详细介绍）。ProcessingTimeProcessingTime是指机器的系统执行相应操作的时间。当Streaming计算基于ProcessingTime时，所有基于时间的操作（例如TimeWindow）将使用运行相应算子的机器的系统时钟。ProcessingTime是最简单的时间概念，它提供最好的性能和最低的延迟。但是，在分布式和异步环境中，ProcessingTime不提供确定性，因为它容易受到Event到达系统的速度（例如来自消息队列）和ApacheFlink系统内部处理记录的顺序的影响.IngestionTimeIngestion时间是事件进入ApacheFlink的时间。在Source算子处生成，每条记录都以source的当前时间作为时间戳，基于时间的算子（比如TimeWindow）会引用这个时间戳。摄取时间在概念上位于事件时间和处理时间之间。与ProcessingTime相比，IngestionTime的成本略高，但可以提供更可预测的结果：由于IngestionTime使用稳定的时间戳（在源头分配一次），因此不受内部处理事件的顺序和顺序的影响系统受数据传输延迟的影响。与EventTime相比，IngestionTime无法处理任何乱序事件或延迟数据。IngestionTime与ApacheFlink内部机制中的EventTime非常相似，具有时间戳自动分配和水印自动生成功能。ApacheFlink目前使用的时间目前在ApacheFlinkSQL层面为用户开发的时间类型有EventTime和ProcessingTime。小结本文介绍了ApacheFlink的内部时间概念。在ApacheFlink内部，有EventTime、ProcessingTime和Ingestiontime三种时间，目前对用户开放的是EventTime和ProcessingTime。时间在流计算中非常重要。时间是数据分组的主要依据，时间也是流计算中处理数据延迟和数据乱序的核心要素。作者介绍孙金城，社区编辑，ApacheFlinkPMC成员，ApacheBeamCommitter，ApacheIoTTDBPMC成员，ALCBeijing成员，Apache神鱼导师，Apache软件基金会成员。专注于技术领域的流计算和时序数据存储。
