爲什麼選擇 Flink
【1】流數據更真實地反映了我們的生活方式（實時聊天）；
【2】傳統的數據架構是基於有限數據集的（Spark 是基於微批次數據處理）；
【3】我們的目標：低延遲、高吞吐（分佈式架構，可能會出現順序上的混亂，比如統計1個小時內，可能在1小時的時候，可能有的數據還在處理，會延遲到達幾毫秒，這個可以通過設置來規避）、結果的準確性和良好的容錯性；
哪些行業需要處理流數據
【1】電商和市場營銷：數據報表、廣告投放、業務流程需要；
【2】物聯網（IOT）：傳感器實時數據採集和顯示、實時報警，交通運輸業；
【3】電信業：基站流量調配；
【4】銀行和金融業：實時結算和通知推送，實時檢測異常行爲（不用再到晚上進行才進行批處理計算）；
傳統數據處理架構
企業剛開始主要進行事務處理：CRM 產生事件——在 Order 中進行邏輯處理——最終反饋給Click，數據都是通過關係型數據庫獲取，那麼當對數據進行統計時，數據量大的時候就會遇到瓶頸。OLTP 特點是快速響應。缺點是數據量大時不易擴展。
分析處理：將數據從業務數據庫複製到數倉，再進行分析和查詢。OLAP 特點是對大數據的數據分析，缺點是離線分析。
有狀態的流式處理：將數據存儲在本地內存，如果處理的過程中某個節點掛了，數據如何保存。就有了 RemoteStorage（內存的一個快照）實現了毫秒級別的延遲。但是問題是分佈式項目不能保證數據處理的順序，不能保證數據的準確性，在併發性上和吞吐量上存在瓶頸。Stom的實現方式。
流處理的演變：Lambda 架構，用兩套系統，同時保證低延遲和結果準確。問題就是麻煩，需要兩套架構。
流處理的演變：整合 Spark Streaming 的高吞吐和正確性（使用的時候需要設置500ms之上延遲）和Storm的低延遲。
Flink 的主要特點
事件驅動（Event-driven）
基於流的世界觀：在Flink 的世界觀中，一切都是由流組成的，離線數據是有界的流；實時數據是一個沒有界限的流：這就是所謂的有界流和無界流。
分成API 的設置：越頂層越抽象，表達含義越簡明，使用越方便。越底層越具體，表達能力越豐富，使用越靈活。
Flink 的其他特點
支持事件時間（event-time）和處理時間（processing-time）語義：對時間進行不同的定義；
精確一次（exactly-once）的狀態一致性保證：正確性更加準確；
低延遲，每秒處理數百萬個事件，毫秒級延遲
與衆多常用存儲系統的鏈接：kafka、redis、hive、dfs等服務器進行鏈接
高可用，動態擴展，實現7*24小時全天候運行
Flink vs Spark Streaming
流（Stream）和微批（micro-batching）
數據模型：spark 採用RDD模型，spark streaming 的 DStream 實際上也就是一組小批數據 RDD 的集合。Flink 基本數據模型是數據流，以及事件（Event）序列。
運行時架構：spark 是批計算，將 DAG 劃分爲不同的 stage，一個完成後纔可以計算下一個。Flink 是標準的流執行模式，一個事件在一個節點處理完後可以直接發往下一個節點進行處理。
----關注公衆號，獲取更多內容----