這是數據處理引擎的發電站，它們正競相定義下一個大數據時代

當涉及到大數據時，流計算和它所帶來的實時強大分析的重要性是不可避免的。此外，當涉及到流計算時，無法避免該領域最強大的兩種數據處理引擎:Spark和Flink。

自2014年以來，Apache Spark的受歡迎程度迅速上升，在某些情況下，它的性能超過了Hadoop MapReduce的三位數，提供了一個統一的引擎，支持所有常見的數據處理場景，如批處理、流處理、交互查詢和機器學習。憑借其高性能和全面的場景支持，它在大數據開發中繼續受到早期采用者的青睞。

在Spark出現后不久，Apache Flink作為一個外部挑戰者開始進入公眾視野，直到2016年才廣為人知。早期的Spark用戶在實時流處理等場景中遇到可用性問題時，Flink提供了一個高級流處理引擎，它支持廣泛的場景以及其他優勢。

在他們短暫的競爭中，Spark一直在優化它的實時流媒體功能，2.3版本(2月份發布)引入了連續處理模型，將流處理延遲降低到毫秒。Flink同樣是一個令人敬畏的創新者，這兩種架構中哪一種將最終主導下一代大數據計算還有待觀察。

通過對它們各自技術和用途的綜合分析，本文應該有助于闡明這一問題。

大數據計算引擎的起源

Hadoop和其他基于mapreduce的數據處理系統的出現首先是為了滿足傳統數據庫無法滿足的數據處理需求。隨著2004年谷歌發布MapReduce白皮書以來的發展浪潮，利用Hadoop的開源生態系統或類似系統處理大數據已經成為行業的基本需求。

盡管最近努力降低進入門檻，但在開發自己的數據處理系統時，組織不可避免地會遇到一系列問題，常常會發現從數據中獲得價值所需的投資大大超出預期。

下面的章節將詳細介紹這些問題中最普遍的部分，這有助于解釋Spark和Flink繼續競爭行業偏好的基礎。

非常陡峭的學習曲線

剛接觸大數據的人通常會對需要掌握的技術數量感到震驚。過去幾十年發展起來的傳統數據庫一般都是為了綜合數據處理而構建的，而像Hadoop這樣的大數據生態系統需要幾個不同的子系統，每個子系統在呈現各種需求場景之前都有自己的專長和優勢。

上面的圖片描述了一個典型的lambda架構。僅僅展示了兩種場景(批處理和流處理)，它已經涉及了至少四到五種技術，不包括經常需要考慮的替代方案。通過添加實時查詢、交互分析、機器學習和其他場景，每種情況都涉及到以不同方式覆蓋重疊區域的幾種技術之間的選擇。因此，業務通常需要使用許多技術來支持完整的數據處理。再加上研究和選擇，投資者需要消化的信息量是巨大的。

為了了解可用的技術，請考慮以下對大數據行業的概述。

開發運營效率低下

由于涉及的系統種類繁多，每個系統都有自己的開發工具和語言，大數據的開發效率在默認情況下相當有限。由于數據需要在多個系統之間傳輸，進一步的開發和操作成本不可避免地會出現。同時，數據一致性仍然難以保證。

在許多組織中，超過一半的開發工作花費在系統之間的數據傳輸上。

操作復雜、數據質量等問題

多個系統，每個系統都需要自己的操作和維護，帶來較高的運行成本，增加系統出錯的可能性。此外，很難保證數據的質量，而且當問題確實出現時，很難跟蹤和解決它們。

最后但并非最不重要的，還有人的問題。在許多情況下，系統的復雜性意味著對每個子系統的支持和使用必須在不同的部門中實現，這些部門并不總是與目標和優先級保持一致。

到一個解決方案

鑒于這些問題，不難理解Spark的受歡迎程度。在其2014年崛起之時，Spark不僅增強了Hadoop MapReduce的性能，而且還提供了一個通用引擎來支持各種數據處理場景。在一個筆記本中看到一個Spark演示程序與上述所有場景一起工作，對于許多開發人員來說，轉向Spark是一個相對容易的決定。因此，Spark作為Hadoop中的MapReduce引擎的完全替代品出現也就不足為奇了。

與此同時，Flink的出現是為了在一系列場景中提供更方便的使用，特別是在數據流的實時處理方面。

隨著競賽領域的建立，下面的部分將在技術層面上比較這兩種競爭的框架。

在Spark和Flink中處理引擎

