當(dāng)前這個(gè)數(shù)據(jù)時(shí)代，各領(lǐng)域各業(yè)務(wù)場(chǎng)景時(shí)時(shí)刻刻都有大量的數(shù)據(jù)產(chǎn)生，如何理解大數(shù)據(jù)，對(duì)這些數(shù)據(jù)進(jìn)行有效的處理成為很多企業(yè)和研究機(jī)構(gòu)所面臨的問(wèn)題。本文將從大數(shù)據(jù)的基礎(chǔ)特性開(kāi)始，進(jìn)而解釋分而治之的處理思想，最后介紹一些流行的大數(shù)據(jù)技術(shù)和組件，讀者能夠通過(guò)本文了解大數(shù)據(jù)的概念、處理方法和流行技術(shù)。

什么是大數(shù)據(jù)?

大數(shù)據(jù)，顧名思義，就是擁有龐大體量的數(shù)據(jù)。關(guān)于什么是大數(shù)據(jù)，如何定義大數(shù)據(jù)，如何使用大數(shù)據(jù)等一系列問(wèn)題，不同領(lǐng)域背景的朋友理解各不相同。IBM將大數(shù)據(jù)歸納為5個(gè)V[^1]，涵蓋了大數(shù)據(jù)絕大多數(shù)的特性。 

大數(shù)據(jù)的5個(gè)V 來(lái)源：IBM

• Volume：數(shù)據(jù)量大，從TB(1,024 GB)、PB(1,024 TB)、EB(1,024 PB)、ZB(1,024 EB)甚至到Y(jié)B(1,024 ZB)。紐約證交所每天產(chǎn)生的交易數(shù)據(jù)大約在TB級(jí)，瑞士日內(nèi)瓦附近的大型強(qiáng)子對(duì)撞機(jī)每年產(chǎn)生的數(shù)據(jù)約為PB級(jí)，而目前全球數(shù)據(jù)總量已經(jīng)在ZB級(jí)，相當(dāng)于 1,000,000 PB，也就是大家更熟悉的10億 TB?；诟笠?guī)模的數(shù)據(jù)，我們可以對(duì)某個(gè)研究對(duì)象的歷史、現(xiàn)狀和未來(lái)有更加全面的了解。
• Velocity：數(shù)據(jù)產(chǎn)生速度快，所要求的處理速度和時(shí)效性高，因?yàn)闀r(shí)間就是金錢(qián)。金融市場(chǎng)的交易數(shù)據(jù)必須以秒級(jí)的速度進(jìn)行處理，搜索和推薦引擎需要在分鐘級(jí)將實(shí)時(shí)新聞推送給用戶(hù)。更快的數(shù)據(jù)處理速度，讓我們基于最新的數(shù)據(jù)上做更加實(shí)時(shí)的決策。
• Variety：數(shù)據(jù)類(lèi)型繁多，包括數(shù)字、文字、圖片、視頻等不同的數(shù)據(jù)形式，也包括來(lái)自社交網(wǎng)絡(luò)、視頻網(wǎng)站、可穿戴設(shè)備以及各類(lèi)傳感器的數(shù)據(jù)。數(shù)據(jù)可能是Excel里高度結(jié)構(gòu)化的數(shù)據(jù)，也可能是圖片和視頻這種非結(jié)構(gòu)化的數(shù)據(jù)。
• Veracity：數(shù)據(jù)真實(shí)性。一方面，數(shù)據(jù)并非天然具有高價(jià)值，一些異常值會(huì)被摻雜進(jìn)來(lái)，例如，統(tǒng)計(jì)偏差、人的情感影響、天氣、經(jīng)濟(jì)因素甚至謊報(bào)數(shù)據(jù)等。另一方面，數(shù)據(jù)源類(lèi)型不同，數(shù)據(jù)源多樣，如何將這些多元異構(gòu)數(shù)據(jù)連接、匹配、清洗和轉(zhuǎn)化，形成具有高置信度的數(shù)據(jù)是一項(xiàng)非常有挑戰(zhàn)的工作。
• Value：數(shù)據(jù)價(jià)值。我們研究和利用大數(shù)據(jù)的最終目的是提供更有價(jià)值的決策支持，基于以上提到的四個(gè)V，挖掘大數(shù)據(jù)的深層價(jià)值。

