'尋找數據統治力：比較Spark和Flink'
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的物化，下圖呈現了這裡涉及的基本概念。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
Flink另一個非常獨特的方面是在引擎中引入了託管狀態。為了理解託管狀態，我們必須先從狀態處理開始。如果處理事件（或數據塊）的結果只與事件本身的內容相關，則稱為無狀態處理; 如果結果與先前處理的事件相關，稱為有狀態處理。任何重要的數據處理，如基本聚合，都是有狀態的處理。Flink社區一直堅信，沒有良好的狀態支持，就不會有有效的流，因此，在早期引入了託管狀態和狀態API。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
Flink另一個非常獨特的方面是在引擎中引入了託管狀態。為了理解託管狀態，我們必須先從狀態處理開始。如果處理事件（或數據塊）的結果只與事件本身的內容相關，則稱為無狀態處理; 如果結果與先前處理的事件相關，稱為有狀態處理。任何重要的數據處理，如基本聚合，都是有狀態的處理。Flink社區一直堅信，沒有良好的狀態支持，就不會有有效的流，因此，在早期引入了託管狀態和狀態API。
通常在流的情景中考慮狀態處理，但仔細觀察狀態處理，它也會影響批處理。以窗口聚合的常見情況為例，如果批量數據週期大於窗口，中間狀態可以忽略，用戶邏輯往往會忽略這個問題。但是，當批量數據週期小於窗口時，批處理的結果實際上依賴以前處理過的批。由於批處理引擎通常看不到這個需求，它們通常不提供內置的狀態支持，需要用戶手動維護狀態。例如在窗口聚合的情況下，用戶需要一箇中間結果表來存儲不完整窗口的結果。因此，當用戶縮短批處理週期時，處理邏輯變得更加複雜。在結構化流發佈之前，這是早期Spark流用戶的常見問題。
另一方面，Flink作為一個流引擎，從一開始就必須面對這個問題，並將託管狀態作為一個通用的解決方案引入。除了讓用戶的工作更容易之外，與用戶實現的解決方案相比，內置的解決方案還可以獲得更好的性能。最重要的是，它可以提供更好的一致性保證。
簡單地說，數據處理邏輯本身就會存在一些問題，這些問題在批處理中可以忽略或簡化，而不會影響結果，但在流處理中則會暴露，需要加以解決。流引擎中主要通過在特定的區域進行專門的處理以便進行優化，這樣以有限流的形式實現批處理，可以自然而然地得到正確地結果。相反，小批量的模擬流則意味著會暴露出新的問題。當批處理計算引擎沒有這個問題的通用解決方案時，它需要用戶自己解決。除了狀態處理問題以外，還包括維度表更改（更新用戶信息）、批處理數據邊界、數據延遲到達等。
編程模型
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
Flink另一個非常獨特的方面是在引擎中引入了託管狀態。為了理解託管狀態，我們必須先從狀態處理開始。如果處理事件（或數據塊）的結果只與事件本身的內容相關，則稱為無狀態處理; 如果結果與先前處理的事件相關，稱為有狀態處理。任何重要的數據處理，如基本聚合，都是有狀態的處理。Flink社區一直堅信，沒有良好的狀態支持，就不會有有效的流，因此，在早期引入了託管狀態和狀態API。
通常在流的情景中考慮狀態處理，但仔細觀察狀態處理，它也會影響批處理。以窗口聚合的常見情況為例，如果批量數據週期大於窗口，中間狀態可以忽略，用戶邏輯往往會忽略這個問題。但是，當批量數據週期小於窗口時，批處理的結果實際上依賴以前處理過的批。由於批處理引擎通常看不到這個需求，它們通常不提供內置的狀態支持，需要用戶手動維護狀態。例如在窗口聚合的情況下，用戶需要一箇中間結果表來存儲不完整窗口的結果。因此，當用戶縮短批處理週期時，處理邏輯變得更加複雜。在結構化流發佈之前，這是早期Spark流用戶的常見問題。
另一方面，Flink作為一個流引擎，從一開始就必須面對這個問題，並將託管狀態作為一個通用的解決方案引入。除了讓用戶的工作更容易之外，與用戶實現的解決方案相比，內置的解決方案還可以獲得更好的性能。最重要的是，它可以提供更好的一致性保證。
簡單地說，數據處理邏輯本身就會存在一些問題，這些問題在批處理中可以忽略或簡化，而不會影響結果，但在流處理中則會暴露，需要加以解決。流引擎中主要通過在特定的區域進行專門的處理以便進行優化，這樣以有限流的形式實現批處理，可以自然而然地得到正確地結果。相反，小批量的模擬流則意味著會暴露出新的問題。當批處理計算引擎沒有這個問題的通用解決方案時，它需要用戶自己解決。除了狀態處理問題以外，還包括維度表更改（更新用戶信息）、批處理數據邊界、數據延遲到達等。
編程模型
Spark的初衷之一是提供一個統一的編程模型，能夠解決不同用戶的各種需求，它為之付出了巨大的努力。Spark基於RDD的初始API已經能夠完成各種數據處理。隨後為了簡化用戶的開發，在Spark 2.0(dateframe=dataset[row])中引入了更高級別的數據幀（在RDD中向結構化數據添加列）和數據集（添加dateframe列類型），它也較早地引入了Spark SQL支持。隨著特定場景API的持續改進，如結構化流媒體和集成機器學習、深度學習，Spark的API變得非常容易使用，現在已經成為框架最強大的方面之一。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
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）、窗口和觸發器。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
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優化和機器學習集成。本文比較的主要目的是回顧兩個系統的基本架構和設計特點。理論上，更切實際的做法是通過相互學習來跟上場景所需的上層功能發展，但改變基礎設計的成本更大，令人望而卻步。
Spark和Flink執行模型的最大區別在於對流處理的支持。最初，Spark流處理方法過於簡單，導致在更復雜的處理中出現問題。Spark 2.0中引入的結構化流，不再使用流語義，增加了對時間事件（event-time）的處理和端到端一致性的支持。儘管Spark在功能方面仍然有許多限制，但在過去的迭代中已經取得了相當大的進展。微批執行方法的問題仍然存在，尤其是大規模數據處理的性能問題。近年來，Spark為應對應用需求，推出一種持續處理的模式，在2.3的實驗版中只能支持簡單的類似於map操作。
大數據文摘授權轉載自數據派THU
作者：王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時，我們無法忽視流式計算的重要性，它能夠完成強大的實時分析。而說起流式計算，我們也無法忽視最強大的數據處理引擎：Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎，如批處理、流處理、交互式查詢和機器學習。在某些情況下，它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持，它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久，Apache Flink就作為強勁對手進入公眾視野，並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時，Flink提供了一個支持各種場景的高級流處理引擎，Flink的優勢還不僅僅於此。
在這場短暫的競爭中，Spark在持續優化它的實時流處理能力，2.3版（2月份）中引入了一個持續流處理模型，將流處理延遲降至毫秒級。同樣，Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流，這還有待觀察。
為了闡明這個問題，本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初，Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統數據庫能力以外的數據處理需求。2004年穀歌發佈MapReduce白皮書以來的發展浪潮，利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降，但公司在開發自己的數據處理系統時，還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題，這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中，開發的傳統數據庫通常都是為了廣泛的數據處理而構建的（技術不多），但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統（技術相對較多），原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。
上圖展示的是一個典型的Lambda架構，儘管只包括了2個場景（批處理和流處理），但它涉及到4至5項技術，還不包括經常要考慮的備選技術方案。加上實時查詢、交互分析、機器學習等場景，每個場景都涉及在多個技術之間進行選擇，這些技術以不同的方式疊加使用。因此，企業通常要用多種技術來支持完整的數據處理。再加上最初的技術研究和選擇，投資者需要消化的信息量是巨大的。
下面這張大數據行業技術概覽圖可以幫助你瞭解相關的可用技術。
開發和運維低效
由於涉及的系統種類繁多，並且每個系統都有自己的開發工具和編程語言，因此默認情況下，大數據的開發效率非常受限。由於數據需要在多個系統之間傳輸，這不可避免地會增加開發和運維成本。同時，我們也難以保證數據一致性。
在大多數企業中，超過一半的開發時間都花在了系統間的數據傳輸上。
操作複雜、數據質量等問題
每個系統都需要自己獨特的操作和運維，這不僅會帶來更高的操作成本，也會增加系統出錯的可能性。此外，我們很難保證數據的質量。而且當這些問題出現時，跟蹤和解決問題也很困難。
除此之外，人也是不可忽視的問題。在許多情況下，系統的複雜性意味著要在不同部門之間實現每個子系統的支持和使用，但這些部門並不總是有一致的目標和優先級。
提出解決方案
基於這些問題，我們可以更理解Spark受歡迎的原因。2014年，Spark不僅推出了提升Hadoop MapReduce性能的增強功能，還推出了一個支持全方位數據處理場景的通用引擎。如此一來，上面提及的所有場景在同一個notebook中一起運行。看到這樣一個Spark Demo，開發人員都會有所心動。毫無疑問，Spark已經完全取代了Hadoop中的MapReduce引擎。
與此同時，Flink的出現為一系列場景提供了更大的易用性，特別是在數據流的實時處理中。
在這樣的競爭背景下，以下各章節將從技術層面比較這2個框架。
Spark和Flink處理引擎
本章節重點介紹Spark和Flink引擎的體系結構特性（潛力和侷限性）。除了數據和處理模型不同以外，這兩個引擎在數據處理場景、狀態處理方法和編程模型的側重點也不相同。
數據模型和處理模型
為了理解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的過程基本相同。
Spark和Flink在DAG執行上有一個顯著的區別，在Flink的流執行模式中，事件在一個節點上處理後的輸出可以發送到下一個節點進行即時處理，這樣，執行引擎就不會有任何的延遲。相應地，所有的節點都需要同時運行。相反，Spark的微批量執行和其正常的批量執行沒有區別，因為只有在上游階段完成微批量處理之後，下游階段才開始處理其輸出。
數據處理場景
除了批處理之外，Spark還支持實時數據流處理、交互查詢、機器學習和圖形計算等場景。
實時數據流處理和批處理的主要區別在於低延遲要求。Spark RDD是基於內存的，可以很容易地將其切割成更小的塊進行處理，快速處理這些小數據塊就可以實現低延遲。
如果所有的數據都在內存中並且處理速度足夠快，Spark還可以支持交互式查詢。
Spark的機器學習和圖形計算可以看作是不同類別的RDD操作符。Spark提供了支持公共操作的庫，用戶或第三方也可以擴展和提供更多的操作。值得一提的是，Spark的RDD模型與機器學習模型訓練過程中的迭代計算非常兼容。從一開始，它就在某些場景中帶來了顯著的性能改進。
基於這些特性，Spark本質上是一個基於內存的批處理程序。它比Hadoop MapReduce更快，並且能使用足夠快的批處理來實現各種場景。
在Flink中，如果輸入數據流是有邊界的，那麼批處理結果會自然而然地生成。流處理和批處理之間的區別僅在於輸入類型，與底層的實現和優化無關，因此用戶需要實現的邏輯是完全相同的，從而產生更清晰的抽象。
Flink還提供支持機器學習和圖形計算等場景的庫，在這方面，它和Spark沒有什麼不同。
值得注意的是，Flink的低級API可以單獨使用Flink集群來實現一些數據驅動的分佈式服務。一些公司使用Flink集群來實現社交網絡、網絡爬蟲和其他服務，這些應用反映了Flink作為通用計算引擎的多功能性，並受益於Flink內置的狀態支持。
一般來說，Spark和Flink的目標都是支持單個執行引擎中的大數據處理場景，並且兩者都應該能夠實現。兩者主要的區別在於：在某些場景中，每個架構都有一定的限制。其中，一個值得注意的地方是Spark Streaming的微批量執行模式，Spark社區應該已經意識到這一點，最近開始致力於研究持續處理模型，我們稍後再談。
狀態處理
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優化和機器學習集成。本文比較的主要目的是回顧兩個系統的基本架構和設計特點。理論上，更切實際的做法是通過相互學習來跟上場景所需的上層功能發展，但改變基礎設計的成本更大，令人望而卻步。
Spark和Flink執行模型的最大區別在於對流處理的支持。最初，Spark流處理方法過於簡單，導致在更復雜的處理中出現問題。Spark 2.0中引入的結構化流，不再使用流語義，增加了對時間事件（event-time）的處理和端到端一致性的支持。儘管Spark在功能方面仍然有許多限制，但在過去的迭代中已經取得了相當大的進展。微批執行方法的問題仍然存在，尤其是大規模數據處理的性能問題。近年來，Spark為應對應用需求，推出一種持續處理的模式，在2.3的實驗版中只能支持簡單的類似於map操作。
根據Spark+AI峰會提供的最新進展，持續處理似乎可以發展成為一個執行引擎，與Flink的流處理模型非常相似。然而，如上圖所示，其主要功能仍在不斷髮展，這些功能的性能表現如何以及將來Spark的原始批處理執行引擎如何集成，仍需觀察。
本文作者王海濤，最初發表於阿里巴巴的Flink系列。