今天看到一篇講得比較清晰的框架對比，這幾個框架的選擇對於初學分散式運算的人來說確實有點迷茫，相信看完這篇文章之後應該能有所收穫。

簡介

大資料是收集、整理、處理大容量資料集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理資料所需的計算能力或儲存容量早已超過一臺計算機的上限，但這種計算型別的普遍性、規模，以及價值在最近幾年才經歷了大規模擴充套件。

在之前的文章中，我們曾經介紹過有關大資料系統的常規概念、處理過程，以及各種專門術語，本文將介紹大資料系統一個最基本的元件：處理框架。處理框架負責對系統中的資料進行計算，例如處理從非易失儲存中讀取的資料，或處理剛剛攝入到系統中的資料。資料的計算則是指從大量單一資料點中提取資訊和見解的過程。

下文將介紹這些框架：

• 僅批處理框架：
  • Apache Hadoop
• 僅流處理框架：
  • Apache Storm
  • Apache Samza
• 混合框架：
  • Apache Spark
  • Apache Flink

大資料處理框架是什麼？

處理框架和處理引擎負責對資料系統中的資料進行計算。雖然“引擎”和“框架”之間的區別沒有什麼權威的定義，但大部分時候可以將前者定義為實際負責處理資料操作的元件，後者則可定義為承擔類似作用的一系列元件。

例如Apache Hadoop可以看作一種以MapReduce作為預設處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop並取代MapReduce。元件之間的這種互操作性是大資料系統靈活性如此之高的原因之一。

雖然負責處理生命週期內這一階段資料的系統通常都很複雜，但從廣義層面來看它們的目標是非常一致的：通過對資料執行操作提高理解能力，揭示出資料蘊含的模式，並針對複雜互動獲得見解。

為了簡化這些元件的討論，我們會通過不同處理框架的設計意圖，按照所處理的資料狀態對其進行分類。一些系統可以用批處理方式處理資料，一些系統可以用流方式處理連續不斷流入系統的資料。此外還有一些系統可以同時處理這兩類資料。

在深入介紹不同實現的指標和結論之前，首先需要對不同處理型別的概念進行一個簡單的介紹。

批處理系統

批處理在大資料世界有著悠久的歷史。批處理主要操作大容量靜態資料集，並在計算過程完成後返回結果。

批處理模式中使用的資料集通常符合下列特徵...

• 有界：批處理資料集代表資料的有限集合
• 持久：資料通常始終儲存在某種型別的持久儲存位置中
• 大量：批處理操作通常是處理極為海量資料集的唯一方法

批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時，必須將資料集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中資料維持自己的狀態。

需要處理大量資料的任務通常最適合用批處理操作進行處理。無論直接從持久儲存裝置處理資料集，或首先將資料集載入記憶體，批處理系統在設計過程中就充分考慮了資料的量，可提供充足的處理資源。由於批處理在應對大量持久資料方面的表現極為出色，因此經常被用於對歷史資料進行分析。

大量資料的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。

Apache Hadoop

Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社群獲得極大關注的大資料框架。基於谷歌有關海量資料處理所發表的多篇論文與經驗的Hadoop重新實現了相關演算法和元件堆疊，讓大規模批處理技術變得更易用。

新版Hadoop包含多個元件，即多個層，通過配合使用可處理批資料：

• HDFS：HDFS是一種分散式檔案系統層，可對叢集節點間的儲存和複製進行協調。HDFS確保了無法避免的節點故障發生後資料依然可用，可將其用作資料來源，可用於儲存中間態的處理結果，並可儲存計算的最終結果。
• YARN：YARN是Yet Another Resource Negotiator（另一個資源管理器）的縮寫，可充當Hadoop堆疊的叢集協調元件。該元件負責協調並管理底層資源和排程作業的執行。通過充當叢集資源的介面，YARN使得使用者能在Hadoop叢集中使用比以往的迭代方式執行更多型別的工作負載。
• MapReduce：MapReduce是Hadoop的原生批處理引擎。

批處理模式

Hadoop的處理功能來自MapReduce引擎。MapReduce的處理技術符合使用鍵值對的map、shuffle、reduce演算法要求。基本處理過程包括：

• 從HDFS檔案系統讀取資料集
• 將資料集拆分成小塊並分配給所有可用節點
• 針對每個節點上的資料子集進行計算（計算的中間態結果會重新寫入HDFS）
• 重新分配中間態結果並按照鍵進行分組
• 通過對每個節點計算的結果進行彙總和組合對每個鍵的值進行“Reducing”
• 將計算而來的最終結果重新寫入 HDFS