在數(shù)據(jù)分析領(lǐng)域，研究對(duì)象的全部被稱(chēng)為總體(Population)，總體包含大量的數(shù)據(jù)，甚至說(shuō)數(shù)據(jù)可能是無(wú)限的。比如調(diào)查15個(gè)國(guó)家的國(guó)民的誠(chéng)信情況，所有國(guó)民是總體。很多情況下，我們無(wú)法保證能收集和分析總體的所有數(shù)據(jù)，因此研究者一般基于研究對(duì)象的一個(gè)子集進(jìn)行數(shù)據(jù)分析。樣本(Sample)是從總體中抽取的個(gè)體，是研究對(duì)象的子集，通過(guò)對(duì)樣本的調(diào)查和分析，研究者可以推測(cè)總體的情況。在誠(chéng)信調(diào)查的案例中，我們可以在每個(gè)國(guó)家抽取一部分國(guó)民作為樣本，以此推測(cè)該國(guó)國(guó)民的誠(chéng)信水平。

在大數(shù)據(jù)技術(shù)成熟之前，受限于數(shù)據(jù)收集、存儲(chǔ)和分析能力，樣本數(shù)量相對(duì)較小，大數(shù)據(jù)技術(shù)的出現(xiàn)讓數(shù)據(jù)存儲(chǔ)和分析能力不再是瓶頸，研究者可以在更大規(guī)模的數(shù)據(jù)上，以更快地速度進(jìn)行數(shù)據(jù)分析。但數(shù)據(jù)并非天然有價(jià)值，如何讓數(shù)據(jù)點(diǎn)石成金非常有挑戰(zhàn)。在誠(chéng)信調(diào)查中，如果我們直接詢(xún)問(wèn)樣本對(duì)象：“你是否謊報(bào)了自己和家庭的資產(chǎn)以獲取更大的金融借貸額度?”十之八九，我們得不到真實(shí)的答案，但我們可以綜合多種渠道來(lái)分析該問(wèn)題，比如結(jié)合樣本對(duì)象的工作經(jīng)歷、征信記錄等數(shù)據(jù)。

可見(jiàn)，大數(shù)據(jù)具有更大的數(shù)據(jù)量、更快的速度、更多的數(shù)據(jù)類(lèi)型的特點(diǎn)。在一定的數(shù)據(jù)真實(shí)性基礎(chǔ)上，大數(shù)據(jù)技術(shù)最終為數(shù)據(jù)背后的價(jià)值服務(wù)。

隨著大數(shù)據(jù)技術(shù)的發(fā)展，數(shù)據(jù)的復(fù)雜性越來(lái)越高，有人在這5個(gè)V的基礎(chǔ)上，又提出了一些補(bǔ)充，比如增加了動(dòng)態(tài)性(Vitality)，強(qiáng)調(diào)整個(gè)數(shù)據(jù)體系的動(dòng)態(tài)性;增加了可視性(Visualization)，強(qiáng)調(diào)數(shù)據(jù)的顯性化展現(xiàn);增加了合法性(Validity)，強(qiáng)調(diào)數(shù)據(jù)采集和應(yīng)用的合法性，特別是對(duì)于個(gè)人隱私數(shù)據(jù)的合理使用等;增加了數(shù)據(jù)在線(xiàn)(Online)，強(qiáng)調(diào)數(shù)據(jù)永遠(yuǎn)在線(xiàn)，能隨時(shí)調(diào)用和計(jì)算。

分布式計(jì)算 分而治之

