作者：ezaya
鏈接：https://www.zhihu.com/question/403840013/answer/1317631316
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

目錄

一、MapReduce

二、Spark

三、Flink & Storm

四、總結(jié)

---

這四個(gè)項(xiàng)目能放在一起比較的背景應(yīng)該是分布式計(jì)算的演進(jìn)過程。

一、MapReduce

開源分布式計(jì)算的第一個(gè)流行的框架是 Hadoop 項(xiàng)目中的 MapReduce 模塊。它將所有計(jì)算抽象成 Map 和 Reduce 兩個(gè)階段，在計(jì)算時(shí)通過增加機(jī)器，并行的讀取數(shù)據(jù)文件，進(jìn)行 Map 或 Reduce 的操作，并將結(jié)果寫到文件中。如此反復(fù)得到最終的結(jié)果。

上面過程中，每個(gè) Map 和 Reduce 階段所能表達(dá)的計(jì)算邏輯是有限的，因此完整的業(yè)務(wù)邏輯往往包含了多個(gè)階段。注意到每個(gè)階段都有讀取數(shù)據(jù)文件和數(shù)據(jù)寫出到文件的開銷，對于同一個(gè)任務(wù)的中間結(jié)果，其唯一用途就是被下一階段讀取，且讀后就成為垃圾文件，對中間結(jié)果落盤顯然是不合理的重大開銷。

二、Spark

基于這樣的觀察，Spark 提出了內(nèi)存計(jì)算的概念，核心思想就是中間結(jié)果盡量不落盤。依靠這樣的基礎(chǔ)思想，Spark 相對 Hadoop MapReduce 獲得了千百倍的性能提升，代價(jià)是更高的內(nèi)存開銷以及 OOM 風(fēng)險(xiǎn)。經(jīng)歷過 Spark 1.x 年代的研發(fā)和運(yùn)維應(yīng)該都對此深有體會。

三、Flink & Storm

Storm 和 Flink 完全是另一個(gè)路數(shù)。我們這里討論 Flink 的流計(jì)算部分，而不討論它早年被 Spark 全方位吊打的 DataSet 批計(jì)算部分。前面討論的批計(jì)算，其特點(diǎn)是輸入數(shù)據(jù)集是事先知曉且有限的，而流計(jì)算的世界觀認(rèn)為輸入數(shù)據(jù)集是無限的消息流。因此，它們的計(jì)算邏輯處理的不是一批一批的數(shù)據(jù)，而是一條一條連綿不斷的消息。

Storm 通過產(chǎn)生數(shù)據(jù)流的源頭和消費(fèi)數(shù)據(jù)流的管道來抽象流計(jì)算的世界，Flink 的流計(jì)算部分其實(shí)大同小異。兩者最大的區(qū)別或者說 Flink 最大的優(yōu)勢是它擁有內(nèi)置的狀態(tài)管理和精確一次送達(dá)語義的容錯(cuò)機(jī)制。Flink 的官方標(biāo)語就是狀態(tài)化的流計(jì)算，因此這才是它的核心競爭力。有了內(nèi)置的狀態(tài)管理，Flink 相比 Storm 就少了對接外部狀態(tài)存儲的負(fù)擔(dān)。要知道，每次手動對接外部存儲，重復(fù)開發(fā)量是巨大的，而且涉及兩個(gè)分布式項(xiàng)目的端到端一致性保證，將變得非常復(fù)雜。

四、總結(jié)

以上就是對這四個(gè)項(xiàng)目口水化的介紹，其使用場景大抵如下。

Spark 作為批計(jì)算的王者存在，基本處理所有分布式批處理的場景。有的時(shí)候會使用 Hadoop MapReduce 是因?yàn)榇媪繕I(yè)務(wù)沒有明顯的性能瓶頸，不需要故意開發(fā)遷移。另一種情況是在沒有嚴(yán)格性能要求的情況下，減少 Spark 的部署運(yùn)維成本，簡單使用 HDFS 集群直接支持的 MapReduce 計(jì)算任務(wù)。還有一種情況是早年某些 MapReduce 作業(yè)的 DSL 的存量，傳遞依賴 MapReduce 且同樣沒有升級的強(qiáng)需求，例如 Pig 程序。

Flink 作為流計(jì)算的標(biāo)桿，基本覆蓋了阿里巴巴內(nèi)部的流計(jì)算場景。但是，在阿里強(qiáng)推之前，或者從技術(shù)上說被雙十一磨礪之前，大部分公司的偽實(shí)時(shí)需求可以通過 Spark Streaming 或者 Storm 乃至訂閱 Kafka 加消費(fèi)者任務(wù)來解決。因此市面上非 Flink 的流計(jì)算大抵是過時(shí)或者有局限性技術(shù)的存量。Flink 的核心優(yōu)勢在于內(nèi)置狀態(tài)管理以及先發(fā)優(yōu)勢帶來的較為完善的功能支持，這方面解決了流計(jì)算開箱即用的問題，以及雙十一磨礪的性能優(yōu)勢，目前仍然是流計(jì)算框架的跑分榜第一。

當(dāng)然，這些項(xiàng)目都還有其他內(nèi)容。例如 Hadoop 的 YARN 資源管理框架，Spark 跟高迭代的機(jī)器學(xué)習(xí)的整合等等。同時(shí)，外圍還有數(shù)據(jù)湖技術(shù)和 HTAP 以及其他流計(jì)算框架在爭奪這四款軟件的業(yè)務(wù)場景，那就不是這里一兩句話能說完的了。

總結(jié)

以上是生活随笔為你收集整理的分布式计算—MapReduce、Spark、Storm、Flink分别适用什么场景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。