優勢和侷限

由於這種方法嚴重依賴持久儲存，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁碟空間通常是伺服器上最豐富的資源，這意味著MapReduce可以處理非常海量的資料集。同時也意味著相比其他類似技術，Hadoop的MapReduce通常可以在廉價硬體上執行，因為該技術並不需要將一切都儲存在記憶體中。MapReduce具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。

MapReduce的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop叢集快速實現某些應用時依然需要注意這個問題。

圍繞Hadoop已經形成了遼闊的生態系統，Hadoop叢集本身也經常被用作其他軟體的組成部件。很多其他處理框架和引擎通過與Hadoop整合也可以使用HDFS和YARN資源管理器。

總結

Apache Hadoop及其MapReduce處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的非常大規模資料集。通過非常低成本的元件即可搭建完整功能的Hadoop叢集，使得這一廉價且高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的相容與整合能力使得Hadoop可以成為使用不同技術的多種工作負載處理平臺的底層基礎。

流處理系統

流處理系統會對隨時進入系統的資料進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個資料集執行操作，而是對通過系統傳輸的每個資料項執行操作。

流處理中的資料集是“無邊界”的，這就產生了幾個重要的影響：

• 完整資料集只能代表截至目前已經進入到系統中的資料總量。
• 工作資料集也許更相關，在特定時間只能代表某個單一資料項。
• 處理工作是基於事件的，除非明確停止否則沒有“盡頭”。處理結果立刻可用，並會隨著新資料的抵達繼續更新。

流處理系統可以處理幾乎無限量的資料，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）資料，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優化。

功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個資料執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些型別的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。

此類處理非常適合某些型別的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程式錯誤日誌，以及其他基於時間的衡量指標是最適合的型別，因為對這些領域的資料變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的資料。

Apache Storm

Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的資料，通過比其他解決方案更低的延遲提供結果。

流處理模式

Storm的流處理可對框架中名為Topology（拓撲）的DAG（Directed Acyclic Graph，有向無環圖）進行編排。這些拓撲描述了當資料片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。

拓撲包含：

• Stream：普通的資料流，這是一種會持續抵達系統的無邊界資料。
• Spout：位於拓撲邊緣的資料流來源，例如可以是API或查詢等，從這裡可以產生待處理的資料。
• Bolt：Bolt代表需要消耗流資料，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連線，隨後相互連線以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連線的其他系統的輸入。

Storm背後的想法是使用上述元件定義大量小型的離散操作，隨後將多個元件組成所需拓撲。預設情況下Storm提供了“至少一次”的處理保證，這意味著可以確保每條訊息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理訊息。

為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。

為避免這些問題，通常建議Storm使用者儘可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智慧地處理重複訊息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少使用者點選了某個連結，此時Trident將是你唯一的選擇。儘管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。

Trident拓撲包含：

• 流批（Stream batch）：這是指流資料的微批，可通過分塊提供批處理語義。
• 操作（Operation）：是指可以對資料執行的批處理過程。

優勢和侷限

目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理資料，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響使用者體驗，例如需要將處理結果直接提供給訪客開啟的網站頁面，此時Storm將會是一個很好的選擇。

Storm與Trident配合使得使用者可以用微批代替純粹的流處理。雖然藉此使用者可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。

Core Storm無法保證訊息的處理順序。Core Storm為訊息提供了“至少一次”的處理保證，這意味著可以保證每條訊息都能被處理，但也可能發生重複。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。

在互操作性方面，Storm可與Hadoop的YARN資源管理器進行整合，因此可以很方便地融入現有Hadoop部署。除了支援大部分處理框架，Storm還可支援多種語言，為使用者的拓撲定義提供了更多選擇。

總結

對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條訊息都被處理，可配合多種程式語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟體。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。

Apache Samza

Apache Samza是一種與Apache Kafka訊息系統緊密繫結的流處理框架。雖然Kafka可用於很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩衝，以及狀態儲存。

Samza可使用YARN作為資源管理器。這意味著預設情況下需要具備Hadoop叢集（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。

流處理模式

Samza依賴Kafka的語義定義流的處理方式。Kafka在處理資料時涉及下列概念：

