《易經(jīng)·系辭》有云：“形而上者謂之道，形而下者謂之器”。同理，任何技術(shù)都可以從道和器的角度去解讀，一門技術(shù)，只知道器不知道道，走不遠，只知道道而不知道器，啥也干不了，只能空口吹牛逼！談及大數(shù)據(jù)時亦如此，本文著重道的層面。
總覽
國內(nèi)大數(shù)據(jù)這詞比較火是從2012年左右開始的，從那時起，各大媒體、公司開始瘋狂吹棒大數(shù)據(jù)、云計算，很多大數(shù)據(jù)、云計算八桿子打不著的產(chǎn)品也給自己起了個響當當?shù)拿纸心衬吃?，逼格可不小?/p>
國外大數(shù)據(jù)在0幾年就有應(yīng)用了。03年，Google發(fā)表了一篇名為The Google File System的論文，論文中提出了一種分布式文件系統(tǒng)，可見人家早已有研究?？汕傻氖牵敃r有個叫Doug Cutting的大叔正在開發(fā)一個開源搜索引擎Nutch，受此論文啟發(fā)，大叔瞬間獲得了洪荒之力，一口氣寫了一個開源的分布式文件系統(tǒng)—Nutch Distributed File System。
04年，Google再次放大招，發(fā)表了MapReduce,Simplified Data Processing on Large Clusters的論文，那位大叔再次將MapReduce計算模型實現(xiàn)了。
06年1月，Yahoo啟動Hadoop項目，Nutch Cutting大叔也加入了雅虎，就這樣Nutch項目變成了Hadoop他爹，Hadoop從他爹那里繼承了兩樣重量級的東西，一個是分布式文件系統(tǒng)NDFS，Hadoop重命名為HDFS，另一個就是MapReduce計算模型。
06年2月，Apache Hadoop項目正式啟動，至此，第一個開源的大數(shù)據(jù)計算平臺誕生了。
Hadoop主要解決了大數(shù)據(jù)處理的2個問題，其一是海量數(shù)據(jù)的存儲，其二是海量數(shù)據(jù)的計算。有了Hadoop，大數(shù)據(jù)處理問題是不是都解決了呢？程序員們同意，但是現(xiàn)實需求不同意??！有了新需求，你不去解決，總有人解決！于是，大數(shù)據(jù)計算平臺在和現(xiàn)實需求賽跑的這場馬拉松中，跑到了現(xiàn)在，在決戰(zhàn)現(xiàn)實需求的過程中，他們演化成了四支隊伍，分別應(yīng)對不同的需求，目前這四支隊伍及其代表如圖1所示。
從圖1中，我們可以看出這四支隊伍分別是以Hadoop為代表大數(shù)據(jù)批處理平臺、以Storm為代表的大數(shù)據(jù)流式處理平臺、以Spark為代表的大數(shù)據(jù)交互式處理平臺和以黑客帝國里男女主角命名的大圖數(shù)據(jù)處理平臺。下面分別去拜訪一下他們。
Hadoop
前面提到，Hadoop早在06年2月的時候就在Apache開源了，發(fā)展到今天，其穩(wěn)定版本已經(jīng)到2.8版本了，本文寫作時，Hadoop3.0已開始了Alpha測試。目前Hadoop包括的模塊如圖2所示。
從圖2中可以看出，目前Hadoop包括四大模塊。Hadoop Common，Hadoop里的雷鋒同志，專為大家提供公共服務(wù)的。HDFS，專治海量數(shù)據(jù)存儲的。Hadoop YARN(Yet Another Resource Negotiator)，Hadoop2.X新成員，主管集群資源協(xié)調(diào)，集群資源利用率低就找他麻煩了（哈哈）。Hadoop MapReduce，海量數(shù)據(jù)計算編程模型，使用MapReduce編程處理大數(shù)據(jù)，主要分兩步，首先實現(xiàn)Mapper接口的map方法，將輸入的key-value鍵值對轉(zhuǎn)化為中間狀態(tài)的key-value鍵值對輸出，比如，在wordCount中，輸入的key-value鍵值對中key是該行文本首字符在文本中的偏移量，value自然就是文本行，經(jīng)過map方法轉(zhuǎn)換后，key值是文本行經(jīng)過分割后的單詞，value是1。之后再實現(xiàn)Reducer接口的reduce方法，對輸入的鍵值對按照key進行規(guī)約輸出即可，在wordCount中，輸入的key就是單詞，value是這個單詞出現(xiàn)次數(shù)的迭代器（iterator），reduce方法累加迭代器中的值，最后輸出每個單詞及其出現(xiàn)次數(shù)的key-value對。
那么，在變化無窮的現(xiàn)實需求面前，Hadoop是不是無懈可擊呢？或者說他強大的背后有哪些缺點呢？
現(xiàn)實需求和程序員們發(fā)現(xiàn)，Hadoop有兩個大“缺點”，其一，延遲高，無法進行實時處理。這沒什么奇怪的，Hadoop計算的數(shù)據(jù)主要存放在磁盤上，需要不斷訪問磁盤，速度不慢才怪，再者，Hadoop的基因是批處理，追求的是高吞吐量，不是低延遲。其二，Hadoop MapReduce編程模型為大數(shù)據(jù)計算帶來簡單的同時也帶來了復(fù)雜。簡單是實現(xiàn)了map、reduce方法即可，復(fù)雜是現(xiàn)實需求不是wordCount那么簡單的（都是需求惹的禍），往往需要多重map、reduce。這就麻煩了，map來reduce去的，最后不知道reduce到哪去了，高層的需求邏輯被深深地掩埋在各種低層的map、reduce中！這就好比C/C++中的指針，指來指去，最后不知道飛哪兒去了，不是誰都可以駕馭好的。
大牛們在躺了Hadoop的那些坑后，決定自己填一下這些坑，于是有了新的大數(shù)據(jù)計算平臺，Storm就是為填Hadoop高延遲的坑而誕生的。
Storm
Storm填了Hadoop高延遲的坑，而且填得平平整整，使大數(shù)據(jù)實時計算觸手可及。Storm采用內(nèi)存來存計算的數(shù)據(jù)，計算速度那是相當?shù)目欤湓诠俜焦嫉臄?shù)據(jù)中，1秒鐘可以處理百萬條元組。Storm對一個計算的高級抽象叫Topology（拓撲），其結(jié)構(gòu)如圖3所示。
在圖3中，長得像水龍頭那樣的叫Spout，是Storm拓撲中的數(shù)據(jù)源，負責向拓撲發(fā)射數(shù)據(jù)。長得像閃電那樣的叫Bolt，負責處理上游來的數(shù)據(jù)，將處理結(jié)果持久化或者發(fā)射到下游Bolt。整個Storm拓撲就是一個有向無環(huán)圖（DAG），顯然其是一種基于圖進行計算的思想，后面還會遇到這種計算思想。
在集群中運行時，Storm借助Zookeeper對各個組件進行協(xié)調(diào)，集群環(huán)境下的Storm如圖4 所示。
從圖4可以看出，和Hadoop一樣，集群中的Storm也是主從架構(gòu)。主控節(jié)點運行Nimbus守護進程，負責任務(wù)分發(fā)和監(jiān)聽從節(jié)點的狀態(tài)，各個從節(jié)點運行Supervisor守護進程，負責執(zhí)行任務(wù)并向主節(jié)點報告狀態(tài)信息。Zookeeper本身就是一個集群管理器，當然干它本職的工作了。
Storm已經(jīng)填好了Hadoop高延遲的坑，但是沒有填MapReduce的坑，Storm采用的是和MapReduce不一樣的計算模型，這個坑Spark來填。
Spark
在Hadoop里面map來reduce去，最后不知道reduce到哪去了，Spark把這個坑給填了，而且填得非常完美！Spark繼承了MapReduce的很多思想，當然也有很多自己的創(chuàng)新，這才是關(guān)鍵。Spark的編程API抽象層次相當高，把底層的各種map、reduce給屏蔽了，甚至把集群中可以屏蔽的細節(jié)一并屏蔽掉，這些東西對開發(fā)人員是透明的。在Spark中，直接面向高層的業(yè)務(wù)邏輯編程，具體底層是怎么map、reduce的，Spark幫我們做好了，不會存在map、reduce迷路的現(xiàn)象了。Spark還有一大突破是大數(shù)據(jù)交互式處理，Spark提供了Python和Scala的shell，在shell環(huán)境下，對大數(shù)據(jù)的計算，輸入命令回車即可得結(jié)果（Spark也是基于內(nèi)存計算的，相當快?。?，這一點是整個大數(shù)據(jù)處理的一大突破，不得不給Spark點贊！Spark的架構(gòu)如圖5所示。
圖5展示了Spark的各個方面。Spark Core是Spark的內(nèi)核部分，Spark SQL是Spark的結(jié)構(gòu)化數(shù)據(jù)操作組件。Spark Streaming是Spark流式大數(shù)據(jù)處理的組件，對！不只是Storm能夠進行流式大數(shù)據(jù)處理，Spark也可以，而且Spark的流式計算API抽象層次更高，當然編程也就更簡單。MLib是Spark的機器學(xué)習(xí)庫，GraphX則是Spark針對大圖數(shù)據(jù)提供的計算庫。以上是Spark的主要編程庫，Spark要在集群中運行，還需要一個東西，集群管理器。這塊Spark也做得很好，提供了自己的集群管理器（Standalone），不需要依賴第三方集群管理器就可以輕松部署Spark集群。當然，Spark也支持第三方集群管理器，Spark的集群管理器設(shè)計為可插拔的。目前，Spark支持比較好的集群管理器是YARN和Mesos。
集群中的Spark同樣是主從架構(gòu)，主控節(jié)點運行Spark驅(qū)動器程序，負責任務(wù)分發(fā)、協(xié)調(diào)和監(jiān)聽各從節(jié)點狀態(tài)，從節(jié)點負責任務(wù)執(zhí)行和狀態(tài)匯報。
大圖數(shù)據(jù)計算
圖是由若干結(jié)點和邊組成的數(shù)據(jù)結(jié)構(gòu)，這個大學(xué)數(shù)據(jù)結(jié)構(gòu)課里就學(xué)過了。當圖有成千上萬個結(jié)點，再加上成千上萬條邊時，對圖數(shù)據(jù)的快速計算無疑是有挑戰(zhàn)的，比如實時規(guī)劃最短路徑。針對這一需求，Google、Microsoft等公司提出了自己的解決方案，Google有Pregel，微軟則一不做二不休，搞了兩個，還生怕名氣不大，干脆用the Matrix里的男女主角來命名，分別叫做Neo4j和Trinity。
“知之為知之，不知為不知”，關(guān)于大圖數(shù)據(jù)計算，我目前還沒有遇到這樣的場景，當然也沒有基于Neo4j和Trinity編程過，本節(jié)到此為止。
入門建議
本節(jié)專為想入門大數(shù)據(jù)處理的新人而寫，大神請?zhí)^！
“我想入門大數(shù)據(jù)處理，但是看到這些五花八門的技術(shù)，心生恐懼，無從下手，怎么辦？”，一位學(xué)弟這樣問我。是的，學(xué)大數(shù)據(jù)處理是有門檻的，各種大數(shù)據(jù)計算框架都是分布式的，集群來集群去的，我哪有那么多硬件資源可用？可是這已經(jīng)成為過去時了，Hadoop時代是這樣的，現(xiàn)在不是了！這或許也是Hadoop的不足吧。Storm和Spark這些后出來的技術(shù)都在變得對程序員越來越友好，開發(fā)、運行Storm和Spark應(yīng)用程序不需要什么集群支持，你現(xiàn)在寫代碼的PC機就夠了，因為Storm和Spark都支持本地模式運行。在Maven里面加入相應(yīng)依賴后，即可基于它們的API編程了。
所以，我推薦的學(xué)習(xí)路徑不是從Hadoop開始，而是從Storm或者Spark開始，先把那個經(jīng)典的wordCount跑起來，再去考慮集群環(huán)境部署之類的，有一定的積累后，再去部署Hadoop進行開發(fā)，當然在之前是可以看Hadoop的編程思想的，必究后來者從它哪里繼承了不少東西。
總結(jié)
至此，本文啰嗦了半天，終于介紹完了到目前為止，在與變化無窮的現(xiàn)實需求賽跑中成長起來的四支優(yōu)秀的大數(shù)據(jù)計算隊伍。都說是隊伍，每支隊伍里面還有很多隊員，本文只是拋磚引玉。
最后再啰嗦一句，大數(shù)據(jù)計算與現(xiàn)實需求在進行的是一場沒有終點的馬拉松賽跑，隨著需求的變化，大數(shù)據(jù)計算的隊伍也會不斷地革新。
