別老扯什么hadoop,你的數據根本不夠大


本文原名“Don't use Hadoop when your data isn't that big ”,出自有着多年從業經驗的數據科學家Chris Stucchio,紐約大學柯朗研究所博士后,搞過高頻交易平台,當過創業公司的CTO,更習慣稱自己為統計學者。對了,他現在自己創業,提供數據分析、推薦優化咨詢服務,他的郵件是:stucchio@gmail.com 。

“你有多少大數據和Hadoop的經驗?”他們問我。我一直在用Hadoop,但很少處理幾TB以上的任務。我基本上只是一個大數據新手——知道概念,寫過代碼,但是沒有大規模經驗。

接下來他們會問:“你能用Hadoop做簡單的group by和sum操作嗎?”我當然會,但我會說需要看看具體文件格式。

他們給我一個U盤,里面有所有的數據,600MB,對,他們所有的數據。不知道為什么,我用pandas.read_csvPandas是一種Python數據分析庫)而不是Hadoop完成了這個任務后,他們顯得很不滿意。

Hadoop其實是挺局限的。它無非是運行某個通用的計算,用SQL偽代碼表示就是: SELECT G(...) FROM table GROUP BY F(...) 你只能改變G和F操作,除非要在中間步驟做性能優化(這可不怎么好玩!)。其他一切都是死的。

(關於MapReduce,之前作者寫過一篇“41個詞講清楚MapReduce”,可以參考。)

Hadoop里,所有計算都必須按照一個map、一個group by、一個aggregate或者這種計算序列來寫。這和穿上緊身衣一樣,多憋得慌啊。許多計算用其他模型其實更適合。忍受緊身衣的唯一原因就是,可以擴展到極大極大的數據集。可你的數據集實際上很可能根本遠遠夠不上那個數量級。

可是呢,因為Hadoop和大數據是熱詞,世界有一半的人都想穿上緊身衣,即使他們根本不需要。

可我的數據有好幾百MB呢!Excel都裝不下

對Excel很大可不是什么大數據。有很多好工具——我喜歡用的是基於Numpy的Pandas。它可以將幾百MB數據以高效的向量化格式加載到內存,在我已經3年的老筆記本上,一眨眼的功夫,Numpy就能完成1億次浮點計算。Matlab和R也是很棒的工具。

數百MB數據一般用一個簡單的Python腳本逐行讀取文件、處理,然后寫到了一個文件就行了。

可我的數據有10G呢!

我剛買了一台筆記本電腦。16G內存花了141.98美元,256GB SSD多收200美元。另外,如果在Pandas里加載一個10GB的csv文件,實際在內存里並沒有那么大——你可以將 “17284932583” 這樣的數值串存為4位或者8位整數,“284572452.2435723”存為8位雙精度。

最差情況下,你還可以不同時將所有數據都一次加載到內存里。

可我的數據有100GB/500GB/1TB!

一個2T的硬盤才94.99美元,4T是169.99。買一塊,加到桌面電腦或者服務器上,然后裝上PostgreSQL。

Hadoop的適用范圍遠小於SQL和Python腳本

從計算的表達能力來說,Hadoop比SQL差多了。Hadoop里能寫的計算,在SQL或者簡單的Python腳本都可以更輕松地寫出來。

SQL是直觀的查詢語言,沒有太多抽象,業務分析師和程序員都很常用。SQL查詢往往非常簡單,而且一般也很快——只要數據庫正確地做了索引,要花幾秒鍾的查詢都不太多見。

Hadoop沒有任何索引的概念,它只知道全表掃描。而且Hadoop抽象層次太多了——我之前的項目盡在應付Java內存錯誤、內存碎片和集群競用了,實際的數據分析工作反而沒了時間。

如果你的數據結構不是SQL表的形式(比如純文本、JSON、二進制),一般寫一小段Python或者Ruby腳本按行處理更直接。保存在多個文件里,逐個處理即可。SQL不適用的情況下,從編程來說Hadoop也沒那么糟糕,但相比Python腳本仍然沒有什么優勢。

除了難以編程,Hadoop還一般總是比其他技術方案要慢。只要索引用得好,SQL查詢非常快。比如要計算join,PostgreSQL只需查看索引(如果有),然后查詢所需的每個鍵。而Hadoop呢,必須做全表掃描,然后重排整個表。排序通過多台機器之間分片可以加速,但也帶來了跨多機數據流處理的開銷。如果要處理二進制文件,Hadoop必須反復訪問namenode。而簡單的Python腳本只要反復訪問文件系統即可。

可我的數據超過了5TB!

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

用Hadoop唯一的好處是擴展。如果你的數據是一個數TB的單表,那么全表掃描是Hadoop的強項。此外的話,請關愛生命,盡量遠離Hadoop。它帶來的煩惱根本不值,用傳統方法既省時又省力。

附注:Hadoop也是不錯的工具

我可不是成心黑Hadoop啊。其實我自己經常用Hadoop來完成其他工具無法輕易完成的任務。(我推薦使用Scalding,而不是Hive或者Pig,因為你可以用Scala語言來寫級聯Hadoop任務,隱藏了MapReduce底層細節。)我本文要強調的是,用Hadoop之前應該三思而行,別500MB數據這樣的蚊子,你也拿Hadoop這樣的大炮來轟。

評論
 

已有35條評論

  • 最新