• Topic（話題）：進入Kafka系統的每個資料流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關資訊組成的資料流。
• Partition（分割槽）：為了將一個話題分散至多個節點，Kafka會將傳入的訊息劃分為多個分割槽。分割槽的劃分將基於鍵（Key）進行，這樣可以保證包含同一個鍵的每條訊息可以劃分至同一個分割槽。分割槽的順序可獲得保證。
• Broker（代理）：組成Kafka叢集的每個節點也叫做代理。
• Producer（生成方）：任何向Kafka話題寫入資料的元件可以叫做生成方。生成方可提供將話題劃分為分割槽所需的鍵。
• Consumer（消耗方）：任何從Kafka讀取話題的元件可叫做消耗方。消耗方需要負責維持有關自己分支的資訊，這樣即可在失敗後知道哪些記錄已經被處理過了。

由於Kafka相當於永恆不變的日誌，Samza也需要處理永恆不變的資料流。這意味著任何轉換建立的新資料流都可被其他元件所使用，而不會對最初的資料流產生影響。

優勢和侷限

乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。

例如Kafka已經提供了可以通過低延遲方式訪問的資料儲存副本，此外還可以為每個資料分割槽提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。

這種對Kafka的緊密依賴在很多方面類似於MapReduce引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的效能問題，但也避免了流處理遇到的很多其他問題。

Samza與Kafka之間緊密的關係使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似資料的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的資料話題，或任意訂閱其他團隊對資料進行過某些處理後建立的話題。這一切並不會對資料庫等負載密集型基礎架構造成額外的壓力。

直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致資料流入速度超過元件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失資料。按照設計，Kafka可以將資料儲存很長時間，這意味著元件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。

Samza可以使用以本地鍵值儲存方式實現的容錯檢查點系統儲存資料。這樣Samza即可獲得“至少一次”的交付保障，但面對由於資料可能多次交付造成的失敗，該技術無法對彙總後狀態（例如計數）提供精確恢復。

Samza提供的高階抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易於配合使用。目前Samza只支援JVM語言，這意味著它在語言支援方面不如Storm靈活。

總結

對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間並不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的效能。如果部署需求與當前系統不相容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。

混合處理系統：批處理和流處理

一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的元件和API處理兩種型別的資料，藉此讓不同的處理需求得以簡化。

如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不同處理模式如何進行統一，以及要對固定和不固定資料集之間的關係進行何種假設。

雖然側重於某一種處理型別的專案會更好地滿足具體用例的要求，但混合框架意在提供一種資料處理的通用解決方案。這種框架不僅可以提供處理資料所需的方法，而且提供了自己的整合項、庫、工具，可勝任圖形分析、機器學習、互動式查詢等多種任務。

Apache Spark

Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapReduce引擎基於各種相同原則開發而來的Spark主要側重於通過完善的記憶體計算和處理優化機制加快批處理工作負載的執行速度。

Spark可作為獨立叢集部署（需要相應儲存層的配合），或可與Hadoop整合並取代MapReduce引擎。

批處理模式

與MapReduce不同，Spark的資料處理工作全部在記憶體中進行，只在一開始將資料讀入記憶體，以及將最終結果持久儲存時需要與儲存層互動。所有中間態的處理結果均儲存在記憶體中。

雖然記憶體中處理方式可大幅改善效能，Spark在處理與磁碟有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可建立代表所需執行的全部操作，需要操作的資料，以及操作和資料之間關係的Directed Acyclic Graph（有向無環圖），即DAG，藉此處理器可以對任務進行更智慧的協調。

為了實現記憶體中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分散式資料集），即RDD的模型來處理資料。這是一種代表資料集，只位於記憶體中，永恆不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，並最終回溯至磁碟上的資料。Spark可通過RDD在無需將每個操作的結果寫回磁碟的前提下實現容錯。

流處理模式

流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特徵方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將資料流視作一系列非常小的“批”，藉此即可通過批處理引擎的原生語義進行處理。

Spark Streaming會以亞秒級增量對流進行緩衝，隨後這些緩衝會作為小規模的固定資料集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在效能方面依然存在不足。

優勢和侷限

使用Spark而非Hadoop MapReduce的主要原因是速度。在記憶體計算策略和先進的DAG排程等機制的幫助下，Spark可以用更快速度處理相同的資料集。

Spark的另一個重要優勢在於多樣性。該產品可作為獨立叢集部署，或與現有Hadoop叢集整合。該產品可執行批處理和流處理，執行一個叢集即可處理不同型別的任務。

除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、互動式查詢等任務提供更好的支援。相比MapReduce，Spark任務更是“眾所周知”地易於編寫，因此可大幅提高生產力。