計(jì)算機(jī)誕生之后，一般是在單臺(tái)計(jì)算機(jī)上處理數(shù)據(jù)。大數(shù)據(jù)時(shí)代到來(lái)后，一些傳統(tǒng)的數(shù)據(jù)處理方法無(wú)法滿(mǎn)足大數(shù)據(jù)的處理需求，將一組計(jì)算機(jī)組織到一起形成一個(gè)集群，利用集群的力量來(lái)處理大數(shù)據(jù)的工程實(shí)踐逐漸成為主流方案。這種使用集群進(jìn)行計(jì)算的方式被稱(chēng)為分布式計(jì)算，當(dāng)前幾乎所有的大數(shù)據(jù)系統(tǒng)都是在集群進(jìn)行分布式計(jì)算。 

分而治之的算法思想

分布式計(jì)算的概念聽(tīng)起來(lái)很高深，其背后的思想十分樸素，即分而治之(Divide and Conquer)，又被稱(chēng)為分治法。分治法將一個(gè)原始問(wèn)題分解為子問(wèn)題，多個(gè)子問(wèn)題分別在多臺(tái)機(jī)器上求解，借助必要的數(shù)據(jù)交換和合并策略，將子結(jié)果匯總即可求出最終結(jié)果。具體而言，不同的分布式計(jì)算系統(tǒng)所使用的算法和策略根據(jù)所要解決的問(wèn)題各有不同，但基本上都是將計(jì)算拆分，把子問(wèn)題放到多臺(tái)機(jī)器上，分而治之地計(jì)算求解。分布式計(jì)算的每臺(tái)機(jī)器(物理機(jī)或虛擬機(jī))又被稱(chēng)為一個(gè)節(jié)點(diǎn)。

分布式計(jì)算在科研界已經(jīng)有很多比較成熟的方案，其中比較有名的有消息傳遞接口(Message Passing Interface，MPI)和MapReduce。

MPI

MPI是一個(gè)老牌分布式計(jì)算框架，主要解決節(jié)點(diǎn)間數(shù)據(jù)通信的問(wèn)題。在前MapReduce時(shí)代，MPI是分布式計(jì)算的業(yè)界標(biāo)準(zhǔn)。MPI程序現(xiàn)在依然廣泛運(yùn)行在全球各大超級(jí)計(jì)算中心、大學(xué)、政府和軍隊(duì)下屬研究機(jī)構(gòu)中，許多物理、生物、化學(xué)、能源、航空航天等基礎(chǔ)學(xué)科的大規(guī)模分布式計(jì)算都依賴(lài)MPI。

分治法將問(wèn)題切分成子問(wèn)題，在不同節(jié)點(diǎn)上分而治之地求解，MPI提供了一個(gè)在多進(jìn)程多節(jié)點(diǎn)間進(jìn)行數(shù)據(jù)通信的方案，因?yàn)榻^大多數(shù)情況下，在中間計(jì)算和最終合并的過(guò)程中，需要對(duì)多個(gè)節(jié)點(diǎn)上的數(shù)據(jù)進(jìn)行交換和同步。 

MPI并行計(jì)算示意圖

MPI中最重要的兩個(gè)操作為數(shù)據(jù)發(fā)送(Send)和數(shù)據(jù)接收(Recv)，Send表示將本進(jìn)程中某塊數(shù)據(jù)發(fā)送給其他進(jìn)程，Recv表示接收其他進(jìn)程的數(shù)據(jù)。上圖展示了MPI架構(gòu)在4臺(tái)服務(wù)器上并行計(jì)算的示意圖。在實(shí)際的代碼開(kāi)發(fā)過(guò)程中，用戶(hù)需要自行設(shè)計(jì)分治算法，將復(fù)雜問(wèn)題切分為子問(wèn)題，手動(dòng)調(diào)用MPI庫(kù)，將數(shù)據(jù)發(fā)送給指定的進(jìn)程。

