隨著這幾年大數據技術的迅猛發展，人們對于處理數據的要求也越來越高，由最早的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可以處理很多類似的復雜的場景。