為了理解spark和flink引擎的特性，首先必須檢查它們各自的資料模型。
spark使用彈性分布式資料集（resilient distributed dataset，rdd），rdd比mapreduce的檔案模型更抽象，依賴於運算關係以確保可恢復性。rdd通常用於分布式共享記憶體或完全虛擬化，也就是說，當下游處理完全在本地時，可以對一些中間結果進行優化和省略。這節省了大量不必要的輸入和輸出，是spark早期效能優勢的主要基礎。
spark還使用rdd上的轉換（操作符）來描述資料處理，每個操作符（如map、filter、join）生成乙個新的rdd，所有的操作符形成乙個有向無環圖（directed acyclic graph，dag）。spark簡單地將圖的邊劃分為2類：寬依賴和窄依賴。當上下游資料不需要混洗時，邊是乙個窄依賴。在這種情況下，上下游操作可以在同乙個stage中進行本地處理，並且可以忽略上游結果rdd的物化，下圖呈現了這裡涉及的基本概念。
相比之下，flink的基本資料模型由資料流組成，例如事件序列。資料流作為資料的基本模型，可能不如表或資料塊那樣直觀和熟悉，但仍然可以提供一組完全等效的特性。人們普遍認為資料流是沒有邊界的，但它也可以是乙個有邊界的有限流，處理這些流相當於批處理。
為了描述資料處理過程，flink在資料流上使用操作符，每個操作符生成乙個新的資料流。從操作符、dag和上下游操作符的鏈結來看，整體模型和spark大體相同。flink的定點相當於spark中的階段，將操作符劃分為定點的過程和上圖中在spark dag中劃分為stage的過程基本相同。
相比之下，flink的基本資料模型由資料流組成，例如事件序列。資料流作為資料的基本模型，可能不如表或資料塊那樣直觀和熟悉，但仍然可以提供一組完全等效的特性。人們普遍認為資料流是沒有邊界的，但它也可以是乙個有邊界的有限流，處理這些流相當於批處理。
為了描述資料處理過程，flink在資料流上使用操作符，每個操作符生成乙個新的資料流。從操作符、dag和上下游操作符的鏈結來看，整體模型和spark大體相同。flink的定點相當於spark中的階段，將操作符劃分為定點的過程和上圖中在spark dag中劃分為stage的過程基本相同。
實時資料流處理和批處理的主要區別在於低延遲要求。spark rdd是基於記憶體的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小資料塊就可以實現低延遲。
如果所有的資料都在記憶體中並且處理速度足夠快，spark還可以支援互動式查詢。
spark的機器學習和圖形計算可以看作是不同類別的rdd操作符。spark提供了支援公共操作的庫，使用者或第三方也可以擴充套件和提供更多的操作。值得一提的是，spark的rdd模型與機器學習模型訓練過程中的迭代計算非常相容。從一開始，它就在某些場景中帶來了顯著的效能改進。
基於這些特性，spark本質上是乙個基於記憶體的批處理程式。它比hadoop mapreduce更快，並且能使用足夠快的批處理來實現各種場景。
實時資料流處理和批處理的主要區別在於低延遲要求。spark rdd是基於記憶體的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小資料塊就可以實現低延遲。
如果所有的資料都在記憶體中並且處理速度足夠快，spark還可以支援互動式查詢。
spark的機器學習和圖形計算可以看作是不同類別的rdd操作符。spark提供了支援公共操作的庫，使用者或第三方也可以擴充套件和提供更多的操作。值得一提的是，spark的rdd模型與機器學習模型訓練過程中的迭代計算非常相容。從一開始，它就在某些場景中帶來了顯著的效能改進。
基於這些特性，spark本質上是乙個基於記憶體的批處理程式。它比hadoop mapreduce更快，並且能使用足夠快的批處理來實現各種場景。
flink另乙個非常獨特的方面是在引擎中引入了託管狀態。為了理解託管狀態，我們必須先從狀態處理開始。如果處理事件（或資料塊）的結果只與事件本身的內容相關，則稱為無狀態處理; 如果結果與先前處理的事件相關，稱為有狀態處理。任何重要的資料處理，如基本聚合，都是有狀態的處理。flink社群一直堅信，沒有良好的狀態支援，就不會有有效的流，因此，在早期引入了託管狀態和狀態api。
通常在流的情景中考慮狀態處理，但仔細觀察狀態處理，它也會影響批處理。以視窗聚合的常見情況為例，如果批量資料週期大於視窗，中間狀態可以忽略，使用者邏輯往往會忽略這個問題。但是，當批量資料週期小於視窗時，批處理的結果實際上依賴以前處理過的批。由於批處理引擎通常看不到這個需求，它們通常不提供內建的狀態支援，需要使用者手動維護狀態。例如在視窗聚合的情況下，使用者需要乙個中間結果表來儲存不完整視窗的結果。因此，當使用者縮短批處理週期時，處理邏輯變得更加複雜。在結構化流發布之前，這是早期spark流使用者的常見問題。
另一方面，flink作為乙個流引擎，從一開始就必須面對這個問題，並將託管狀態作為乙個通用的解決方案引入。除了讓使用者的工作更容易之外，與使用者實現的解決方案相比，內建的解決方案還可以獲得更好的效能。最重要的是，它可以提供更好的一致性保證。
簡單地說，資料處理邏輯本身就會存在一些問題，這些問題在批處理中可以忽略或簡化，而不會影響結果，但在流處理中則會暴露，需要加以解決。流引擎中主要通過在特定的區域進行專門的處理以便進行優化，這樣以有限流的形式實現批處理，可以自然而然地得到正確地結果。相反，小批量的模擬流則意味著會暴露出新的問題。當批處理計算引擎沒有這個問題的通用解決方案時，它需要使用者自己解決。除了狀態處理問題以外，還包括維度表更改（更新使用者資訊）、批處理資料邊界、資料延遲到達等。
spark的初衷之一是提供乙個統一的程式設計模型，能夠解決不同使用者的各種需求，它為之付出了巨大的努力。spark基於rdd的初始api已經能夠完成各種資料處理。隨後為了簡化使用者的開發，在spark 2.0(dateframe=dataset[row])中引入了更高階別的資料幀（在rdd中向結構化資料新增列）和資料集（新增dateframe列型別），它也較早地引入了spark sql支援。隨著特定場景api的持續改進，如結構化流**和整合機器學習、深度學習，spark的api變得非常容易使用，現在已經成為框架最強大的方面之一。
flink的api也遵循一套類似的目標和開發路徑，因此，flink和spark的核心api在功能上大體能夠對應上。現在，根據過去兩年機器學習和深度學習的整合，spark的api總體上更加完整，flink則在流處理相關方面仍然領先，比如它支援水位線（watermark）、視窗和觸發器。
spark和flink都是通用計算引擎，支援大規模資料處理和各種型別的資料處理，每乙個都有很多值得探索的地方，例如sql優化和機器學習整合。本文比較的主要目的是回顧兩個系統的基本架構和設計特點。理論上，更切實際的做法是通過相互學習來跟上場景所需的上層功能發展，但改變基礎設計的成本更大，令人望而卻步。
Flink和spark的對比
兩者最重要的區別 流和微批 micro batching計算模式認為 流是批的特例 流計算就是將連續不斷的微批進行持續計算，如果批足夠小那麼就有足夠小的延時，在一定程度上滿足了99 的實時計算場景。那麼那1 為啥做不到呢?這就是架構的魅力，在micro batching模式的架構實現上就有乙個自然流...
spark與storm的對比
對比點 storm spark streaming 實時計算模型 純實時，來一條資料，處理一條資料 準實時，對乙個時間段內的資料收集起來，作為乙個rdd，再處理 實時計算延遲度 毫秒級 秒級 吞吐量 低 高 事務機制 支援完善 支援，但不夠完善 健壯性 容錯性 zookeeper，acker，非常強...
spark與storm的對比
對比點 storm spark streaming 實時計算模型 純實時，來一條資料，處理一條資料 準實時，對乙個時間段內的資料收集起來，作為乙個rdd，再處理 實時計算延遲度 毫秒級 秒級 吞吐量 低 高事務機制 支援完善 支援，但不夠完善 健壯性 容錯性 zookeeper，acker，非常強 ...