MPI能夠在很細(xì)的粒度上控制數(shù)據(jù)的通信，這是它的優(yōu)勢(shì)，同時(shí)也是它的劣勢(shì)，因?yàn)榧?xì)粒度的控制意味著從分治算法設(shè)計(jì)到數(shù)據(jù)通信到結(jié)果匯總都需要編程人員手動(dòng)控制。有經(jīng)驗(yàn)的程序員可以對(duì)程序進(jìn)行底層優(yōu)化，取得成倍的速度提升。但如果對(duì)計(jì)算機(jī)和分布式系統(tǒng)沒(méi)有太多經(jīng)驗(yàn)，編碼、調(diào)試和運(yùn)行MPI程序的時(shí)間成本極高，加上數(shù)據(jù)在不同節(jié)點(diǎn)上不均衡和通信延遲等問(wèn)題，一個(gè)節(jié)點(diǎn)進(jìn)程失敗將會(huì)導(dǎo)致整個(gè)程序失敗，因此，MPI對(duì)于大部分程序員來(lái)說(shuō)簡(jiǎn)直就是噩夢(mèng)。

并非所有的編程人員都能熟練掌握MPI編程，衡量一個(gè)程序的時(shí)間成本，不僅要考慮程序運(yùn)行的時(shí)間，也要考慮程序員學(xué)習(xí)、開(kāi)發(fā)和調(diào)試的時(shí)間。就像C語(yǔ)言運(yùn)算速度極快，但是Python語(yǔ)言卻更受歡迎一樣，MPI雖然能提供極快的分布式計(jì)算加速，但不太接地氣。

MapReduce

為了解決分布式計(jì)算學(xué)習(xí)和使用成本高的問(wèn)題，研究人員提出了更簡(jiǎn)單易用的MapReduce編程模型[^2]。MapReduce是Google 2004年提出的一種編程范式，比起MPI將所有事情交給程序員控制不同，MapReduce編程模型只需要程序員定義兩個(gè)操作：map和reduce。 

使用MapReduce制作三明治

網(wǎng)絡(luò)上有很多MapReduce的介紹和解釋?zhuān)@里我們用三明治的制作過(guò)程對(duì)MapReduce進(jìn)行了分解。假設(shè)我們需要大批量地制作三明治，三明治的每種食材可以分別單獨(dú)處理，map階段將原材料在不同的節(jié)點(diǎn)上分別進(jìn)行處理，生成一些中間食材，shuffle階段將不同的中間食材進(jìn)行組合，reduce最終將一組中間食材組合成為三明治成品?？梢钥吹剑@種map + shuffle + reduce的方式就是分而治之思想的一種實(shí)現(xiàn)。

基于MapReduce編程模型，不同的團(tuán)隊(duì)分別實(shí)現(xiàn)了自己的大數(shù)據(jù)框架：Hadoop是最早的一種開(kāi)源實(shí)現(xiàn)，如今已經(jīng)成為大數(shù)據(jù)領(lǐng)域的業(yè)界標(biāo)桿，之后又出現(xiàn)了Spark和Flink。這些框架提供了編程接口和API，輔助程序員存儲(chǔ)、處理和分析大數(shù)據(jù)。

比起MPI，MapReduce編程模型將更多的中間過(guò)程做了封裝，程序員只需要將原始問(wèn)題轉(zhuǎn)化為更高層次的API，至于原始問(wèn)題如何切分為更小的子問(wèn)題、中間數(shù)據(jù)如何傳輸和交換、如何將計(jì)算伸縮擴(kuò)展到多個(gè)節(jié)點(diǎn)等一系列細(xì)節(jié)問(wèn)題可以交給大數(shù)據(jù)框架來(lái)解決。因此，MapReduce相對(duì)來(lái)說(shuō)學(xué)習(xí)門(mén)檻更低，使用更方便，編程開(kāi)發(fā)速度更快。

批處理和流處理

數(shù)據(jù)與數(shù)據(jù)流

