近日，博客園作者leftnoteasy撰寫了一篇題為“為什么我相信Hadoop一定是分布式計算的未來”文章，以此與大家分享自己的觀點。
寫在前面的話：
今天聽同事分享了一篇很有意思的講座，叫做"Why Map-Reduce Is Not The Solution To Your Big-Data Problem"(為什么Map-Reduce不是你的“大數(shù)據(jù)”問題的解決方案)。同事很牛，也分享了很多非常有價值的觀點，不過他預言Map-Reduce將會在5年之內消失（而且還呼吁有做存儲方面的牛人來預言一下，Hdfs將在5年之內消失），這個話題如果成立的話，讓我這個目前在Hadoop工程師，感到無比的壓力。這里不為了爭個你死我活，只是談談自己的一些想法。另外由于這位同事的分享是內部進行的，這里就不透露分享中具體的內容了，只談談自己的觀點。
（本文需要對Hadoop有一定的基礎方可理解）
Hadoop為何物？
雖說Hadoop的名聲很大，但是總還是有同學不太了解的，這里一筆帶過一下。
Google分布式計算三駕馬車：
Hadoop的創(chuàng)始源頭在于當年Google發(fā)布的3篇文章，被稱為Google的分布式計算三駕馬車（Google還有很多很牛的文章，但是在分布式計算方面，應該這三篇的影響力最大了）：http://blog.sina.com.cn/s/blog_4ed630e801000bi3.html，鏈接的文章比我介紹得更清晰，當然最好還是看看原文了，這是做分布式系統(tǒng)、分布式計算的工程師必修課。
Google File System用來解決數(shù)據(jù)存儲的問題，采用N多臺廉價的電腦，使用冗余（也就是一份文件保存多份在不同的電腦之上）的方式，來取得讀寫速度與數(shù)據(jù)安全并存的結果。
Map-Reduce說穿了就是函數(shù)式編程，把所有的操作都分成兩類，map與reduce，map用來將數(shù)據(jù)分成多份，分開處理，reduce將處理后的結果進行歸并，得到最終的結果。但是在其中解決了容錯性的問題。
BigTable是在分布式系統(tǒng)上存儲結構化數(shù)據(jù)的一個解決方案，解決了巨大的Table的管理、負載均衡的問題。
Google就靠著這幾樣技術，在搜索引擎和廣告方面取得了舉世矚目的成就。不過Google不是傻的，這三篇文章雖然都是干貨，但是不是直接就可以用的。話說Google發(fā)表了這三篇文章后，在學術界引起了軒然大波，大家對這三樣東西提起了濃厚的興趣，都想著是不是可以實現(xiàn)一下，以為己用。
Doug Cutting：
Doug Cutting之前是一個非常有名的開源社區(qū)的人，創(chuàng)造了nutch與lucene（現(xiàn)在都是在Apache基金會下面的），nutch之前就實現(xiàn)了一個分布式的爬蟲抓取系統(tǒng)。等Google的三駕馬車發(fā)布后，Doug Cutting一看，挖靠這么厲害的技術，于是就實現(xiàn)了一個DFS(distributed file system)與Map-Reduce（大牛風范?。?，集成進了Nutch，作為Nutch的一個子項目存在。那時，是2004年左右。
在互聯(lián)網(wǎng)這個領域一直有這樣的說法：
“如果老二無法戰(zhàn)勝老大，那么就把老大賴以生存的東西開源吧”
當年與Google還是處在強烈競爭關系的Yahoo!于是招了Doug兄進來，把老大賴以生存的DFS與Map-Reduce開源了。開始了Hadoop的童年時期。差不多在2008年的時候，Hadoop才算逐漸成熟。
現(xiàn)在的Hadoop:
現(xiàn)在的Hadoop不僅是當年的老二Yahoo的專用產品了，從Hadoop長長的用戶名單中，可以看到Facebook,可以看到Linkedin，可以看到Amazon，可以看到EMC, eBay，Tweeter，IBM, Microsoft, Apple, HP...(后面的一些未必是完全使用)。國內的公司有淘寶、百度等等。
我來定義一下Hadoop：
Hadoop是一套開源的、基礎是Java的、目前能夠讓數(shù)千臺普通、廉價的服務器組成一個穩(wěn)定的、強大的集群，使其能夠對pb級別的大數(shù)據(jù)進行存儲、計算。已經(jīng)具有了強大穩(wěn)定的生態(tài)系統(tǒng)，也具有很多使用的延伸產品。比如做查詢的Pig, 做分布式命名服務的ZooKeeper, 做數(shù)據(jù)庫的Hive等等。
為什么世界上只有一個Hadoop？
我的前公司是國內某一個著名互聯(lián)網(wǎng)公司的子公司，專注做云計算，我也在這個公司最興盛的時候進入，當時宣傳的口號是“做最好的云計算”，就是希望自己開發(fā)一套存儲計算系統(tǒng)（就是類似于前面提到過的dfs與map-reduce），并且克服一些Hadoop的缺點（比如說用c++去實現(xiàn)，克服Java的一些性能問題）。后來結局可能大家也猜到了，投入了很多錢，招了不少牛人，確實也做出了還算不錯的云計算（至少在國內是數(shù)一數(shù)二的）。但是最終不管從穩(wěn)定性還是效率上還是scalable來說，都遠遠被Hadoop甩在了后面。雖然我前公司這個云計算項目是否會成功，這里沒辦法預測，但是前途終究還是比較黯淡的。
最近一年還聽說國內不少的互聯(lián)網(wǎng)巨頭都成立了云計算部門，做“自己的”云計算，有些小得像創(chuàng)業(yè)時期一樣的公司，都寧愿自己寫一套map-reduce框架，不愿意直接使用Hadoop?？赡苓@個跟國人的想法，武功秘笈一定要自己藏著，不讓別人學，傳男不傳女。對別人白給你的東西，非常不放心，覺得大家都能學到的東西，肯定競爭力是不夠的。
除開心態(tài)問題不談，但從技術實力上來說，一般國內公司的核心開發(fā)團隊的能力和當年的Yahoo!比，還是有非常大的差距的，至少像是Doug兄這樣的大牛是很罕見的，從開發(fā)者的實力來說，就差了不止一個檔次。
其次從積累來說，Hadoop從初創(chuàng)到現(xiàn)在也經(jīng)過了至少7年的積累的，碰到過很多刁鉆客戶的問題都慢慢克服了（比如Facebook的超大數(shù)據(jù)存儲），帶給用戶的經(jīng)驗教訓是很充足的，比如說性能調優(yōu)這一塊，就有非常多的文章去介紹。而自己開發(fā)一個，什么都需要從頭再來。
最后也是最重要的是，Hadoop形成了一個強大穩(wěn)定的生態(tài)系統(tǒng)，里面有生產者（共享改進的代碼、fix bug），也有消費者（使用項目并且反饋經(jīng)驗），Hadoop的用戶也可以獲得較大的經(jīng)濟利益（不花錢買軟件，還可以增加效率）。對于一個開源社區(qū)來說，構建出一個完整的生態(tài)系統(tǒng)是非常非常的困難，一旦構造出來了，項目就會很穩(wěn)定的往前去進步。
Hadoop的優(yōu)勢
之前分析了一些“虛”的東西，比如生態(tài)系統(tǒng)什么的，這里說說一些實際的東西。
Benchmark:
Hadoop現(xiàn)在保持了很多漂亮的記錄：
存儲：現(xiàn)在世界上最大的Hadoop集群目前在Facebook，可以存儲30PB的數(shù)據(jù)
計算：Hadoop是目前Terasort記錄的保持者（參見：http://sortbenchmark.org/)，Terasort是給出1TB的隨機數(shù)據(jù)，看誰能夠在最短的時間內完成排序，Hadoop使用了1400多個節(jié)點，在2分鐘內完成1T的數(shù)據(jù)排序。
這里順便說一下，之前給出網(wǎng)站里面有很多的benchmark，可以看到Hadoop的集群是最大的，使用的機器最多的，像是TritonSort這樣的集群，使用了區(qū)區(qū)50多個節(jié)點，最終的結果并不比Hadoop差太多，但是這里得注意一下。TritonSort是專門用來做排序的，里面加入了相當多的優(yōu)化，但是Hadoop是一個通用的集群，并沒有為了一種任務進行如此多的優(yōu)化。從用戶的角度上來說，愿意花錢去買一個只會排序的電腦是意義不那么大的。
注：左右兩邊屬于兩種不同的terasort，hadoop是其中一種的記錄保持者
能做什么？
前面說的基本的存儲和計算Hadoop是一定能勝任的，下面談談一些“高級”的功能。
常見的數(shù)據(jù)庫操作，比如orderby、select這樣的操作都可以的，Hive就是支持這樣的Sql模型，能夠將Sql語句最終轉化到Map-Reduce程序中去。其性能和可用性已經(jīng)得到了證明，F(xiàn)acebook就用它做了不少的數(shù)據(jù)分析的工作
常見的機器學習、矩陣分析算法，目前Mahout作為一個發(fā)展迅速的項目，在逐漸填補Hadoop在機器學習領域的空白，現(xiàn)在常見的分類、聚類、推薦、主成分分析算法（比如SVD）都已經(jīng)有相應的Map-Reduce實現(xiàn)了。雖然目前從用戶群和效率上來說是不夠的，但是從它的發(fā)展來說應該會很快的達到工業(yè)界的標準
Hadoop的劣勢
現(xiàn)在Hadoop依然有很多的問題沒有解決，這讓有些人非常的懷疑Hadoop的未來，這里談談Hadoop的一些重要的劣勢
HA(High Availability)高可用性:
這一點是Hadoop非常弱的一個缺點，不管是Hdfs還是Map-reduce，都是采用單master的方式，集群中的其他機器都是與一臺中心機器進行通信，如果這個中心機器掛了，集群就只有不工作了（不一定數(shù)據(jù)會丟失，但是至少需要重啟等等工作)，讓可用性變得更低。這個一般叫做單點失敗(single point of failure,SPOF)。
雖然現(xiàn)在有些公司已經(jīng)給出了解決方案，比如EMC就有用Vmware搭建虛擬集群，對master節(jié)點進行鏡像備份，如果master掛掉，那么立刻換上鏡像備份的機器，使其可用性變高，不過這個終究不是一個內置的解決方案，而且Vmware這一套東西也并不便宜。
不過之后這個問題將會得到非常好的解決，我在Hadoop的未來這一章將說以說。
Hadoop目前解決得不那么好的一些算法：
Join等:
Map-Reduce還有一個問題是，對于Join這個最常見的數(shù)據(jù)庫操作，支持力度還是不夠，特別是針對那種上TB的數(shù)據(jù)，Join將會很不給力，現(xiàn)在已經(jīng)有了一些解決方案，比如說SIGMOD'2010的這篇文章：
A Comparison of Join Algorithms for Log Processing in MapReduce
不過在現(xiàn)在的情況下，只有盡量的避免大數(shù)據(jù)庫的Join操作
需要進行很多輪迭代、循環(huán)的算法：
對于循環(huán)，Map-Reduce稍好，比如矩陣計算，高斯消元法這樣的，循環(huán)的次數(shù)的確定的算法，實現(xiàn)起來還是不難，只是有點慢。但是迭代就更麻煩了，因為現(xiàn)在的Map-Reduce的mapper和reducer是不太方便去弄這樣的終止條件。
還有就是迭代次數(shù)超多的算法（比如說矩陣的SVD分解），在超大矩陣的情況下，迭代次數(shù)可能會上億次。而Map-Reduce在每次迭代的時候都會把數(shù)據(jù)往文件里面讀寫一遍，這樣的浪費的時間是巨大的。
其實Map-Reduce不是絕對沒有辦法去解決這些問題，而只是現(xiàn)在這個還不是最重要的日程，Hadoop還有很多很多的東西可以優(yōu)化，比如說前面提到的HA，這些東西只有往后放放，我將在之后的Hadoop的未來部分，談談未來版的Hadoop怎么去解決這些問題。
編程復雜，學習曲線陡峭：
對于一般的map-reduce框架，hello world程序就變成了word count，就是給出一堆的文本文件，最終統(tǒng)計出里面每一個不同的單詞出現(xiàn)的次數(shù)，這樣一個簡單的任務（可能在linux shell下一行就寫出來了），在Map-reduce中需要幾十行，一般新人從理解word count到寫出自己的word count，到跑通，一個星期是肯定需要的。這樣陡峭的學習曲線讓許多人難以深入。
另外還有一點Hadoop被人所詬病的是，代碼丑陋，雖然Hadoop是用高級語言Java寫成的，但是里面對每一個步驟都要分成mapper和reducer，這個被戲稱為新時代的匯編語言。
一般來說，做數(shù)據(jù)分析的人程序都寫得不咋地（強哥這樣的達人除外），能寫寫matlab，R，或者spss就差不多了，如果要讓他們去寫map-reduce，那就等于叫他們別干活了。而大數(shù)據(jù)的重要的作用就是用來做數(shù)據(jù)分析，Hadoop的未來發(fā)展必須得抓住這群數(shù)據(jù)分析師的心。
其實現(xiàn)在已經(jīng)有一些實驗中的產品，讓用戶可以用高級語言編程，不會再看到丑丑的map-reduce了。我在前公司的時候就與團隊一起做了還不錯的嘗試，至少，數(shù)據(jù)分析師可以用Python來編程了。map-reduce變成了一個底層的東西，現(xiàn)在不是某些人在分析性能的時候就貼上匯編代碼嗎，之后可能會變成在前段的程序效率不行的時候，就貼上后端Java的map-reduce程序。
所以對這個難題之后肯定會解決掉，底層分布式程序開發(fā)與用戶將被清楚的分開，之后想要寫word-count一定會像hello world一樣簡單。
Hadoop的未來怎么樣？
http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)
給出這樣的一個官方文檔，談談之后的hadoop的發(fā)展。目前的hadoop的穩(wěn)定版是0.20.x，這個0.23是個未來版，估計將在今年的Q4進行beta的發(fā)布（目前看起來，至少代碼是寫了很多了） 。
HDFS Federation
首先是一個叫做HDFS Federation的東西，它將hdfs的命名空間進行了擴展，目前的HDFS的所有文件的meta信息都保存在一臺機器的內存中，使得HDFS支持的文件數(shù)目是有限的，現(xiàn)在進行了這樣改動后，將hdfs的命名空間做成了分布式的，對之后方便對不同的用戶文件夾進行管理，還有從HDFS的實現(xiàn)上來說，都會更為簡單。
下一代的Map-Reduce：
節(jié)點數(shù)：從目前的4000增加到6000-10000臺
并發(fā)的任務數(shù):從目前的40000增加到100000
更高級的硬件支持，目前支持的硬件主要是8core, 16G ram, 4T disk, 之后將會支持16+core, 48/96G ram, 24/48T disk
架構的改變，對現(xiàn)在的JobTracker-TaskTracker的結構做了很大的改進，現(xiàn)在會用ZooKeeper去保存master的狀態(tài)，避免了之前提到的SPOF
更多的編程模式的支持（這個很重要）
比如MPI，迭代程序的處理，并且在Hadoop中運行這些類型的編程模式，并且這些程序將會被Hadoop統(tǒng)一管理
總結：
之前談了Hadoop的優(yōu)勢、劣勢等等，綜合來說就是，優(yōu)勢是很明顯的（比如這么多牛公司在用，并且也貢獻了很多的代碼），遠遠超出了其他的分布式系統(tǒng)，劣勢雖然不小，但是改進這些不足的地方是在計劃中，已經(jīng)在實施了。而且Hadoop不僅在學術界或者是工業(yè)界，都有很高的地位，綜合了這些天時地利人和，那前途還是非常光明的