Flink對於流處理架構的意義十分重要，Kafka讓消息具有了持久化的能力，而處理數據，甚至穿越時間的能力都要靠Flink來完成。 在 "Streaming 大數據的未來" 一文中我們知道，對於流式處理最重要的兩件事，正確性，時間推理工具。而Flink對兩者都有非常好的支持。 Flink對於正確性的 ...
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-大數據的未來
以上為Flink對於時間的處理，更多實時計算,Flink,Kafka等相關技術博文，歡迎關註實時流式計算：
