Flink vs Spark
Apache Spark和Flink都是下一代大數據工具搶占業界關注的焦點。兩者都提供與Hadoop和NoSQL數據庫的本機連接，並且可以處理HDFS數據。兩者都是幾個大數據的好方法問題。但由於其底層架構，Flink比Spark更快。Apache Spark是Apache存儲庫中最活躍的組件。Spark擁有非常強大的社區支持，並且擁有大量的貢獻者。Spark已經在生產中部署。但就流媒體功能而言，Flink遠比Spark好（因為spark以微批量形式處理流）並且具有對流的本機支持。Spark被認為是大數據的3G，而Flink則被視為大數據的4G。
Spark簡介
Spark的歷史比較悠久,已經發展了很長時間,目前在大數據領域也有了一定的地位.Spark是Apache的一個頂級項目。它是一種快速的、輕量級、基於內存、分布式迭代計算的大數據處理框架。,Spark最初由美國加州伯克利大學（UCBerkeley）的AMP（Algorithms，Machines and People）實驗室與2009年開發，是基於內存計算的大數據並行計算框架，可用於構建大型的、低延遲的數據分析應用程序。2003年加入Apache孵化器項目后的到迅猛的發展，如今已成為Apache的頂級項目。
Flink簡介
Flink出來的時間比較晚,可以說是大數據流計算的新貴,但是發展速度很快,勁頭不容小覷,到2016年的時候才嶄露頭角,Stratosphere 項目最早在 2010 年 12 月由德國柏林理工大學教授 Volker Markl 發起，主要開發人員包括 Stephan Ewen、Fabian Hueske。Stratosphere 是以 MapReduce 為超越目標的系統，同時期有加州大學伯克利 AMP 實驗室的 Spark。相對於 Spark，Stratosphere 是個徹底失敗的項目。其實剛開始的時候Flink也是做批處理的,但是當時,spark已經在批處理領域有所建樹,所以Flink決定放棄批處理,直接在流處理方面發力.所以 Volker Markl 教授參考了谷歌的流計算最新論文 MillWheel，決定以流計算為基礎，開發一個流批結合的分布式流計算引擎 Flink。Flink 於 2014 年 3 月進入 Apache 孵化器並於 2014 年 11 月畢業成為 Apache 頂級項目。
計算模型的區別
兩者最重要的區別就是計算模型的不同（微批和流）：
1、Micro Batching 模式(spark)
Micro-Batching 計算模式：流計算就是將連續不斷的批進行持續計算，如果批足夠小那么就有足夠小的延時，在一定程度上滿足了99%的實時計算場景。那么那1%為啥做不到呢?這就是架構的魅力，在Micro-Batching模式的架構實現上就有一個自然流數據流入系統進行攢批的過程，這在一定程度上就增加了延時。
Micro-Batching 模式的思想就是把輸入的數據,分成微小的批次,然后一個批次一個批次的處理,然后也是一個批次一個批次的輸出。很顯然Micro-Batching模式有其天生的低延時瓶頸，但任何事物的存在都有兩面性，在大數據計算的發展歷史上，最初Hadoop上的MapReduce就是優秀的批模式計算框架，Micro-Batching在設計和實現上可以借鑒很多成熟實踐。
2、Native Streaming 模式(flink)
Native Streaming 計算模式認為 ""批是流的特例"，這個認知更貼切流的概念，比如一些監控類的消息流，數據庫操作的binlog，實時的支付交易信息等等自然流數據都是一條，一條的流入。Native Streaming 計算模式每條數據的到來都進行計算，這種計算模式顯得更自然，並且延時性能達到更低。
Native Streaming 模型可以將輸入的數據過來一條處理一條，然后輸出，幾乎不存在延遲，很明顯Native Streaming模式占據了流計算領域 "低延時" 的核心競爭力。當然Native Streaming模式的框架實現上面很容易實現Micro-Batching和Batching模式的計算，另外，目前大數據領域主流的是流批統一，而Apache Flink就是Native Streaming計算模式的流批統一的計算引擎。
數據模型區別
1、基礎概念
無邊界數據，其實就是一種可增長，無限的數據集。我們無法判斷他到底會在什么時候結束。例如：我們生活中的支付寶中的交易數據，每時每刻都會有數據產生，無法判斷它什么時候會停止發送。我們也可以稱他為”流數據（Streaming Data）“。
有邊界數據，其實就是一種保存好了的數據，例如數據庫中的數據或者csv中的數據等。拿我們之前的交易數據來說，如果按照一定的時間窗口，拿取一小部分數據，那么提取出來的數據也是有邊界數據了。例如我提取2019年08月19日這天地數據來做處理，我們提取出來地這份數據就是有邊界數據。
批處理：數據的批處理，可以理解為一系列相關的任務按順序或並行的，一個接一個地執行。批處理地輸入是在一段時間內收集好地數據。每次批處理地輸出都可以是下次批處理地輸入。
大部分情況下，批處理地輸入數據和輸出數據都是有邊界數據。所以在批處理中，我們更關注地事件事件。批處理的系統架構通常會被設計在：日志分析、賬單處理、數據倉庫等；
流處理：數據的流處理可以理解為系統需要接收並處理一系列連續不斷變化的數據。例如，音視頻的實時推薦、周邊推薦等。流處理的輸入基本都是無邊界數據。而流處理系統中是關心事件時間還是處理時間一般是隨應用場景而定的。流處理的特點應該是足夠快、低延遲、以及來自各種數據源的大規模數據。流處理所需的響應時間更應該以毫秒（或秒）來進行計算。向我們平時用到的搜索引擎，系統必須在用戶輸入關鍵字后以毫秒級的延時返回搜索結果給用戶。流處理快的原因，是因為他是在數據未達到磁盤時計算的，也就是在內存中計算的。流處理的應用場景有：實時監控、實時交易等。
2、Spark的數據模型
Spark 最早采用 RDD 模型，達到比 MapReduce 計算快 100 倍的顯著優勢，對 Hadoop 生態大幅升級換代。RDD 彈性數據集是分割為固定大小的批數據，RDD 提供了豐富的底層 API 對數據集做操作。為持續降低使用門檻，Spark 社區開始開發高階 API：DataFrame/DataSet，Spark SQL 作為統一的 API，掩蓋了底層，同時針對性地做 SQL 邏輯優化和物理優化，非堆存儲優化也大幅提升了性能。
Spark Streaming 里的 DStream 和 RDD 模型類似，把一個實時進來的無限數據分割為一個個小批數據集合 DStream，定時器定時通知處理系統去處理這些微批數據。劣勢非常明顯，API 少、難勝任復雜的流計算業務，調大吞吐量而不觸發背壓是個體力活。不支持亂序處理，或者說很難處理亂序的問題。Spark Streaming 僅適合簡單的流處理，這里稍微解釋一下,因為spark的創始人在當時認為延遲不是那么的重要,他認為現實生活中沒有那么多低延遲的應用場景,所以就沒太注重延遲的問題,但是隨着生活多樣化場景的不斷增加,對實時性的要求越來越高,所以spark也注意到了這個問題,開始在延遲方面發力,進而推出了Structured Streaming,相信很快sparkstreaming就會被Structured Streaming替代掉。
Spark Structured Streaming 提供了微批和流式兩個處理引擎。微批的 API 雖不如 Flink 豐富，窗口、消息時間、trigger、watermarker、流表 join、流流 join 這些常用的能力都具備了。時延仍然保持最小 100 毫秒。當前處在試驗階段的流式引擎，提供了 1 毫秒的時延，但不能保證 exactly-once 語義，支持 at-least-once 語義。同時，微批作業打了快照，作業改為流式模式重啟作業是不兼容的。這一點不如 Flink 做的完美。當然了現在還在優化階段。
綜上，Spark Streaming 和 Structured Streaming 是用批計算的思路做流計算。其實，用流計算的思路開發批計算才是最合理的。對 Spark 來講，大換血不大可能，只有局部優化。其實，Spark 里 core、streaming、structured streaming、graphx 四個模塊，是四種實現思路，通過上層 SQL 統一顯得不純粹和諧。
3、Flink的數據模型
Flink 的基本數據模型是數據流，及事件(Event)的序列。數據流作為數據的基本模型可能沒有表或者數據塊直觀熟悉，但是可以證明是完全等效的。流可以是無邊界的無限流，即一般意義上的流處理。也可以是有邊界的有限流，這樣就是批處理。
Flink 采用 Dataflow 模型，和 Lambda 模式不同。Dataflow 是純粹的節點組成的一個圖，圖中的節點可以執行批計算，也可以是流計算，也可以是機器學習算法，流數據在節點之間流動，被節點上的處理函數實時 apply 處理，節點之間是用 netty 連接起來，兩個 netty 之間 keepalive，網絡 buffer 是自然反壓的關鍵。經過邏輯優化和物理優化，Dataflow 的邏輯關系和運行時的物理拓撲相差不大。這是純粹的流式設計，時延和吞吐理論上是最優的。
運行時架構
1、Spark運行時架構
批計算是把 DAG 划分為不同 stage，DAG 節點之間有血緣關系，在運行期間一個 stage 的 task 任務列表執行完畢，銷毀再去執行下一個 stage；
Spark Streaming 則是對持續流入的數據划分一個批次，定時去執行批次的數據運算；
Structured Streaming 將無限輸入流保存在狀態存儲中，對流數據做微批或實時的計算，跟 Dataflow 模型比較像。
2、Flink運行時架構
Flink 有統一的 runtime，在此之上可以是 Batch API、Stream API、ML、Graph、CEP 等，DAG 中的節點上執行上述模塊的功能函數，DAG 會一步步轉化成 ExecutionGraph，即物理可執行的圖，最終交給調度系統。節點中的邏輯在資源池中的 task 上被 apply 執行，task 和 Spark 中的 task 類似，都對應線程池中的一個線程。
在 DAG 的執行上，Spark 和 Flink 有一個比較顯著的區別。在 Flink 的流執行模式中，一個事件在一個節點處理完后的輸出就可以發到下一個節點立即處理。這樣執行引擎並不會引入額外的延遲。與之相應的，所有節點是需要同時運行的。而 Spark 的 micro batch 和一般的 batch 執行一樣，處理完上游的 stage 得到輸出之后才開始下游的 stage。在流計算的運行時架構方面，Flink 明顯更為統一且優雅一些。
時延和吞吐
至於延遲和吞吐方面,Spark Streaming是秒級別的,Structured Streaming是毫秒級別的；Flink是亞秒級別的,其實這個沒差多少。吞吐量的話,測試的結果是Flink是Spark的1.X倍.也相差不是太大。
反壓
Flink 中，下游的算子消費流入到網絡 buffer 的數據，如果下游算子處理能力不夠，則阻塞網絡 buffer，這樣也就寫不進數據，那么上游算子發現無法寫入，則逐級把壓力向上傳遞，直到數據源，這種自然反壓的方式非常合理。Spark Streaming 是設置反壓的吞吐量，到達閾值就開始限流，從批計算上來看是合理的。從這點看Flink的反壓機制是要比spark好的。
狀態存儲
Spark 的快照 API 是 RDD 基礎能力，定時開啟快照后，會對同一時刻整個內存數據持久化。Spark 一般面向大數據集計算，內存數據較大，快照不宜太頻繁，會增加集群計算量。spark的狀態管理目前做的比較簡單,只有兩個對應的算子。
Flink 提供文件、內存、RocksDB 三種狀態存儲，可以對運行中的狀態數據異步持久化。打快照的機制是給 source 節點的下一個節點發一條特殊的 savepoint 或 checkpoint 消息，這條消息在每個算子之間流動，通過協調者機制對齊多個並行度的算子中的狀態數據，把狀態數據異步持久化。
Flink 打快照的方式，是我見過最為優雅的一個。Flink 支持局部恢復快照，作業快照數據保存后，修改作業，DAG 變化，啟動作業恢復快照，新作業中未變化的算子的狀態仍舊可以恢復。而且 Flink 也支持增量快照，面對內存超大狀態數據，增量無疑能降低網絡和磁盤開銷。我們會發現Flink的狀態存儲也有較多的選擇。
API方面
Spark 的初衷之一就是用統一的編程模型來解決用戶的各種需求，在這方面一直很下功夫。最初基於 RDD 的 API 就可以做各種類型的數據處理。后來為了簡化用戶開發，逐漸推出了更高層的 DataFrame(在 RDD 中加了列變成結構化數據)和 Datasets(在 DataFrame 的列上加了類型)，並在 Spark 2.0 中做了整合(DataFrame = DataSet[Row])。Spark SQL 的支持也比較早就引入了。在加上各個處理類型 API 的不斷改進，比如 Structured Streaming 以及和機器學習深度學習的交互，到了今天 Spark 的 API 可以說是非常好用的，也是 Spark 最強的方面之一。
Flink 的 API 也有類似的目標和發展路線。Flink 和 Spark 的核心 API 可以說是可以基本對應的。今天 Spark API 總體上更完備一下，比如說最近一兩年大力投入的和機器學習深度學習的整合方面。Flink 在流處理相關的方面還是領先一些，比如對 watermark、window、trigger 的各種支持要比spark好很多。