本文原名“Don’t use Hadoop when your data isn’t that big ”，出自有著多年從業(yè)經(jīng)驗(yàn)的數(shù)據(jù)科學(xué)家Chris Stucchio，紐約大學(xué)柯朗研究所博士后，搞過(guò)高頻交易平臺(tái)，當(dāng)過(guò)創(chuàng)業(yè)公司的CTO，更習(xí)慣稱自己為統(tǒng)計(jì)學(xué)者。對(duì)了，他現(xiàn)在自己創(chuàng)業(yè)，提供數(shù)據(jù)分析、推薦優(yōu)化咨詢服務(wù)，他的郵件是：stucchio@gmail.com 。

“你有多少大數(shù)據(jù)和Hadoop的經(jīng)驗(yàn)?”他們問(wèn)我。我一直在用Hadoop，但很少處理幾TB以上的任務(wù)。我基本上只是一個(gè)大數(shù)據(jù)新手——知道概念，寫(xiě)過(guò)代碼，但是沒(méi)有大規(guī)模經(jīng)驗(yàn)。

接下來(lái)他們會(huì)問(wèn)：“你能用Hadoop做簡(jiǎn)單的group by和sum操作嗎?”我當(dāng)然會(huì)，但我會(huì)說(shuō)需要看看具體文件格式。

他們給我一個(gè)U盤(pán)，里面有所有的數(shù)據(jù)，600MB，對(duì)，他們所有的數(shù)據(jù)。不知道為什么，我用pandas.read_csv(Pandas是一種Python數(shù)據(jù)分析庫(kù))而不是Hadoop完成了這個(gè)任務(wù)后，他們顯得很不滿意。

Hadoop其實(shí)是挺局限的。它無(wú)非是運(yùn)行某個(gè)通用的計(jì)算，用SQL偽代碼表示就是： SELECT G(…) FROM table GROUP BY F(…) 你只能改變G和F操作，除非要在中間步驟做性能優(yōu)化(這可不怎么好玩!)。其他一切都是死的。

(關(guān)于MapReduce，之前作者寫(xiě)過(guò)一篇“41個(gè)詞講清楚MapReduce”，可以參考。)

Hadoop里，所有計(jì)算都必須按照一個(gè)map、一個(gè)group by、一個(gè)aggregate或者這種計(jì)算序列來(lái)寫(xiě)。這和穿上緊身衣一樣，多憋得慌啊。許多計(jì)算用其他模型其實(shí)更適合。忍受緊身衣的唯一原因就是，可以擴(kuò)展到極大極大的數(shù)據(jù)集?？赡愕臄?shù)據(jù)集實(shí)際上很可能根本遠(yuǎn)遠(yuǎn)夠不上那個(gè)數(shù)量級(jí)。

可是呢，因?yàn)镠adoop和大數(shù)據(jù)是熱詞，世界有一半的人都想穿上緊身衣，即使他們根本不需要。

可我的數(shù)據(jù)有好幾百M(fèi)B呢!Excel都裝不下

對(duì)Excel很大可不是什么大數(shù)據(jù)。有很多好工具——我喜歡用的是基于Numpy的Pandas。它可以將幾百M(fèi)B數(shù)據(jù)以高效的向量化格式加載到內(nèi)存，在我已經(jīng)3年的老筆記本上，一眨眼的功夫，Numpy就能完成1億次浮點(diǎn)計(jì)算。Matlab和R也是很棒的工具。

數(shù)百M(fèi)B數(shù)據(jù)一般用一個(gè)簡(jiǎn)單的Python腳本逐行讀取文件、處理，然后寫(xiě)到了一個(gè)文件就行了。

可我的數(shù)據(jù)有10G呢!

我剛買了一臺(tái)筆記本電腦。16G內(nèi)存花了141.98美元，256GB SSD多收200美元。另外，如果在Pandas里加載一個(gè)10GB的csv文件，實(shí)際在內(nèi)存里并沒(méi)有那么大——你可以將 “17284932583” 這樣的數(shù)值串存為4位或者8位整數(shù)，“284572452.2435723”存為8位雙精度。

最差情況下，你還可以不同時(shí)將所有數(shù)據(jù)都一次加載到內(nèi)存里。

可我的數(shù)據(jù)有100GB/500GB/1TB!

一個(gè)2T的硬盤(pán)才94.99美元，4T是169.99。買一塊，加到桌面電腦或者服務(wù)器上，然后裝上PostgreSQL。

Hadoop的適用范圍遠(yuǎn)小于SQL和Python腳本

從計(jì)算的表達(dá)能力來(lái)說(shuō)，Hadoop比SQL差多了。Hadoop里能寫(xiě)的計(jì)算，在SQL或者簡(jiǎn)單的Python腳本都可以更輕松地寫(xiě)出來(lái)。

SQL是直觀的查詢語(yǔ)言，沒(méi)有太多抽象，業(yè)務(wù)分析師和程序員都很常用。SQL查詢往往非常簡(jiǎn)單，而且一般也很快——只要數(shù)據(jù)庫(kù)正確地做了索引，要花幾秒鐘的查詢都不太多見(jiàn)。

Hadoop沒(méi)有任何索引的概念，它只知道全表掃描。而且Hadoop抽象層次太多了——我之前的項(xiàng)目盡在應(yīng)付Java內(nèi)存錯(cuò)誤、內(nèi)存碎片和集群競(jìng)用了，實(shí)際的數(shù)據(jù)分析工作反而沒(méi)了時(shí)間。

如果你的數(shù)據(jù)結(jié)構(gòu)不是SQL表的形式(比如純文本、JSON、二進(jìn)制)，一般寫(xiě)一小段Python或者Ruby腳本按行處理更直接。保存在多個(gè)文件里，逐個(gè)處理即可。SQL不適用的情況下，從編程來(lái)說(shuō)Hadoop也沒(méi)那么糟糕，但相比Python腳本仍然沒(méi)有什么優(yōu)勢(shì)。

除了難以編程，Hadoop還一般總是比其他技術(shù)方案要慢。只要索引用得好，SQL查詢非?？?。比如要計(jì)算join，PostgreSQL只需查看索引(如果有)，然后查詢所需的每個(gè)鍵。而Hadoop呢，必須做全表掃描，然后重排整個(gè)表。排序通過(guò)多臺(tái)機(jī)器之間分片可以加速，但也帶來(lái)了跨多機(jī)數(shù)據(jù)流處理的開(kāi)銷。如果要處理二進(jìn)制文件，Hadoop必須反復(fù)訪問(wèn)namenode。而簡(jiǎn)單的Python腳本只要反復(fù)訪問(wèn)文件系統(tǒng)即可。

可我的數(shù)據(jù)超過(guò)了5TB!

你的命可真苦——只能苦逼地折騰Hadoop了，沒(méi)有太多其他選擇(可能還能用許多硬盤(pán)容量的高富帥機(jī)器來(lái)扛)，而且其他選擇往往貴得要命(腦海中浮現(xiàn)出IOE等等字樣……)。

用Hadoop唯一的好處是擴(kuò)展。如果你的數(shù)據(jù)是一個(gè)數(shù)TB的單表，那么全表掃描是Hadoop的強(qiáng)項(xiàng)。此外的話，請(qǐng)關(guān)愛(ài)生命，盡量遠(yuǎn)離Hadoop。它帶來(lái)的煩惱根本不值，用傳統(tǒng)方法既省時(shí)又省力。

原文鏈接：http://www.kankanews.com/ICkengine/archives/47621.shtml