Flink對於流處理架構的意義十分重要，Kafka讓訊息具有了持久化的能力，而處理資料，甚至穿越時間的能力都要靠Flink來完成。

在Streaming-大資料的未來一文中我們知道，對於流式處理最重要的兩件事，正確性，時間推理工具。而Flink對兩者都有非常好的支援。

Flink對於正確性的保證

對於連續的事件流資料，由於我們處理時可能有事件暫未到達，可能導致資料的正確性受到影響，現在採取的普遍做法的通過高延遲的離線計算保證正確性，但是也犧牲了低延遲。

Flink的正確性體現在計算視窗的定義符合資料產生的自然規律。比如點選流事件，追蹤3個使用者A，B，C的訪問情況。我們看到資料是可能有間隙的，這也就是session視窗。

用SparkStreaming的微批處理方式（虛線為計算視窗，實線是會話視窗），很難做到計算視窗與會話視窗的吻合。而使用Flink的流處理API，可以靈活的定義計算視窗。比如可以設定一個值，如果超出這個值就認為活動結束。

不同於一般的流處理，Flink可以採用事件時間，這對於正確性非常有用。

對於發生故障性的正確性保證，必須要跟蹤計算狀態，現在大部分時候狀態性的保證是靠開發人員完成的，但是連續的流處理計算沒有終點。Flink採用檢查點-checkpoint技術解決了這個問題。在每個檢查點，系統都會記錄中間計算狀態，從而在故障發生時準確地重 置。這一方法使系統以低開銷的方式擁有了容錯能力——當一切正常時， 檢查點機制對系統的影響非常小。

Flink提供的介面，包括了跟蹤計算的任務，並用同一種技術來實現流處理和批處理，簡化了運維開發工作，這也是對正確性的一種保證。

Flink對於時間的處理

用流處理和批處理最大的區別就是對時間的處理。

採用批處理架構處理

在該架構中，我們可以每隔一段時間儲存資料，比如存在HDFS中，由排程程式定時的執行，將結果輸出。

這種架構可行但是有幾個問題：

• 太多獨立的部分。為了計算資料中的事件數，這種架構動用了太多系統。 每一個系統都有學習成本和管理成本，還可能存在 bug。

• 對時間的處理方法不明確。假設需要改為每 30 分鐘計數一次。這個變動涉及工作流排程邏輯（而不是應用程式程式碼邏輯），從而使 DevOps 問題 與業務需求混淆。

• 預警。假設除了每小時計數一次外，還需要儘可能早地收到計數預警（ 如在事件數超過10 時預警）。為了做到這一點，可以在定期執行的批處理作業之外，引入 Storm 來採集訊息流。 Storm 實時提供近似的計數，批處理作業每小時提供準確的計數。但是這樣一來，就向架構增加了一個系統，以及與之相關的新程式設計模型。上述架構叫作 Lambda 架構。

​

• 亂序事件流。在現實世界中，大多數事件流都是亂序的，即事件的實際發生順序和資料中心所記錄的順序不一樣。這意味著本屬於前一批的事件可能被錯誤地歸入當前一批。批處理架構很難解決這個問題，大部分人則選擇忽視它。
• 批處理作業的界限不清晰。在分割時間點前後的事件既可能被歸入前一批，也可能被歸入當前一批。

採用流處理

首先將訊息集中寫入訊息傳輸系統kafka，事件流由訊息傳輸系統提供，並且只被單一的 Flink 作業處理。

以時間為單位把事件流分割為一批批任務，這種邏輯完全嵌入在 Flink 程式的應用邏輯中。預警由同一個程式生成，亂序事件由 Flink 自行處理。要從以固定時間分組改為根據產生資料的時間段分組，只需在 Flink 程式中修改對視窗的定義即可。此外，如果應用程式的程式碼有過改動，只需重播 Kafka 主題，即可重播應用程式。採用流處理架構，可以大幅減少需要學習、管理和編寫程式碼的系統。Flink 應用程式程式碼示例：

DataStream<LogEvent> stream = env  
// 通過Kafka生成資料流  
.addSource(new FlinkKafkaConsumer(...))   
// 分組   
.keyBy("country")   
// 將時間視窗設為60分鐘  
.timeWindow(Time.minutes(60))   
// 針對每個時間視窗進行操作   
.apply(new CountPerWindowFunction());

在流處理中，主要有兩個時間概念 ：

事件時間，即事件實際發生的時間。更準確地說，每一個事件都有一個與它相關的時間戳，並且時間戳是資料記錄的一部分。

處理時間，即事件被處理的時間。處理時間其實就是處理事件的機器所測量的時間。