在大數(shù)據(jù)的5V定義中我們已經(jīng)提到，數(shù)據(jù)的容量大且產(chǎn)生速度快。從時(shí)間維度上來(lái)講，數(shù)據(jù)源源不斷地產(chǎn)生，形成一個(gè)無(wú)界的數(shù)據(jù)流(Unbounded Stream)。例如我們每時(shí)每刻的運(yùn)動(dòng)數(shù)據(jù)都會(huì)累積到手機(jī)傳感器上，金融交易隨時(shí)隨地發(fā)生著，傳感器會(huì)持續(xù)監(jiān)控并生成數(shù)據(jù)。數(shù)據(jù)流中的某段有界數(shù)據(jù)流(Bounded Stream)可以組成一個(gè)數(shù)據(jù)集。我們通常所說(shuō)的對(duì)某份數(shù)據(jù)進(jìn)行分析，指的是對(duì)某個(gè)數(shù)據(jù)集進(jìn)行分析。隨著數(shù)據(jù)的產(chǎn)生速度越來(lái)越快，數(shù)據(jù)源越來(lái)越多，人們對(duì)時(shí)效性的重視程度越來(lái)越高，如何處理數(shù)據(jù)流成了大家更為關(guān)注的問(wèn)題。 

 數(shù)據(jù)與數(shù)據(jù)流

批處理

批處理(Batch Processing)是對(duì)一批數(shù)據(jù)進(jìn)行處理。我們身邊批量計(jì)算比比皆是，最簡(jiǎn)單的批量計(jì)算例子有：微信運(yùn)動(dòng)每天晚上有一個(gè)批量任務(wù)，把用戶(hù)好友一天所走的步數(shù)統(tǒng)計(jì)一遍，生成排序結(jié)果后推送給用戶(hù);銀行信用卡中心每月賬單日有一個(gè)批量任務(wù)，把一個(gè)月的消費(fèi)總額統(tǒng)計(jì)一次，生成用戶(hù)月度賬單;國(guó)家統(tǒng)計(jì)局每季度對(duì)經(jīng)濟(jì)數(shù)據(jù)做一次統(tǒng)計(jì)，公布季度GDP增速?？梢?jiàn)，批量任務(wù)一般是對(duì)一段時(shí)間的數(shù)據(jù)聚合后進(jìn)行處理。對(duì)于數(shù)據(jù)量龐大的應(yīng)用，如微信運(yùn)動(dòng)、銀行信用卡等情景，一段時(shí)間內(nèi)積累的數(shù)據(jù)總量非常大，計(jì)算非常耗時(shí)。

批量計(jì)算的歷史可以追溯的計(jì)算機(jī)剛剛起步的上世紀(jì)60年代，當(dāng)前應(yīng)用最為廣泛的當(dāng)屬數(shù)據(jù)倉(cāng)庫(kù)的ETL(Extract Transform Load)數(shù)據(jù)轉(zhuǎn)化工作，如以O(shè)racle為代表的商業(yè)數(shù)據(jù)倉(cāng)庫(kù)和以Hadoop/Spark為代表的開(kāi)源數(shù)據(jù)倉(cāng)庫(kù)。

流處理

