摘要：每小時(shí)窗口將包括在系統(tǒng)時(shí)鐘指示整個(gè)小時(shí)之間到達(dá)特定操作的所有事件。平行流中的水印水印是在源函數(shù)處生成的，或直接在源函數(shù)之后生成的。源函數(shù)的每個(gè)并行子任務(wù)通常獨(dú)立生成其水印。由于其輸入流更新其事件時(shí)間，因此操作員也是如此。

Flink 在流程序中支持不同的 Time 概念，就比如有 Processing Time、Event Time 和 Ingestion Time。

下面我們一起來(lái)看看這幾個(gè) Time：

Processing Time 是指事件被處理時(shí)機(jī)器的系統(tǒng)時(shí)間。

當(dāng)流程序在 Processing Time 上運(yùn)行時(shí)，所有基于時(shí)間的操作(如時(shí)間窗口)將使用當(dāng)時(shí)機(jī)器的系統(tǒng)時(shí)間。每小時(shí) Processing Time 窗口將包括在系統(tǒng)時(shí)鐘指示整個(gè)小時(shí)之間到達(dá)特定操作的所有事件。

例如，如果應(yīng)用程序在上午 9:15 開始運(yùn)行，則第一個(gè)每小時(shí) Processing Time 窗口將包括在上午 9:15 到上午 10:00 之間處理的事件，下一個(gè)窗口將包括在上午 10:00 到 11:00 之間處理的事件。

Processing Time 是最簡(jiǎn)單的 "Time" 概念，不需要流和機(jī)器之間的協(xié)調(diào)，它提供了最好的性能和最低的延遲。但是，在分布式和異步的環(huán)境下，Processing Time 不能提供確定性，因?yàn)樗菀资艿绞录竭_(dá)系統(tǒng)的速度（例如從消息隊(duì)列）、事件在系統(tǒng)內(nèi)操作流動(dòng)的速度以及中斷的影響。

Event Time 是事件發(fā)生的時(shí)間，一般就是數(shù)據(jù)本身攜帶的時(shí)間。這個(gè)時(shí)間通常是在事件到達(dá) Flink 之前就確定的，并且可以從每個(gè)事件中獲取到事件時(shí)間戳。在 Event Time 中，時(shí)間取決于數(shù)據(jù)，而跟其他沒(méi)什么關(guān)系。Event Time 程序必須指定如何生成 Event Time 水印，這是表示 Event Time 進(jìn)度的機(jī)制。

完美的說(shuō)，無(wú)論事件什么時(shí)候到達(dá)或者其怎么排序，最后處理 Event Time 將產(chǎn)生完全一致和確定的結(jié)果。但是，除非事件按照已知順序（按照事件的時(shí)間）到達(dá)，否則處理 Event Time 時(shí)將會(huì)因?yàn)橐却恍o(wú)序事件而產(chǎn)生一些延遲。由于只能等待一段有限的時(shí)間，因此就難以保證處理 Event Time 將產(chǎn)生完全一致和確定的結(jié)果。

假設(shè)所有數(shù)據(jù)都已到達(dá)， Event Time 操作將按照預(yù)期運(yùn)行，即使在處理無(wú)序事件、延遲事件、重新處理歷史數(shù)據(jù)時(shí)也會(huì)產(chǎn)生正確且一致的結(jié)果。 例如，每小時(shí)事件時(shí)間窗口將包含帶有落入該小時(shí)的事件時(shí)間戳的所有記錄，無(wú)論它們到達(dá)的順序如何。

請(qǐng)注意，有時(shí)當(dāng) Event Time 程序?qū)崟r(shí)處理實(shí)時(shí)數(shù)據(jù)時(shí)，它們將使用一些 Processing Time 操作，以確保它們及時(shí)進(jìn)行。

Ingestion Time 是事件進(jìn)入 Flink 的時(shí)間。 在源操作處，每個(gè)事件將源的當(dāng)前時(shí)間作為時(shí)間戳，并且基于時(shí)間的操作（如時(shí)間窗口）會(huì)利用這個(gè)時(shí)間戳。

Ingestion Time 在概念上位于 Event Time 和 Processing Time 之間。 與 Processing Time 相比，它稍微貴一些，但結(jié)果更可預(yù)測(cè)。因?yàn)?Ingestion Time 使用穩(wěn)定的時(shí)間戳（在源處分配一次），所以對(duì)事件的不同窗口操作將引用相同的時(shí)間戳，而在 Processing Time 中，每個(gè)窗口操作符可以將事件分配給不同的窗口（基于機(jī)器系統(tǒng)時(shí)間和到達(dá)延遲）。

與 Event Time 相比，Ingestion Time 程序無(wú)法處理任何無(wú)序事件或延遲數(shù)據(jù)，但程序不必指定如何生成水印。

在 Flink 中，，Ingestion Time 與 Event Time 非常相似，但 Ingestion Time 具有自動(dòng)分配時(shí)間戳和自動(dòng)生成水印功能。

說(shuō)了這么多概念比較干澀，下面直接看圖：

Flink DataStream 程序的第一部分通常是設(shè)置基本時(shí)間特性。 該設(shè)置定義了數(shù)據(jù)流源的行為方式（例如：它們是否將分配時(shí)間戳），以及像 KeyedStream.timeWindow(Time.seconds(30)) 這樣的窗口操作應(yīng)該使用上面哪種時(shí)間概念。

以下示例顯示了一個(gè) Flink 程序，該程序在每小時(shí)時(shí)間窗口中聚合事件。

final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);

// 其他
// env.setStreamTimeCharacteristic(TimeCharacteristic.IngestionTime);
// env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);

