大數(shù)據(jù)計算引擎MapReduce、Storm、Spark、Sparkstreaming、Flink到底哪家強？

自大數(shù)據(jù)的概念被提出以來，企業(yè)對于數(shù)據(jù)信息變?yōu)閿?shù)據(jù)資產(chǎn)的訴求越來越強烈，進而在技術(shù)領域出現(xiàn)了很多大數(shù)據(jù)計算引擎服務，最著名、使用最廣的莫過于MapReduce、Storm、Spark、Sparkstreaming、Flink了。它們都是在不同的時代背景下所產(chǎn)生的，又是為了解決每個階段所不能遇到的難題而新出現(xiàn)的解決方案，那么它們到底是什么呢？我們今天一一的來看看這些計算引擎寶貝們～

從處理的時間來看，我們可以把大數(shù)據(jù)計算引擎劃分為離線計算、實時計算兩類，離線計算一般是T+1的延遲，實時計算一般是秒級或毫秒級的延遲；從處理的數(shù)據(jù)量來看，我們可以把大數(shù)據(jù)引擎劃分為流式計算、批量計算兩類，流式計算是一次來一條處理一條，批量計算則是一次來多條處理多條。MapReduce、Spark屬于離線計算、批量計算引擎，Storm、Sparkstreaming、Flink屬于實時計算、流式與批量并存的計算引擎。

給計算引擎寶貝們分好類之后，我們一個個的來看看它們的絕技。MapReduce是大數(shù)據(jù)計算引擎的開山鼻祖，自Google著名的三篇論文發(fā)表之后，大數(shù)據(jù)處理開始流行起來，很多企業(yè)都使用Hadoop三件套MapReduce、HDFS、YARN來進行大數(shù)據(jù)的處理任務，所有的數(shù)據(jù)在進行處理前會劃分成大小相同的數(shù)據(jù)，經(jīng)過Map模型初次處理數(shù)據(jù)，得到中間結(jié)果，再經(jīng)過Reduce模型二次處理中間結(jié)果數(shù)據(jù)，最后得到分析數(shù)據(jù)，存儲在HDFS。在該模型中，存在兩個問題：

1、模型簡單，對于復雜的處理任務不好支持。對于復雜的統(tǒng)計分析任務，在MR模型中就需要經(jīng)過多次轉(zhuǎn)換成中間結(jié)果，尤其是人工智能、深度學習類需要多次計算的場景就更不好使了；

2、不能有效的利用內(nèi)存，在MR模型中所生成的中間數(shù)據(jù)都是存儲在磁盤中的，每次數(shù)據(jù)進入磁盤，再從磁盤讀取出來，非常的耗費IO，時間延遲太長了。因此Spark出現(xiàn)了。

Spark是升級版的MapReduce計算引擎，在Spark中引入了RDD彈性分布式數(shù)據(jù)集（ResilientDistributedDatasets），在Spark中多個計算任務可以并在1個RDD里進行，假設我們的數(shù)據(jù)是存儲在HDFS當中，當要進行數(shù)據(jù)處理時，我們先把數(shù)據(jù)劃分成為多個大小相同的數(shù)據(jù)，一組任務是一個Stage，在Stage1階段進行Map計算，產(chǎn)生中間結(jié)果（RDD1），在Stage2階段進行Reduce計算，產(chǎn)生中間結(jié)果（RDD2），在Stage3階段再將之前階段的結(jié)果關(guān)聯(lián)起來（RDD3），最后給到Actions將RDD計算結(jié)果給到業(yè)務呈現(xiàn)。

在Spark模型中，它支持復雜的計算模型（支持多個Stage），也優(yōu)化了磁盤性能問題（每個數(shù)據(jù)集任務都被抽象成RDD進行計算，存儲在內(nèi)存中），以至于有人說Spark會取代MapReduce。在Spark模型流行了一段時間后，互聯(lián)網(wǎng)企業(yè)們對于數(shù)據(jù)的要求變得越來越高了，他們希望更快的得到數(shù)據(jù)分析結(jié)果，所以實時計算應運而生。

最先出現(xiàn)的實時計算框架是Storm，在Storm中有spout管口、bolt處理器、tuple元組的概念，spout負責從數(shù)據(jù)源接收數(shù)據(jù)tuple，按照一定的規(guī)則下放給到bolt進行處理，處理結(jié)束之后由數(shù)據(jù)庫存儲相應的結(jié)果。Storm處理模型中存在高可用和數(shù)據(jù)準確性問題，所謂高可用指的是spout節(jié)點掛掉了，數(shù)據(jù)計算任務怎么辦？

在MapReduce中數(shù)據(jù)掛掉了之后會重啟Map模型，而在Storm中也有一個對應的ACK機制，bolt接收到數(shù)據(jù)之后返回確認，處理完數(shù)據(jù)后返回確認，數(shù)據(jù)庫存儲數(shù)據(jù)后返回確認，基本要三輪確認后整個處理任務才算完成了；所謂準確性指的是數(shù)據(jù)重復處理問題，比如在數(shù)據(jù)處理過程中，處理節(jié)點bolt1處理完數(shù)據(jù)之后，發(fā)送給了接收節(jié)點bolt1，但接收節(jié)點bolt1還沒來得及確認，處理節(jié)點bolt1掛掉了，處理節(jié)點bolt2繼續(xù)重復處理bolt1的數(shù)據(jù)，從而導致在整個任務中數(shù)據(jù)是有冗余的。在Sparkstreaming中針對這兩個問題，提出了對應的解決方案。

Sparkstreaming是Spark的升級版本，在Sparkstreaming使用RDD模型將每次處理的數(shù)據(jù)轉(zhuǎn)換成1個數(shù)據(jù)集進行處理，減少了每次ACK的開銷，提高了效率，并通過exactlyone精準消費一次模型來保障數(shù)據(jù)的重復處理問題。它聯(lián)同分布式消息隊列Kafka（生產(chǎn)者消費者使用事務ACID模型來保障了數(shù)據(jù)消費和更新的原子性）在消息發(fā)送處、消息接收處實現(xiàn)了exactlyone。在Sparkstreaming中存在的問題是每次處理的數(shù)據(jù)量都是小批量的，如果我們想實現(xiàn)更小顆粒度的數(shù)據(jù)處理，就沒有辦法了，但這時候Flink應運而生。

Flink通過分布式快照snapshot快照模型來實現(xiàn)數(shù)據(jù)按條處理，在整個數(shù)據(jù)處理任務當中，snapshot快照模型對每次操作都進行拍照，記錄當時處理現(xiàn)況，當處理發(fā)生故障時，F(xiàn)link則停止當下處理，找到最近一次快照，把數(shù)據(jù)流恢復到當時的處理節(jié)點，讓業(yè)務按照當時處理情況繼續(xù)處理。并且為了更高效的處理任務，F(xiàn)link還提供了Window窗口模型，支持用戶自定義每個窗口需要處理的數(shù)據(jù)或時長。

在本文介紹了MapReduce、Storm、Spark、Sparkstreaming、Flink五款大數(shù)據(jù)計算引擎如何處理大數(shù)據(jù)計算任務，各自的特點，所解決的問題，其實并不是說能解決最多問題的就是最好的，在采用大數(shù)據(jù)計算引擎之前，應當結(jié)合自己的業(yè)務特點、數(shù)據(jù)訴求，綜合開發(fā)成本、維護成本，再決定采用哪一款，最合適的才是最強的。