大數據流處理-我爲什麼選擇Apache Flink

隨着這幾年大數據技術的迅猛發展，人們對於處理數據的要求也越來越高，由最早的MapReduce，到後來的hive、再到後來的spark，爲了獲取更快、更及時的結果，計算模型也在由以前的T+1的離線數據慢慢向流處理轉變，比如每年雙十一阿里的實時大屏，要求秒級的輸出結果；再比如當我們以100邁的速度開車的時候，我們希望地圖導航軟件能給我們毫秒級延遲的導航信息。

那麼對於已經有了storm、spark streaming這樣的流處理框架之後，我們爲什麼還要選擇Apache Flink來作爲我們的流處理框架呢？

真正的流處理

低延遲

對於spark streaming來說，雖然也是一個流處理框架，但是他的底層是一個微批的模式，只是這個批足夠小，使我們看起來像一個流處理，這種對於我們普通的需求來說已經足夠了，但是對於我們上面所說的地圖導航軟件來說，我們需要的延遲是毫秒級別的，因爲如果你延遲了半分鐘，我可能已經開出來好遠了，你給我的導航信息也沒什麼用了。
所以對於微批處理的框架，天生是會造成數據延遲的，flink作爲一個真正的流處理框架，可以每來一個數據處理一個，實現真正的流處理、低延遲。

高吞吐

就像我們前面說的，阿里雙十一的數據計算是很大的，這個時候對這麼龐大的數據進行計算，就需要我們有一個支持高吞吐量的計算框架來滿足更實時的需求。

多種窗口

flink本身提供了多種靈活的窗口,我們結合實際來講講這幾個窗口的含義.

• 滾動窗口： 每隔五分鐘計算當前這五分鐘內的銷售總額。
• 滑動窗口： 每隔五分鐘計算一下前一個小時的銷售總額。
• session窗口 ：統計用戶在他登錄的這段時間裏，他的訪問總次數
• 全局窗口：我們可以統計自程序上線以來的一些數值。

除了時間窗口（time window），還有計數窗口（count window），count window窗口也可以有滾動和滑動窗口，比如我們每隔100個數來統計一下這100個數的平均值。

自帶狀態(state)

何爲狀態，白話講一下，比如我們從kafka消費了一條條的數據，然後又一條條的寫入了文件，這種是沒有狀態的計算，因爲單條數據不需要依賴其前後的數據。

當我們要實現一個窗口計數，統計每個小時的pv數，我們可以想象，有這麼一個變量，每來一個數據這個變量就加一，然後程序運行一半的時候，因爲某一種原因掛了，這個時候那個變量如果是存在內存裏的，就丟了，程序重啓之後，我們必須重新從窗口的開始來計算，那麼有沒有一種機制，可以自動的幫我把這個臨時變量可靠的存起來呢，這個就是flink中的狀態，對於上述場景，當我們恢復程序的時候，選擇從上一個checkpoint恢復，那麼我們就可以繼續從程序掛掉的時候繼續計算，而不用從窗口的開始進行計算了。

精確一次傳輸語義

對於一個大型分佈式系統來說，因爲網絡、磁盤等等原因造成程序失敗是很常見的，那麼當我們恢復了程序之後，如何保證數據不丟不重呢？
flink提供了Exactly-once語義來處理這個問題。

時間管理

flink提供了多種時間語義來供我們使用。

• 事件時間
  也就是我們計算的時候使用數據中的時間，比如我們的程序因爲某些原因掛了半個小時，當程序起來的時候我們希望程序能接着上次的繼續處理，這個時候事件時間就派上用場了。
  此外，對於一些告警系統，日誌中的時間往往能真實的反應出有問題的時間，更有實際意義

• 處理時間
  也就是flink程序當前的時間

• 攝取時間
  數據進入flink程序的時間
  

水印

真實的生產環境中，數據的傳輸會經過很多流程、在這個過程中，免不了由於網絡抖動等等各種原因造成數據的延遲到達、本來應該先來的數據遲到了，這種情況怎麼處理呢，flink的watermark機制來幫你處理。
我們可以簡單的理解爲，通過設置一個可以接受的延遲時間，如果你的數據到點了沒過來flink會等你幾秒鐘，然後等你的數據過來了再觸發計算，但是由於是流處理，肯定不能無限制的等下去，對於超過了我設置的等待時間還沒來的數據，那麼我只能拋棄或者存到另一個流裏面用別的邏輯來處理了。

複雜事件處理

先來說這麼一個場景，比如說我們要監控機器的溫度，連續10分鐘之內有三次溫度超過50度，生成一個警告，如果連續一個小時之內出現過兩次上述警告，生成一個報警。
對於這麼一個場景，是不是覺得普通的api程序不好做了？那好，flink的複雜事件處理(CEP)派上用場了，使用cep可以處理很多類似的複雜的場景。

其實flink還有很多好用的功能，等待我們一起去開發！

更多精彩內容，歡迎關注我的公衆號【大數據技術與應用實戰】，一起進步！