這四個專案能放在一起比較的背景應該是分散式計算的演進過程。

一、MapReduce
開源分散式計算的第一個流行的框架是 Hadoop 專案中的 MapReduce 模組。它將所有計算抽象成 Map 和 Reduce 兩個階段，在計算時通過增加機器，並行的讀取資料檔案，進行 Map 或 Reduce 的操作，並將結果寫到檔案中。如此反覆得到最終的結果。

上面過程中，每個 Map 和 Reduce 階段所能表達的計算邏輯是有限的，因此完整的業務邏輯往往包含了多個階段。注意到每個階段都有讀取資料檔案和資料寫出到檔案的開銷，對於同一個任務的中間結果，其唯一用途就是被下一階段讀取，且讀後就成為垃圾檔案，對中間結果落盤顯然是不合理的重大開銷。

二、Spark
基於這樣的觀察，Spark 提出了記憶體計算的概念，核心思想就是中間結果儘量不落盤。依靠這樣的基礎思想，Spark 相對 Hadoop MapReduce 獲得了千百倍的效能提升，代價是更高的記憶體開銷以及 OOM 風險。經歷過 Spark 1.x 年代的研發和運維應該都對此深有體會。

三、Flink & Storm
Storm 和 Flink 完全是另一個路數。我們這裡討論 Flink 的流計算部分，而不討論它早年被 Spark 全方位吊打的 DataSet 批計算部分。前面討論的批計算，其特點是輸入資料集是事先知曉且有限的，而流計算的世界觀認為輸入資料集是無限的訊息流。因此，它們的計算邏輯處理的不是一批一批的資料，而是一條一條連綿不斷的訊息。

Storm 通過產生資料流的源頭和消費資料流的管道來抽象流計算的世界，Flink 的流計算部分其實大同小異。兩者最大的區別或者說 Flink 最大的優勢是它擁有內建的狀態管理和精確一次送達語義的容錯機制。Flink 的官方標語就是狀態化的流計算，因此這才是它的核心競爭力。有了內建的狀態管理，Flink 相比 Storm 就少了對接外部狀態儲存的負擔。要知道，每次手動對接外部儲存，重複開發量是巨大的，而且涉及兩個分散式專案的端到端一致性保證，將變得非常複雜。

四、總結
以上就是對這四個專案口水化的介紹，其使用場景大抵如下。

Spark 作為批計算的王者存在，基本處理所有分散式批處理的場景。有的時候會使用 Hadoop MapReduce 是因為存量業務沒有明顯的效能瓶頸，不需要故意開發遷移。另一種情況是在沒有嚴格效能要求的情況下，減少 Spark 的部署運維成本，簡單使用 HDFS 叢集直接支援的 MapReduce 計算任務。還有一種情況是早年某些 MapReduce 作業的 DSL 的存量，傳遞依賴 MapReduce 且同樣沒有升級的強需求，例如 Pig 程式。

Flink 作為流計算的標杆，基本覆蓋了阿里巴巴內部的流計算場景。但是，在阿里強推之前，或者從技術上說被雙十一磨礪之前，大部分公司的偽實時需求可以通過 Spark Streaming 或者 Storm 乃至訂閱 Kafka 加消費者任務來解決。因此市面上非 Flink 的流計算大抵是過時或者有侷限性技術的存量。Flink 的核心優勢在於內建狀態管理以及先發優勢帶來的較為完善的功能支援，這方面解決了流計算開箱即用的問題，以及雙十一磨礪的效能優勢，目前仍然是流計算框架的跑分榜第一。

當然，這些專案都還有其他內容。例如 Hadoop 的 YARN 資源管理框架，Spark 跟高迭代的機器學習的整合等等。同時，外圍還有資料湖技術和 HTAP 以及其他流計算框架在爭奪這四款軟體的業務場景，那就不是這裡一兩句話能說完的了。

ps: 這四個框架都是用的actor架構
————————————————
版權宣告：本文為CSDN博主「測試狗一枚」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/sanmi8276/article/details/113839944