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

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

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

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

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

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

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

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

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

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

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

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