我們拋開計數(shù)窗口，先看時間窗口

對于時間窗口最主要的就是時間，比如1分鐘的窗口長度，那么這個1分鐘是如何定義呢？

Flink中針對時間有3種類型

• EventTime[事件時間]

事件發(fā)生的時間，例如：點擊網(wǎng)站上的某個鏈接的時間

• IngestionTime[攝入時間]

某個Flink節(jié)點的source operator接收到數(shù)據(jù)的時間，例如：某個source消費到kafka中的數(shù)據(jù)

• ProcessingTime[處理時間]

某個Flink節(jié)點執(zhí)行某個operation的時間，例如：timeWindow接收到數(shù)據(jù)的時間

• 事件時間 event time

事件真實發(fā)生的時間。Flink1.12版本起默認事件時間。

• 處理時間 process time

Flink處理start-log中這條數(shù)據(jù)時的設(shè)備時間。Flink1.12之前默認處理時間。

Flink1.12版本之前，如何指定為事件時間呢？

EventTime

在大數(shù)據(jù)領(lǐng)域，日志服務(wù)器生成的一條數(shù)據(jù)也可以稱為一個事件。EventTime是指在數(shù)據(jù)產(chǎn)生時該設(shè)備上對應(yīng)的時間，這個時間在進入Flink之前已經(jīng)存在于數(shù)據(jù)記錄中了。

以后數(shù)據(jù)被Flink處理數(shù)據(jù)，如果使用EventTime作為時間標準，那么數(shù)據(jù)并不是按照EventTime的先后順序被處理的，由于數(shù)據(jù)可能產(chǎn)生在多個不同的日志服務(wù)器，然后通常是再將數(shù)據(jù)寫入到分布性消息中間件，然后被被Flink拉取進行處理時，處理的實際時間相對于數(shù)據(jù)產(chǎn)生的實際肯定有一定的延遲，并且EventTime可能也是亂序的。

那么為什么還要使用EventTime呢？

是因為使用EventTime時，F(xiàn)link程序可以處理亂序事件和延遲數(shù)據(jù)。并且最重要的功能就是可以統(tǒng)計在數(shù)據(jù)產(chǎn)生時，對應(yīng)時間的數(shù)據(jù)指標。

總之，使用EventTime的優(yōu)勢是結(jié)果的可預測性，缺點是緩存較大，增加了延遲，且調(diào)試和定位問題更復雜。

ProcessingTime

ProcessingTime是指事件數(shù)據(jù)被Operator處理時所在機器的系統(tǒng)時間，它提供了最好的性能和最低的延遲。

但是，F(xiàn)link是一個在分布式的計算框架，數(shù)據(jù)從產(chǎn)生到被處理會有一定的延遲（例如從消息隊列拉取數(shù)據(jù)到Source，Source再到處理的Operator會有一定的延遲），所以ProcessingTime無法精準的體現(xiàn)出數(shù)據(jù)在產(chǎn)生的那個時刻的變化情況。

IngestionTime

IngestionTime指的是事件數(shù)據(jù)進入到Flink的時間。每條數(shù)據(jù)的IngestionTime就是進入到SourceOperator時所在機器的系統(tǒng)時間。比如Flink從Kafka消息中間件消費數(shù)據(jù)，每一條數(shù)據(jù)的IngestionTime就是FlinkKafkaConsumer拉取數(shù)據(jù)進入到TaskManager對應(yīng)的時間。

IngestionTime介于EventTime和ProcessingTime之間，與EventTime相比，IngestionTime程序無法處理任何無序事件或延遲數(shù)據(jù)，并且程序不必指定如何生成水，F(xiàn)link會自動分配時間戳和自動生成水位線。