以《星球大戰》系列電影為例。首先上映的 3 部電影是該系列中的第 4、5、 6 部（這是事件時間），它們的上映年份分別是 1977 年、1980 年和 1983 年 （這是處理時間）。之後按事件時間上映的第 1、2、3、7 部，對應的處理時間分別是 1999 年、2002 年、2005 年和 2015 年。由此可見，事件流的順序可能是亂的（儘管年份順序一般不會亂）

通常還有第 3 個時間概念，即攝取時間，也叫作進入時間。它指的是事件進入流處理框架的時間。缺乏真實事件時間的資料會被流處理器附上時間戳，即流處理器第一次看到它的時間（這個操作由 source 函式完成，它是程式的第一個處理點）。

在現實世界中，許多因素（如連線暫時中斷，不同原因導致的網路延遲， 分散式系統中的時鐘不同步，資料速率陡增，物理原因，或者運氣差）使 得事件時間和處理時間存在偏差（即事件時間偏差）。事件時間順序和處理 時間順序通常不一致，這意味著事件以亂序到達流處理器。

Flink 允許使用者根據所需的語義和對準確性的要求選擇採用事 件時間、處理時間或攝取時間定義視窗。

視窗

時間視窗是最簡單和最有用的一種視窗。它支援滾動和滑動。

比如一分鐘滾動視窗收集最近一分鐘的數值，並在一分鐘結束時輸出總和：

一分鐘滑動視窗計算最近一分鐘的數值總和，但每半分鐘滑動一次並輸出 結果：

在 Flink 中，一分鐘滾動視窗的定義如下。

stream.timeWindow(Time.minutes(1))

每半分鐘（即 30 秒）滑動一次的一分鐘滑動視窗如下所示。

stream.timeWindow(Time.minutes(1), Time.seconds(30))

Flink 支援的另一種常見視窗叫作計數視窗。採用計數視窗時，分組依據不 再是時間戳，而是元素的數量。

滑動視窗也可以解釋為由 4 個元素組成的計數視窗，並且每兩個元素滑動一次。滾動和滑動的計數窗 口分別定義如下。

stream.countWindow(4) 
stream.countWindow(4, 2)

雖然計數視窗有用，但是其定義不如時間視窗嚴謹，因此要謹慎使用。時 間不會停止，而且時間視窗總會“關閉”。但就計數視窗而言，假設其定義 的元素數量為 100，而某個 key 對應的元素永遠達不到 100 個，那麼視窗就 永遠不會關閉，被該窗口占用的記憶體也就浪費了。

Flink 支援的另一種很有用的視窗是會話視窗。會話視窗由超時時間設定，即希望等待多久才認為會話已經結束。
示例如下：

stream.window(SessionWindows.withGap(Time.minutes(5))

觸發器

除了視窗之外，Flink 還提供觸發機制。觸發器控制生成結果的時間，即何時聚合視窗內容並將結果返回給使用者。每一個預設視窗都有一個觸發器。 例如，採用事件時間的時間視窗將在收到水印時被觸發。對於使用者來說， 除了收到水印時生成完整、準確的結果之外，也可以實現自定義的觸發器。

時間回溯

流處理架構的一個核心能力是時間的回溯機制。意味著將資料流倒回至過去的某個時間，重新啟動處理程式，直到處理至當前時間為止。 Kafka支援這種能力。

實時流處理總是在處理最近的資料（即圖中“當前時間”的資料），歷史流處理 則從過去開始，並且可以一直處理至當前時間。流處理器支援事件時間， 這意味著將資料流“倒帶”，用同一組資料重新運行同樣的程式，會得到相同的結果。

水印

Flink 通過水印來推進事件時間。水印是嵌在流中的常規記錄，計算程式通 過水印獲知某個時間點已到。收到水印的視窗就知道 不會再有早於該時間的記錄出現，因為所有時間戳小於或等於該時間的事 件都已經到達。這時，視窗可以安全地計算並給出結果（總和）。水印使事 件時間與處理時間完全無關。遲到的水印（“遲到”是從處理時間的角度而言）並不會影響結果的正確性，而只會影響收到結果的速度。

水印由應用程式開發人員生成，這通常需要對相應的領域有 一定的瞭解。完美的水印永遠不會錯：時間戳小於水印標記時間的事件不會再出現。

如果水印遲到得太久，收到結果的速度可能就會很慢，解決辦法是在水印 到達之前輸出近似結果（Flink 可以實現）。如果水印到達得太早，則可能收到錯誤結果，不過 Flink 處理遲到資料的機制可以解決這個問題。

相關文章：
Streaming-大資料的未來

實時計算大資料處理的基石-Google Dataflow

資料架構的未來——淺談流處理架構

以上為Flink對於時間的處理，更多實時計算,Flink,Kafka等相關技術博文，歡迎關注實時流式計算：