如前文所說(shuō)，數(shù)據(jù)其實(shí)是以流(Stream)的方式持續(xù)不斷地產(chǎn)生著，流處理(Stream Processing)就是對(duì)數(shù)據(jù)流進(jìn)行處理。時(shí)間就是金錢(qián)，對(duì)數(shù)據(jù)流進(jìn)行分析和處理，獲取實(shí)時(shí)數(shù)據(jù)價(jià)值越發(fā)重要。個(gè)人用戶(hù)每晚看一次微信運(yùn)動(dòng)排名覺(jué)得是一個(gè)比較舒適的節(jié)奏，但是對(duì)于金融界來(lái)說(shuō)，時(shí)間是以百萬(wàn)、千萬(wàn)甚至上億為單位的金錢(qián)!雙十一電商大促銷(xiāo)，管理者要以秒級(jí)的響應(yīng)時(shí)間查看實(shí)時(shí)銷(xiāo)售業(yè)績(jī)、庫(kù)存信息以及與競(jìng)品的對(duì)比結(jié)果，以爭(zhēng)取更多的決策時(shí)間;股票交易要以毫秒級(jí)的速度來(lái)對(duì)新信息做出響應(yīng);風(fēng)險(xiǎn)控制要對(duì)每一份欺詐交易迅速做出處理，以減少不必要的損失;網(wǎng)絡(luò)運(yùn)營(yíng)商要以極快速度發(fā)現(xiàn)網(wǎng)絡(luò)和數(shù)據(jù)中心的故障等等。以上這些場(chǎng)景，一旦出現(xiàn)故障，造成了服務(wù)的延遲，損失都難以估量，因此，響應(yīng)速度越快，越能減少損失，增加收入。而IoT物聯(lián)網(wǎng)和5G通信的興起將為數(shù)據(jù)生成提供更完美的底層技術(shù)基礎(chǔ)，海量的數(shù)據(jù)在IoT設(shè)備上采集生成，并通過(guò)更高速的5G通道傳輸?shù)椒?wù)器，更龐大的實(shí)時(shí)數(shù)據(jù)流將洶涌而至，流式處理的需求肯定會(huì)爆炸式增長(zhǎng)。

代表性大數(shù)據(jù)技術(shù)

如前文所述，MapReduce編程模型的提出為大數(shù)據(jù)分析和處理開(kāi)創(chuàng)了一條先河，之后陸續(xù)涌現(xiàn)出了Hadoop、Spark和Flink等大數(shù)據(jù)框架。

Hadoop

2004年，Hadoop的創(chuàng)始人受MapReduce編程模型等一系列論文的啟發(fā)，對(duì)論文中提及的思想進(jìn)行了編程實(shí)現(xiàn)。Hadoop的名字來(lái)源于創(chuàng)始人Doug Cutting兒子的玩具大象。由于創(chuàng)始人Doug Cutting當(dāng)時(shí)加入了雅虎，并在此期間支持了大量Hadoop的研發(fā)工作，因此Hadoop也經(jīng)常被認(rèn)為是雅虎開(kāi)源的一款大數(shù)據(jù)框架。時(shí)至今日，Hadoop不僅僅是整個(gè)大數(shù)據(jù)領(lǐng)域的先行者和領(lǐng)導(dǎo)者，更形成了一套圍繞Hadoop的生態(tài)系統(tǒng)，Hadoop和它的生態(tài)是絕大多數(shù)企業(yè)首選的大數(shù)據(jù)解決方案。 

Hadoop生態(tài)

盡管Hadoop生態(tài)中的組件眾多，其核心組件主要有三個(gè)：

• Hadoop MapReduce：Hadoop版本的MapReduce編程模型，可以處理海量數(shù)據(jù)，主要面向批處理。
• HDFS：HDFS全稱(chēng)為Hadoop Distributed File System，是Hadoop提供的分布式文件系統(tǒng)，有很好的擴(kuò)展性和容錯(cuò)性。
• YARN：YARN是Yet Another Resource Negotiator的縮寫(xiě)，是Hadoop生態(tài)系統(tǒng)中的資源調(diào)度器，可以管理一個(gè)Hadoop集群，并為各種類(lèi)型的大數(shù)據(jù)任務(wù)分配計(jì)算資源。

這三大組件中，數(shù)據(jù)存儲(chǔ)在HDFS上，由MapReduce負(fù)責(zé)計(jì)算，YARN負(fù)責(zé)集群的資源管理。除了三大核心組件，Hadoop生態(tài)圈還有很多其他著名的組件：

