大數(shù)據(jù)的兩種計(jì)算框架優(yōu)劣對(duì)比，哪個(gè)更適合開(kāi)發(fā)？

更新時(shí)間:2020年11月18日16時(shí)07分來(lái)源:傳智播客瀏覽次數(shù):

　　Hadoop與Spark兩者都是大數(shù)據(jù)計(jì)算框架，但是兩者各自都有自己的優(yōu)勢(shì)，關(guān)于Spark與Hadoop的對(duì)比，主要有以下幾點(diǎn)：

　　1. 編程方式

　　Hadoop的MapReduce在計(jì)算數(shù)據(jù)時(shí)，計(jì)算過(guò)程必須要轉(zhuǎn)化為Map和Reduce兩個(gè)過(guò)程，從而難以描述復(fù)雜的數(shù)據(jù)處理過(guò)程;而Spark的計(jì)算模型不局限于Map和Reduce操作，還提供了多種數(shù)據(jù)集的操作類型，編程模型比MapReduce更加靈活。

　　2. 數(shù)據(jù)存儲(chǔ)

　　Hadoop的MapReduce進(jìn)行計(jì)算時(shí)，每次產(chǎn)生的中間結(jié)果都是存儲(chǔ)在本地磁盤中;而Spark在計(jì)算時(shí)產(chǎn)生的中間結(jié)果存儲(chǔ)在內(nèi)存中。

　　3. 數(shù)據(jù)處理

　　Hadoop在每次執(zhí)行數(shù)據(jù)處理時(shí)，都需要從磁盤中加載數(shù)據(jù)，導(dǎo)致磁盤的IO開(kāi)銷較大;而Spark在執(zhí)行數(shù)據(jù)處理時(shí)，只需要將數(shù)據(jù)加載到內(nèi)存中，之后直接在內(nèi)存中加載中間結(jié)果數(shù)據(jù)集即可，減少了磁盤的IO開(kāi)銷。

　　4. 數(shù)據(jù)容錯(cuò)

　　MapReduce計(jì)算的中間結(jié)果數(shù)據(jù)，保存在磁盤中，并且Hadoop框架底層實(shí)現(xiàn)了備份機(jī)制，從而保證了數(shù)據(jù)容錯(cuò);同樣Spark RDD實(shí)現(xiàn)了基于Lineage的容錯(cuò)機(jī)制和設(shè)置檢查點(diǎn)兩種方式的容錯(cuò)機(jī)制，彌補(bǔ)數(shù)據(jù)在內(nèi)存處理時(shí)斷電數(shù)據(jù)丟失的問(wèn)題。關(guān)于Spark容錯(cuò)機(jī)制我們?cè)诘谌耂park RDD彈性分布式數(shù)據(jù)集中將會(huì)詳細(xì)講解。

　　在Spark與Hadoop性能對(duì)比中，較為明顯的缺陷是Hadoop 中的MapReduce計(jì)算延遲較高，無(wú)法勝任當(dāng)下爆發(fā)式的數(shù)據(jù)增長(zhǎng)所要求的實(shí)時(shí)、快速計(jì)算的需求。接下來(lái)，我們通過(guò)圖1來(lái)詳細(xì)講解這一原因。

　　圖1 Hadoop與Spark執(zhí)行流程

　　從圖1中可以看出，使用Hadoop MapReduce進(jìn)行計(jì)算時(shí)，每次計(jì)算產(chǎn)生的中間結(jié)果都需要從磁盤中讀取并寫入，大大增加了磁盤的IO開(kāi)銷，而使用Spark進(jìn)行計(jì)算時(shí)，需要先將磁盤中的數(shù)據(jù)讀取到內(nèi)存中，產(chǎn)生的數(shù)據(jù)不再寫入磁盤，直接在內(nèi)存中迭代處理，這樣就避免了從磁盤中頻繁讀取數(shù)據(jù)造成不必要的開(kāi)銷。通過(guò)官方計(jì)算測(cè)試，Hadoop與Spark在執(zhí)行邏輯斯蒂回歸時(shí)所需的時(shí)間對(duì)比，如圖2所示。