在數(shù)據(jù)處理方面，我們發(fā)現(xiàn)數(shù)據(jù)輸入速度一般要比的數(shù)據(jù)處理速度快很多，這種現(xiàn)象在大數(shù)據(jù)領(lǐng)域尤為明顯。隨著數(shù)據(jù)不斷膨脹，相應(yīng)的響應(yīng)時(shí)間自然要有所增加，數(shù)據(jù)處理的復(fù)雜度也在不斷提高。作為一個(gè)開發(fā)者，我們自然非常關(guān)注系統(tǒng)的運(yùn)行速度問題。在云計(jì)算領(lǐng)域，一個(gè)小技巧也許能帶來系統(tǒng)性能的大幅度提升。對(duì)于Hadoop來說，如何提升它的速度呢？來看看下文。

Hadoop是用以下的方式來解決速度問題：

1 使用分布式文件系統(tǒng)：這使得負(fù)載分?jǐn)偅汛笙到y(tǒng)

2 優(yōu)化寫入速度：為了獲得更快的寫入速度，Hadoop架構(gòu)是設(shè)計(jì)成先寫入記錄，然后在進(jìn)行處理

3 使用批處理(Map/Reduce)來平衡數(shù)據(jù)傳送速度和處理速度。

批處理所帶來的挑戰(zhàn)

批量處理的挑戰(zhàn)在于，數(shù)據(jù)必須要間斷性地進(jìn)入才能保證流程正常運(yùn)作，而如果數(shù)據(jù)源連續(xù)地輸入，就會(huì)造成系統(tǒng)崩潰。

如果我們?cè)黾优幚泶翱诘脑?，結(jié)果就會(huì)增加數(shù)據(jù)處理過程的時(shí)間，使得相關(guān)的數(shù)據(jù)分析報(bào)告也要推遲落入我們的手中。在許多系統(tǒng)里，他們會(huì)選擇在非高峰時(shí)間進(jìn)行數(shù)據(jù)批處理，而這個(gè)時(shí)間是非常有限的。隨著數(shù)據(jù)的體積不斷脹大，處理數(shù)據(jù)的時(shí)間就不斷增加，這樣發(fā)展下去的話，需要被處理的數(shù)據(jù)就會(huì)不斷積壓。這最終的結(jié)果有可能一天都處理不完數(shù)據(jù)。

通過流處理來提升速度

流處理的概念是非常簡(jiǎn)單的。我們并不需要等到所有數(shù)據(jù)記錄完后才進(jìn)行處理，我們可以邊記錄邊處理。

拿生產(chǎn)線來做比喻，我們可以等到所有的組件齊全后才開始裝配汽車，也可以在生產(chǎn)廠那邊把組件包裝好，然后再送到特定的生產(chǎn)線，并馬上組裝起來。不用說，你也知道哪個(gè)速度會(huì)更快一點(diǎn)吧。

數(shù)據(jù)處理就跟生產(chǎn)線一樣，而流處理進(jìn)程就是把數(shù)據(jù)包裝起來，并送到特定的“生產(chǎn)線”上。而在傳統(tǒng)行業(yè)上，即使生產(chǎn)商把所有的部件都預(yù)裝起來，我們依然需要一條生產(chǎn)線來組裝。同樣，流處理并不是要取代Hadoop，它只是用于減少系統(tǒng)大量工作，從而提升系統(tǒng)的處理速度。

Curt Monash在他的“傳統(tǒng)數(shù)據(jù)庫最終會(huì)在RAM中終結(jié)”的研究中指出的，內(nèi)存間的流處理能夠打造出更好的流處理系統(tǒng)。下面就是一個(gè)實(shí)時(shí)大數(shù)據(jù)的分析案例，并用Twitter來演示數(shù)據(jù)的相應(yīng)處理方式。

Google更快的處理方案：用流處理來替代Map/Reduce

由于當(dāng)時(shí)缺乏可替方案，即使Map/Reduce性能不佳，許多大數(shù)據(jù)系統(tǒng)依然要使用這個(gè)技術(shù)。一個(gè)***的應(yīng)用例子就是使用這項(xiàng)技術(shù)來維護(hù)全球的搜索索引?，F(xiàn)在Google在索引處理方面大大減少使用Map/Reduce，反而加入了實(shí)時(shí)處理模式，這使得索引速度縮短為原來的一百分之一。

在網(wǎng)絡(luò)中，一些類型的數(shù)據(jù)在不斷膨脹。這也是HBase為什么計(jì)入觸發(fā)式處理的原因，而Twitter未來將要處理更龐大的流數(shù)據(jù)。

***的啰嗦

為了提升速度，在數(shù)據(jù)抵達(dá)Hadoop系統(tǒng)之前，我們可以通過一些預(yù)處理來提升系統(tǒng)的速度。我們也能像Google一樣，在某些情況下使用流處理方案來替代Map/Reduce。