• Hive：借助Hive，用戶(hù)可以編寫(xiě)SQL語(yǔ)句來(lái)查詢(xún)HDFS上的結(jié)構(gòu)化數(shù)據(jù)，SQL會(huì)被轉(zhuǎn)化成MapReduce執(zhí)行。
• HBase：HDFS上的數(shù)據(jù)量非常龐大，但訪(fǎng)問(wèn)和查詢(xún)速度比較慢，HBase可以提供給用戶(hù)毫秒級(jí)的實(shí)時(shí)查詢(xún)服務(wù)，是一個(gè)基于HDFS的分布式數(shù)據(jù)庫(kù)。
• Storm：Strom是一款實(shí)時(shí)計(jì)算框架，主要負(fù)責(zé)流處理。
• Zookeeper：Hadoop生態(tài)圈很多組件使用動(dòng)物來(lái)命名，形成了一個(gè)大型動(dòng)物園，Zookeeper是這個(gè)動(dòng)物園的管理者，主要負(fù)責(zé)分布式環(huán)境的協(xié)調(diào)。

Spark

Spark于2009年誕生于加州大學(xué)伯克利分校，2013年被捐獻(xiàn)給Apache基金會(huì)。Spark是一款大數(shù)據(jù)計(jì)算框架，其初衷是改良Hadoop MapReduce的編程模型和執(zhí)行速度。與Hadoop相比，Spark的改進(jìn)主要有兩點(diǎn)：

• 易用性：比起MPI，MapReduce模型更友好，但仍然不夠方便，因?yàn)椴⒉皇撬杏?jì)算任務(wù)都可以簡(jiǎn)單拆分成map和reduce，有可能為了解決一個(gè)問(wèn)題，要設(shè)計(jì)多個(gè)MapReduce任務(wù)，任務(wù)之間相互依賴(lài)，整個(gè)程序非常復(fù)雜，導(dǎo)致代碼的可讀性差。Spark提供更加方便易用的接口，提供Java、Scala、Python和R幾種語(yǔ)言的API，支持SQL、機(jī)器學(xué)習(xí)和圖計(jì)算，覆蓋了絕大多數(shù)大數(shù)據(jù)計(jì)算的場(chǎng)景。
• 速度快：Hadoop的map和reduce之間的中間結(jié)果都需要落地到磁盤(pán)上，而Spark盡量將大部分計(jì)算放在內(nèi)存中，加上Spark的有向無(wú)環(huán)圖優(yōu)化，在官方的基準(zhǔn)測(cè)試中，Spark比Hadoop快一百倍以上。 

Spark生態(tài)

Spark的核心在于計(jì)算，主要目的在于優(yōu)化Hadoop MapReduce計(jì)算部分，在計(jì)算層面提供更細(xì)致的服務(wù)，比如提供了常用幾種數(shù)據(jù)科學(xué)語(yǔ)言的API，提供了SQL、機(jī)器學(xué)習(xí)和圖計(jì)算支持，這些服務(wù)都是最終面向計(jì)算的。Spark并不能完全取代Hadoop，實(shí)際上，Spark融入到了Hadoop生態(tài)圈，成為其中的重要一元。一個(gè)Spark任務(wù)很可能依賴(lài)HDFS上的數(shù)據(jù)，向YARN來(lái)申請(qǐng)計(jì)算資源，將HBase作為輸出結(jié)果的目的地。當(dāng)然，Spark也可以不用依賴(lài)這些Hadoop組件，獨(dú)立地完成計(jì)算。

 Spark Streaming數(shù)據(jù)流示意圖

Spark主要面向批處理需求，因其優(yōu)異的性能和易用的接口，Spark已經(jīng)是批處理界絕對(duì)的王者。Spark Streaming提供了流處理的功能，它的流處理主要基于mini-batch的思想，即將輸入數(shù)據(jù)流拆分成多個(gè)批次，每個(gè)批次使用批處理的方式進(jìn)行計(jì)算。因此，Spark是一款批量和流式于一體的計(jì)算框架。

Flink

Flink是由德國(guó)幾所大學(xué)發(fā)起的的學(xué)術(shù)項(xiàng)目，后來(lái)不斷發(fā)展壯大，并于2014年末成為Apache頂級(jí)項(xiàng)目。Flink主要面向流處理，如果說(shuō)Spark是批處理界的王者，那么Flink就是流處理領(lǐng)域的冉冉升起的新星。在Flink之前，不乏流式處理引擎，比較著名的有Storm、Spark Streaming，但某些特性遠(yuǎn)不如Flink。 