DataStream stream = env.addSource(new FlinkKafkaConsumer09(topic, schema, props));

stream
    .keyBy( (event) -> event.getUser() )
    .timeWindow(Time.hours(1))
    .reduce( (a, b) -> a.add(b) )
    .addSink(...);

注意：Flink 實(shí)現(xiàn)了數(shù)據(jù)流模型中的許多技術(shù)。有關(guān) Event Time 和 Watermarks 的詳細(xì)介紹，請(qǐng)查看以下文章：

[https://www.oreilly.com/ideas...]()

[https://research.google.com/p...]()

支持 Event Time 的流處理器需要一種方法來(lái)衡量 Event Time 的進(jìn)度。 例如，當(dāng) Event Time 超過(guò)一小時(shí)結(jié)束時(shí)，需要通知構(gòu)建每小時(shí)窗口的窗口操作符，以便操作員可以關(guān)閉正在進(jìn)行的窗口。

Event Time 可以獨(dú)立于 Processing Time 進(jìn)行。 例如，在一個(gè)程序中，操作員的當(dāng)前 Event Time 可能略微落后于 Processing Time （考慮到接收事件的延遲），而兩者都以相同的速度進(jìn)行。另一方面，另一個(gè)流程序可能只需要幾秒鐘的時(shí)間就可以處理完 Kafka Topic 中數(shù)周的 Event Time 數(shù)據(jù)。

Flink 中用于衡量 Event Time 進(jìn)度的機(jī)制是 Watermarks。 Watermarks 作為數(shù)據(jù)流的一部分流動(dòng)并帶有時(shí)間戳 t。 Watermark（t）聲明 Event Time 已到達(dá)該流中的時(shí)間 t，這意味著流中不應(yīng)再有具有時(shí)間戳 t"<= t 的元素（即時(shí)間戳大于或等于水印的事件）

下圖顯示了帶有(邏輯)時(shí)間戳和內(nèi)聯(lián)水印的事件流。在本例中，事件是按順序排列的(相對(duì)于它們的時(shí)間戳)，這意味著水印只是流中的周期性標(biāo)記。

Watermark 對(duì)于無(wú)序流是至關(guān)重要的，如下所示，其中事件不按時(shí)間戳排序。通常，Watermark 是一種聲明，通過(guò)流中的該點(diǎn)，到達(dá)某個(gè)時(shí)間戳的所有事件都應(yīng)該到達(dá)。一旦水印到達(dá)操作員，操作員就可以將其內(nèi)部事件時(shí)間提前到水印的值。

水印是在源函數(shù)處生成的，或直接在源函數(shù)之后生成的。源函數(shù)的每個(gè)并行子任務(wù)通常獨(dú)立生成其水印。這些水印定義了特定并行源處的事件時(shí)間。

當(dāng)水印通過(guò)流程序時(shí)，它們會(huì)提前到達(dá)操作人員處的事件時(shí)間。當(dāng)一個(gè)操作符提前它的事件時(shí)間時(shí)，它為它的后續(xù)操作符在下游生成一個(gè)新的水印。

一些操作員消耗多個(gè)輸入流; 例如，一個(gè) union，或者跟隨 keyBy（...）或 partition（...）函數(shù)的運(yùn)算符。 這樣的操作員當(dāng)前事件時(shí)間是其輸入流的事件時(shí)間的最小值。 由于其輸入流更新其事件時(shí)間，因此操作員也是如此。

下圖顯示了流經(jīng)并行流的事件和水印的示例，以及跟蹤事件時(shí)間的運(yùn)算符。

https://github.com/zhisheng17...

轉(zhuǎn)載請(qǐng)務(wù)必注明原創(chuàng)地址為：http://www.54tianzhisheng.cn/2018/12/11/Flink-time/

微信公眾號(hào)：zhisheng

另外我自己整理了些 Flink 的學(xué)習(xí)資料，目前已經(jīng)全部放到微信公眾號(hào)了。你可以加我的微信：zhisheng_tian，然后回復(fù)關(guān)鍵字：Flink 即可無(wú)條件獲取到。

https://github.com/zhisheng17/flink-learning/

以后這個(gè)項(xiàng)目的所有代碼都將放在這個(gè)倉(cāng)庫(kù)里，包含了自己學(xué)習(xí) flink 的一些 demo 和博客

1、《從0到1學(xué)習(xí)Flink》—— Apache Flink 介紹

2、《從0到1學(xué)習(xí)Flink》—— Mac 上搭建 Flink 1.6.0 環(huán)境并構(gòu)建運(yùn)行簡(jiǎn)單程序入門

3、《從0到1學(xué)習(xí)Flink》—— Flink 配置文件詳解

4、《從0到1學(xué)習(xí)Flink》—— Data Source 介紹

5、《從0到1學(xué)習(xí)Flink》—— 如何自定義 Data Source ？

6、《從0到1學(xué)習(xí)Flink》—— Data Sink 介紹

7、《從0到1學(xué)習(xí)Flink》—— 如何自定義 Data Sink ？

8、《從0到1學(xué)習(xí)Flink》—— Flink Data transformation(轉(zhuǎn)換)

9、《從0到1學(xué)習(xí)Flink》—— 介紹Flink中的Stream Windows

10、《從0到1學(xué)習(xí)Flink》—— Flink 中的幾種 Time 詳解

11、《從0到1學(xué)習(xí)Flink》—— Flink 寫入數(shù)據(jù)到 ElasticSearch

12、《從0到1學(xué)習(xí)Flink》—— Flink 項(xiàng)目如何運(yùn)行？

13、《從0到1學(xué)習(xí)Flink》—— Flink 寫入數(shù)據(jù)到 Kafka