為流處理系統採用批處理的方法，需要對進入系統的資料進行緩衝。緩衝機制使得該技術可以處理非常大量的傳入資料，提高整體吞吐率，但等待緩衝區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。

由於記憶體通常比磁碟空間更貴，因此相比基於磁碟的系統，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數為資源付費的環境中，這一特性通常可以抵消增加的成本。

Spark記憶體計算這一設計的另一個後果是，如果部署在共享的叢集中可能會遇到資源不足的問題。相比Hadoop MapReduce，Spark的資源消耗更大，可能會對需要在同一時間使用叢集的其他任務產生影響。從本質來看，Spark更不適合與Hadoop堆疊的其他元件共存一處。

總結

Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高記憶體佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。

Apache Flink

Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理資料視作具備有限邊界的資料流，藉此將批處理任務作為流處理的子集加以處理。為所有處理任務採取流處理為先的方法會產生一系列有趣的副作用。

這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構（該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果）。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後才可行的。

流處理模型

Flink的流處理模型在處理傳入資料時會將每一項視作真正的資料流。Flink提供的DataStream API可用於處理無盡的資料流。Flink可配合使用的基本元件包括：

• Stream（流）是指在系統中流轉的，永恆不變的無邊界資料集
• Operator（操作方）是指標對資料流執行操作以產生其他資料流的功能
• Source（源）是指資料流進入系統的入口點
• Sink（槽）是指資料流離開Flink系統後進入到的位置，槽可以是資料庫或到其他系統的聯結器

為了在計算過程中遇到問題後能夠恢復，流處理任務會在預定時間點建立快照。為了實現狀態儲存，Flink可配合多種狀態後端系統使用，具體取決於所需實現的複雜度和永續性級別。

此外Flink的流處理能力還可以理解“事件時間”這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味著可以通過某種有趣的方式確保執行順序和分組。

批處理模型

Flink的批處理模型在很大程度上僅僅是對流處理模型的擴充套件。此時模型不再從持續流中讀取資料，而是從持久儲存中以流的形式讀取有邊界的資料集。Flink會對這些處理模型使用完全相同的執行時。

Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久儲存加以支援，Flink可以不對批處理工作負載建立快照。資料依然可以恢復，但常規處理操作可以執行得更快。

另一個優化是對批處理任務進行分解，這樣即可在需要的時候呼叫不同階段和元件。藉此Flink可以與叢集的其他使用者更好地共存。對任務提前進行分析使得Flink可以檢視需要執行的所有操作、資料集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。

優勢和侷限

Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。

Flink的很多元件是自行管理的。雖然這種做法較為罕見，但出於效能方面的原因，該技術可自行管理記憶體，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理資料的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理資料分割槽和自動快取等操作。

Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關係型資料庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支援多階段並行執行，同時可將受阻任務的資料集合在一起。對於迭代式任務，出於效能方面的考慮，Flink會嘗試在儲存資料的節點上執行相應的計算任務。此外還可進行“增量迭代”，或僅對資料中有改動的部分進行迭代。

在使用者工具方面，Flink提供了基於Web的排程檢視，藉此可輕鬆管理任務並檢視系統狀態。使用者也可以檢視已提交任務的優化方案，藉此瞭解任務最終是如何在叢集中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支援記憶體計算。

Flink能很好地與其他元件配合使用。如果配合Hadoop 堆疊使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕鬆地與YARN、HDFS和Kafka 整合。在相容包的幫助下，Flink還可以執行為其他處理框架，例如Hadoop和Storm編寫的任務。

目前Flink最大的侷限之一在於這依然是一個非常“年幼”的專案。現實環境中該專案的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的侷限目前也沒有較為深入的研究。隨著快速開發週期的推進和相容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署。

總結

Flink提供了低延遲流處理，同時可支援傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可相容原生Storm和Hadoop程式，可在YARN管理的叢集上執行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。

結論

大資料系統可使用多種處理技術。

對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的Hadoop將會是一個好選擇。

對於僅需要流處理的工作負載，Storm可支援更廣泛的語言並實現極低延遲的處理，但預設配置可能產生重複結果並且無法保證順序。Samza與YARN和Kafka緊密整合可提供更大靈活性，更易用的多團隊使用，以及更簡單的複製和狀態管理。

對於混合型工作負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支援更完善，具備各種整合庫和工具，可實現靈活的整合。Flink提供了真正的流處理並具備批處理能力，通過深度優化可運行鍼對其他平臺編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。

最適合的解決方案主要取決於待處理資料的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種專案的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。