能夠穿梭時空的實時計算框架——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 部電影是該系列中的第 四、五、 6 部（這是事件時間），它們的上映年份分別是 1977 年、1980 年和 1983 年 （這是處理時間）。以後按事件時間上映的第 一、二、三、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等相關技術博文，歡迎關注實時流式計算：