ljx930520  2015-01-31 14:28
怎樣用pandas讀GB級的數據啊?~內存溢出了
0
我是一只魂  2015-04-13 19:13
你好,不知道你的問題解決沒? 我用的是pandas0.16版本,python2.7.5,用pandas加載幾百兆的數據出現MemoryError。求助解決!
0
畢加索愛編程  2014-09-26 20:08
了解hadoop是必須的,現在hadoop更新的很快,基本上一兩個月就能發布一個新版本。 各種性能也在提高。 即使對hadoop的褒貶不一,但是不能否認它是一個非常優秀的分布式平台,大家可以多了解一點。 目前最新的hadoop是hadoop2.5.1,界面什么的都更新了
0
yfteach  2014-08-09 18:34
雲凡教育Hadoop2.x架構詳解和偽分布式環境搭建視頻分享http://www.yfteach.com
0
haitao  2014-03-29 11:29
百G、10億條級別,mssql2005就完全勝任——內存大點、分區表
0
Mea_Culpa  2013-12-16 15:24
現在都好高級,讓我這用awk 分進程的情何以堪...
0
baidu_23542553  2014-11-19 17:08
同感啊 awk飄過
0
瓜瓜東西  2013-11-14 08:45
hadoop也不是啥高新的技術,只是現階段說有的技術排列組合到一起,實現了一些功能,大數據庫處理,內存處理能力已經到天花板了,技術不好提升了
0
紅帆軟件  2013-09-21 15:00 來自 新浪微博
路要自己走,樂在其中才有建樹,追風總會隨風而散
0
hills  2013-09-20 22:47
個人認為,Hadoop的分布式計算和可以理論上無限的水平擴展是優勢,業務復雜度一般的TPS達到1萬是小CASE。
0
BYSF_XF  2013-09-20 12:46
我上次去一家公司,做小項目的,面試居然還問到了負載均衡什么的,簡直扯蛋
-1
cheniwantyou  2013-09-20 12:19
那些小破公司動不動也吹神馬hadoop啊,其實都是人傻沒辦法。這些完全就是炒作罷了
0
hctsai  2013-09-20 01:28
真懷疑作者學歷怎麼拿的,還當過CTO。MapReduce 解決的不只是 Scalability 問題,精隨也不只是把工作分到不同節點運算後再合併。更關鍵的解決 Atomic運算的互鎖卻忽略不提。談論Big Data 只考慮數據輛大小,而不考慮處理速度、資料變異性、容錯,真的是誤導新人。
1
期科比  2015-10-11 12:20

說得有理啊

0
車東  2013-09-19 19:39 來自 新浪微博
@梁斌penny 你研究的內存數據庫有對此過一些來源引擎嗎?
0
xg1103  2013-09-19 17:14
路過~~~~~~~~~
0
搬磚工人  2013-09-19 09:54
其實Hive也是寫的SQL語句
0
getclass  2013-09-18 22:04
這句話說的太精辟了 “Hadoop其實是挺局限的。它無非是運行某個通用的計算,用SQL偽代碼表示就是: SELECT G(...) FROM table GROUP BY F(...) 你只能改變G和F操作,除非要在中間步驟做性能優化(這可不怎么好玩!)。其他一切都是死的。”
0
我心向着佛  2013-09-18 19:24 來自 新浪微博
[圍觀]
0
旖旎嫣兒  2013-09-18 16:14 來自 新浪微博
看到了,私信了
0
Bai-Bertie  2013-09-18 16:13 來自 新浪微博
有道理!
0
iamxiami  2013-09-18 15:05
每小時1TB的數據呢? 公司做的項目,每小時差不多可能有1TB的數據. 用戶有要求需要秒級查詢數據(不統計),為了滿足多要求,只能選擇冗余多份存放HBASE,更有趣是客戶可能需要個IN的操作,有幾個列是樹型的結構,很可能他查一個數據,條件就幾MB,轉成幾萬條查詢... 還需要分頁... NND,對N多查詢自己做seek... 哎~ 真的沒什么好替換的方案,被逼的!
0
普世編程技術  2013-09-20 11:49
有個概念叫OLAP知道不? 復雜的,批量數據,就應該先安排作業,然后一天之后才拿到結果。 hadoop這樣的東西,只適合google這等即使搜索的業務,所以google自己研究論文,自己實現自己的業務技術。 是個人,是個公司就講hadoop,就和非洲某個吃不飽飯的小村庄,討論人家美國總統選舉一樣荒唐可笑。
0
sniffer12345  2013-09-18 14:42
即便是5TB 你上mysql集群也比hadoop好得多
-1
juefan_c  2013-09-18 14:39
也不見得很對, Hadoop能處理上TB級別的數據, 也能處理100M級別的小數據, 但不見得拿100M級別的數據用其它工具處理就是明智的, 例如這100M的數據得從1TB的數據中生成時, 如果反復遷移數據的話, 那成本更大!
0
胡爭輝  2013-09-18 14:33 來自 新浪微博
期待翻譯后我好轉發
0
白碩SH  2013-09-18 14:18 來自 新浪微博
太拽了!
0
胡爭輝  2013-09-18 13:57 來自 新浪微博
澆滅NoSQL虛火從清算Hadoop入手
0
好兵帥克  2013-09-18 13:52
用Hadoop之前應該三思而行,別500MB數據這樣的蚊子,你也拿Hadoop這樣的大炮來轟。這才是核心!
2
ictcamera  2013-09-18 13:51
國內磚家一般不希望把這層紙給捅破
0
外號cook  2013-09-18 13:29
不太懂
0
無聊找樂  2013-09-18 12:27
其實用的人未必不知道這些。 炒作新概念使用新技術 不過是一種營銷手段罷了~
0
Well工作室  2013-09-18 11:59
因地制宜!
0
308682805  2013-09-18 11:47
這個是准確的
0
m101162004  2013-09-18 11:28
 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM