大資料處理工具Hadoop是否有些名不副實?

近來多次和百度、阿裡、騰訊、中移動資料中心的架構師進行交流，同時也在網上的論壇/社區主導大資料分析範例的一些討論，與互聯網/雲開發人員進行溝通。 由此，我愉快地發現，大資料分析在中國非常普遍：不光是星巴克、紙牌屋等美國文化元素在中國廣受追捧; Hadoop也受到廣泛接納，並且在中國的雲開發人員的討論中佔據了主導地位。 但是，和其他流行事物一樣，人們在追捧討論的同時也會考慮它當前的熱度是否合理。 「如果我講Hadoop有些名不副實，會不會有人來踢館?」 ——可能全世界的主管和開發人員都在考慮這個問題。 眼下公司介紹中夾雜「大資料」等詞彙，冀圖借此提升公司形象的情況隨處可見，另一方面，開發人員購買Hadoop類書籍來自我提升也屢見不鮮。

然而更加理性的架構師則應該至少還記得最初採納Hadoop的實際考量：

a) 免費。

b) 只需要廉價(通用的)硬體——一個泛型服務器的機群仍然比一台高性能、專用的機器要便宜。

c) 開發便利。 有了龐大的使用群體，代碼基的增長速度驚人，自學成才的開發人員也隨處可見——從BBS版塊或個人的微信朋友圈就能方便找到。

這些優點很難抗拒。 但是要實現一個能夠進行自動任務追蹤、資料複製、檔共用的並行處理平臺，需要開發和維護千百萬行平臺軟體代碼，光是想一想就足以讓任何公司的工程師頭大不已。 此外，為了實現這個系統，還要專門定制硬體，又會額外增加數年的時間，此後才能真正開始開發分析應用。 那麼，是否除了Hadoop，我們就別無選擇?

讓我們再來聆聽硬體架構師的聲音：Hadoop對於某些任務而言可能十分低效：

1) 面向檔——Hadoop的輸入來自檔，並用檔來存儲中間結果，因此對於每一次Map-Reduce，其性能都取決於檔I/O。

2) 無共用——每個節點都完全擁有自己的本地資源(CPU、DRAM、本地SSD、本地HDD)，並完全依賴于本地資源，除非是通過分散式檔案系統(HDFS)請求遠端資料的情況。

因此，Hadoop對於其最初的設計目標而言過於理想，即採用一群便宜的機器來並行處理非常龐大的資料檔案，並以批次處理的模式將結果資訊濃縮到小得多的檔中。

而今，我們在微軟、Yahoo和Facebook的友人揭示了一些驚人的統計資料：除非你是在進行全網規模的關鍵字索引，否則大資料通常根本就不那麼「大」(能存放到個人筆記本電腦上)!還可以很方便地分割成小塊進行消化處理( 也就是說，不要對一整年的歷史記錄進行資料採礦，而是按天來做處理)。

a) 微軟和Yahoo的中等大小的Map-Reduce檔只有14GB。

b) 90%的Facebook Map-Reduce任務小於100GB。

絕大多數這些分析任務可以放在單個伺服器的主存儲當中。 如果有某種方式能夠共用單個機架中伺服器的存儲，可能有99%的任務都可以就此完成。 那麼我們還有必要去搗騰檔麼?何必還費事去把HDD升級成SSD?任何軟體工程師都會講：要是我的全部資料都能存放在主存儲當中....那我的速度就能快上100倍!

眼下這個夢想正在變為現實。 我在BBS版塊上發貼時，正看見「Spark峰會——4月19日，北京——100倍于Hadoop的大資料分析」的閃動宣傳條幅。 Spark改變了什麼，能號稱比Hadoop快上100倍呢?

a) 存儲內資料分析——可以不再需要通過檔案系統和磁片IO來訪問資料，對多次重複處理非常有利(Map卻無需Reduce)

b) 無共用——資料共用還是由遠端節點提出並予以滿足的一項業務請求

看來，光是去除HDFS就帶來了100倍的提升?那麼，如果硬體允許節點之間直接共用存儲中的資料結構呢?能否帶來額外的100倍提升?

就此，再進一步和大家分享一下硬體架構師有關大資料的夢想：

a) 構建帶有高速互聯的機架

b) 在機架裡堆放一組CPU(CPU池)

c) 增加共用的DRAM以及/或者非易失性存儲池

d) 以及共用的SSD/HDDs池

關於這一夢想，我們PMC「P星人」為其冠名為FDIO;Intel 稱之為RSA; Facebook以此為OpenCompute的未來; Baidu則命名為天蠍3.0。 通過它，全世界99%的大資料問題也許都能在單個機架之內得到處理。

推薦閱讀:

1.列舉不適合大資料處理的10件事情

2.從文章寫作揭開大資料處理面紗

3.大資料處理的模式 — — 系統結構、方法及發展趨勢

原文連結：HTTP://blog.csdn.net/pmc/article/details/25194467