本節重點討論Spark和Flink引擎的架構特性，重點討論它們架構的潛力和局限性。和它們的數據和處理模型一樣，它們在數據處理場景、有狀態處理方法和編程模型中的重點是不同的。

數據模型和處理模型

要了解Spark和Flink中的引擎特性，首先必須檢查它們各自的數據模型。

Spark使用彈性分布式數據集(RDD)數據模型。RDD比MapReduce的文件模型更抽象，它依賴沿襲來確保可恢復性。RDD通常可以實現為分布式共享內存或完全虛擬化。這就是說，當下游處理完全是本地的時候，可以優化和省略某些中間結果RDD。這節省了大量不必要的輸入和輸出，這是Spark早期性能優勢的主要基礎。

Spark還在RDD上使用轉換(操作符)來描述數據處理。每個操作符(如map、filter、join)都會生成一個新的RDD。所有的算子一起構成一個有向無環圖(DAG)。Spark簡單地將邊緣劃分為寬依賴項和窄依賴項。當上游和下游數據不需要洗牌時，邊緣是一個狹窄的依賴項。在這種情況下，上游和下游算子可以在同一階段進行本地處理，可以省去上游結果RDD的物化。下圖顯示了所涉及的基本概念。

相比之下，Flink的基本數據模型是由數據流組成的。，事件的順序。作為數據的基本模型，數據流可能不像表或數據塊那樣直觀和熟悉，但仍然可以提供一組完全等價的特性。一條小溪可以是一條無限的小溪，是無限的，這是普遍的感知。它也可以是有邊界的有限流，處理這些流等同于批處理。

為了描述數據處理，Flink在數據流上使用操作符，每個操作符生成一個新的數據流。在運營商、DAGs和上下游運營商鏈方面，整個模型與Spark模型大致相同。Flink的頂點與Spark中的階段大致相同，將操作符劃分為頂點與上圖中Spark DAG中的劃分階段基本相同。

Spark和Flink在DAG執行方面有一個顯著的區別。在Flink的流執行模式中，在一個節點上處理后的事件輸出可以發送到下一個節點進行立即處理。這樣執行引擎就不會引入任何額外的延遲。相應地，所有節點需要同時運行。相反，Spark的微批處理執行與正常的批處理執行沒有區別，只有在上游階段完成微批處理后，下游階段才開始處理其輸出。

在Flink的流執行模式中，可以一起傳輸或計算多個事件以提高效率。然而，這純粹是執行引擎自行決定的優化。它可以獨立地為每個操作符確定，并且不像批處理模型中那樣綁定到數據集(如RDD)的任何邊界。它可以為優化留下靈活性，同時滿足低延遲需求。

Flink使用異步檢查點機制來實現任務狀態的可恢復性，以確保處理一致性。因此，可以消除數據源和輸出之間的整個主處理路徑上的I/O延遲，從而實現更高的性能和更低的延遲。

數據處理方案

除了批處理，Spark還支持實時數據流處理、交互式查詢、機器學習和圖形計算等場景。

實時數據流處理和批處理之間的主要區別是低延遲要求。因為Spark RDD是基于內存的，所以可以很容易地將其切割成更小的塊進行處理。快速處理這些小塊可以實現低延遲。

如果所有數據都在內存中并且處理速度足夠快，Spark還可以支持交互式查詢。

Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了一些庫來支持常見的操作，用戶或第三方庫還可以擴展并提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練的迭代計算非常兼容。從一開始，它就在一些場景中帶來了顯著的性能改進。

基于這些特性，Spark本質上是一個比Hadoop MapReduce更快的基于內存的批處理程序，它使用足夠快的批處理來實現各種場景。

在Flink中，如果輸入數據流是有界的，則批處理的效果自然會產生。流處理和批處理之間的區別僅在于輸入類型，并且獨立于底層實現和優化，因此用戶需要實現的邏輯是完全相同的，從而產生一種更清晰的抽象。

Flink還提供了一些庫來支持機器學習和圖形計算等場景。在這方面，它與Spark并沒有太大的區別。

值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分布式服務。一些公司使用Flink集群來實現社交網絡、web爬行和其他服務。這些用途反映了Flink作為通用計算引擎的多功能性，并得益于Flink的內置狀態支持。

通常，Spark和Flink的目標都是在單個執行引擎中支持大多數數據處理場景，并且都應該能夠實現這一點。主要的區別在于，在某些場景中，它們各自的體系結構可能會受到限制。這種情況的一個值得注意的地方是Spark流的微批處理執行模式。Spark社區應該已經意識到這一點，并且最近開始致力于持續處理。我們稍后會回到這個問題。

