這四個項目能放在一起比較的背景應該是分布式計算的演進過程。
一、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