MapReduce、Spark、Storm、Flink 簡單掃盲

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

一、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架構

————————————————