有狀態的處理

Flink的另一個非常獨特的方面是在引擎中引入了托管狀態。要理解托管狀態，我們必須首先從有狀態處理開始。如果處理事件(或數據片段)的結果只與事件本身的內容相關，則稱為無狀態處理;否則，結果與之前處理的事件相關，稱為有狀態處理。任何重要的數據處理，例如基本聚合，通常都是有狀態處理。Flink一直認為，如果沒有良好的狀態支持，就不會有有效的流，因此，托管狀態和狀態API很早就被引入了。

通常，有狀態處理是在流的上下文中考慮的，但是仔細看看它也會影響批處理。以窗口聚合的常見情況為例，如果批處理數據周期大于窗口，則可以忽略中間狀態，用戶邏輯容易忽略這個問題。然而，當批處理周期小于窗口時，批處理的結果實際上依賴于之前處理過的批處理。因為批處理引擎通常看不到這種需求，所以它們通常不提供內置狀態支持，需要用戶手動維護狀態。例如，在窗口聚合的情況下，用戶將需要一個中間結果表來存儲不完整窗口的結果。因此，當用戶縮短批處理周期時，處理邏輯就變得更加復雜。在結構化流發布之前，這是早期Spark流用戶的一個常見問題。

另一方面，作為流媒體引擎的Flink從一開始就必須面對這個問題，并引入了托管狀態作為通用解決方案。除了簡化用戶的工作之外，與用戶實現的解決方案相比，內置解決方案還可以實現更好的性能。最重要的是，它可以提供更好的一致性保證。

簡單地說，數據處理邏輯中存在一些固有的問題，在批處理中可以忽略或簡化而不影響結果，但在流處理中會暴露并解決這些問題。因此，在流引擎中以有限流的形式實現批處理，自然會產生正確的結果，而主要的工作是為了優化而在某些領域進行專門的實現。相反，小批量模擬流場則會暴露出新的問題。當計算引擎沒有一個問題的通用解決方案時，它需要用戶自己解決它。除了狀態之外，問題還包括維度表更改(如更新用戶信息)、批處理數據邊界、延遲到達的數據等等。

編程模型

Spark最初的意圖之一是提供一個統一的編程模型，能夠解決不同用戶的各種需求——這是它投入了大量精力的一個重點。Spark最初的基于rd的API已經能夠進行各種數據處理。后來，為了簡化用戶的開發，在Spark 2.0 (DataFrame = Dataset [Row])中引入并整合了更高級別的DataFrame(在RDD中向結構化數據中添加列)和Dataset(向DataFrame列添加類型)。Spark SQL支持也相對較早地引入。隨著特定于場景的api的不斷改進，比如結構化流以及與機器學習和深度學習的集成，Spark的api變得非常容易使用，現在已經成為該框架最強大的方面之一。

Flink的API遵循了一組類似的目標和開發路徑。Flink和Spark的核心api可以看作是粗略的對應。在過去的兩年里，通過對機器學習和深度學習的集成，Spark的API總體上更加完整。Flink仍然領先于流相關方面，例如它對水印、窗口和觸發器的支持。

要點

Spark和Flink都是通用計算引擎，支持非常大規模的數據處理和各種類型的處理。每一篇文章都提供了很多這里沒有涉及的內容，比如SQL優化和機器學習集成。這種比較的主要目的是回顧這兩個系統的基本架構和設計特性。其基本原理是，更實際的做法是通過協作學習來趕上更高級別的功能，而在基本設計中進行更改往往代價更大，也更令人望而卻步。

Spark和Flink不同的執行模型之間的最大區別在于它們對流處理的支持。最初Spark流處理的方法過于簡單，在更復雜的處理中出現了問題。Spark 2.0中引入的結構化流，清理了流語義，并增加了對事件時處理和端到端一致性的支持。盡管在功能方面仍有許多限制，但它在過去的迭代中取得了相當大的進展。微批處理執行方法仍然存在一些問題，特別是在大范圍內的性能問題。最近，由于應用程序要求開發一種連續處理模式，Spark受到了刺激。2.3版的實驗性版本只支持簡單的類地圖操作。

在最近的Spark+AI峰會上的更新之后，連續處理似乎已經發展成為一個與Flink的流處理模型非常相似的執行引擎。然而，如上圖所示，主要功能仍在繼續發展。它們的性能如何，以及將來如何與Spark原來的批處理執行引擎集成，還有待觀察。