流處理框架演進(jìn)史

第一代被廣泛采用的流處理框架是Strom。在多項(xiàng)基準(zhǔn)測(cè)試中，Storm的數(shù)據(jù)吞吐量和延遲都遠(yuǎn)遜于Flink。Storm只支持"at least once"和"at most once"，即數(shù)據(jù)流里的事件投遞只能保證至少一次或至多一次，不能保證只有一次。對(duì)于很多對(duì)數(shù)據(jù)準(zhǔn)確性要求較高的應(yīng)用，Storm有一定劣勢(shì)。第二代非常流行的流處理框架是Spark Streaming。Spark Streaming使用mini-batch的思想，每次處理一小批數(shù)據(jù)，一小批數(shù)據(jù)包含多個(gè)事件，以接近實(shí)時(shí)處理的效果。因?yàn)樗看斡?jì)算一小批數(shù)據(jù)，因此總有一些延遲。但Spark Streaming的優(yōu)勢(shì)是擁有Spark這個(gè)靠山，用戶(hù)從Spark遷移到Spark Streaming的成本較低，因此能給用戶(hù)提供一個(gè)批量和流式于一體的計(jì)算框架。

Flink是與上述兩代框架都不太一樣的新一代計(jì)算框架，它是一個(gè)支持在有界和無(wú)界數(shù)據(jù)流上做有狀態(tài)計(jì)算的大數(shù)據(jù)引擎。它以事件為單位，并且支持SQL、State、WaterMark等特性。它支持"exactly once"，即事件投遞保證只有一次，不多也不少，這樣數(shù)據(jù)的準(zhǔn)確性能得到提升。比起Storm，它的吞吐量更高，延遲更低，準(zhǔn)確性能得到保障;比起Spark Streaming，它以事件為單位，達(dá)到真正意義上的實(shí)時(shí)計(jì)算，且所需計(jì)算資源相對(duì)更少。

之前提到，數(shù)據(jù)都是以流的形式產(chǎn)生的。數(shù)據(jù)可以分為有界(bounded)和無(wú)界(unbounded)，批量處理其實(shí)就是一個(gè)有界的數(shù)據(jù)流，是流處理的一個(gè)特例。Flink基于這種思想，逐步發(fā)展成一個(gè)可支持流式和批量處理的大數(shù)據(jù)框架。

經(jīng)過(guò)幾年的發(fā)展，F(xiàn)link的API已經(jīng)非常完善，可以支持Java、Scala和Python，并且支持SQL。Flink的Scala版API與Spark非常相似，有Spark經(jīng)驗(yàn)的程序員可以用一個(gè)小時(shí)的時(shí)間熟悉Flink API。

與Spark類(lèi)似，F(xiàn)link目前主要面向計(jì)算，并且可以與Hadoop生態(tài)高度集成。Spark和Flink各有所長(zhǎng)，也在相互借鑒，一邊競(jìng)爭(zhēng)，一邊學(xué)習(xí)，究竟最終誰(shuí)能一統(tǒng)江湖，我們拭目以待。

小結(jié)

大數(shù)據(jù)一般基于分而治之的思想，分布式地進(jìn)行計(jì)算。經(jīng)過(guò)十幾年的發(fā)展，大數(shù)據(jù)生態(tài)圈涌現(xiàn)出一大批優(yōu)秀的組件和框架，這些組件對(duì)一些底層技術(shù)做了封裝，提供給程序員簡(jiǎn)單易用的API接口。在大數(shù)據(jù)分析和處理領(lǐng)域，Hadoop已經(jīng)發(fā)展成為一個(gè)非常成熟的生態(tài)圈，涵蓋了很多大數(shù)據(jù)相關(guān)的基礎(chǔ)服務(wù)，Spark和Flink主要針對(duì)大數(shù)據(jù)計(jì)算，分別在批處理和流處理方向建立了自己的優(yōu)勢(shì)。