1998年9月4日，Google公司在美國硅谷成立。正如大家所知，它是一家做搜索引擎起家的公司。

無獨有偶，一位名叫Doug?Cutting的美國工程師，也迷上了搜索引擎。他做了一個用于文本搜索的函數(shù)庫（姑且理解為軟件的功能組件），命名為Lucene。

左為Doug Cutting，右為Lucene的LOGO

Lucene是用JAVA寫成的，目標(biāo)是為各種中小型應(yīng)用軟件加入全文檢索功能。因為好用而且開源（代碼公開），非常受程序員們的歡迎。

早期的時候，這個項目被發(fā)布在Doug Cutting的個人網(wǎng)站和SourceForge（一個開源軟件網(wǎng)站）。后來，2001年底，Lucene成為Apache軟件基金會jakarta項目的一個子項目。

Apache軟件基金會，搞IT的應(yīng)該都認(rèn)識

2004年，Doug Cutting再接再勵，在Lucene的基礎(chǔ)上，和Apache開源伙伴Mike Cafarella合作，開發(fā)了一款可以代替當(dāng)時的主流搜索的開源搜索引擎，命名為Nutch。

Nutch是一個建立在Lucene核心之上的網(wǎng)頁搜索應(yīng)用程序，可以下載下來直接使用。它在Lucene的基礎(chǔ)上加了網(wǎng)絡(luò)爬蟲和一些網(wǎng)頁相關(guān)的功能，目的就是從一個簡單的站內(nèi)檢索推廣到全球網(wǎng)絡(luò)的搜索上，就像Google一樣。

Nutch在業(yè)界的影響力比Lucene更大。

大批網(wǎng)站采用了Nutch平臺，大大降低了技術(shù)門檻，使低成本的普通計算機取代高價的Web服務(wù)器成為可能。甚至有一段時間，在硅谷有了一股用Nutch低成本創(chuàng)業(yè)的潮流。

隨著時間的推移，無論是Google還是Nutch，都面臨搜索對象“體積”不斷增大的問題。

尤其是Google，作為互聯(lián)網(wǎng)搜索引擎，需要存儲大量的網(wǎng)頁，并不斷優(yōu)化自己的搜索算法，提升搜索效率。

Google搜索欄

在這個過程中，Google確實找到了不少好辦法，并且無私地分享了出來。

2003年，Google發(fā)表了一篇技術(shù)學(xué)術(shù)論文，公開介紹了自己的谷歌文件系統(tǒng)GFS（Google?File?System）。這是Google公司為了存儲海量搜索數(shù)據(jù)而設(shè)計的專用文件系統(tǒng)。

第二年，也就是2004年，Doug?Cutting基于Google的GFS論文，實現(xiàn)了分布式文件存儲系統(tǒng)，并將它命名為NDFS（Nutch Distributed File?System）。

還是2004年，Google又發(fā)表了一篇技術(shù)學(xué)術(shù)論文，介紹自己的MapReduce編程模型。這個編程模型，用于大規(guī)模數(shù)據(jù)集（大于1TB）的并行分析運算。

第二年（2005年），Doug?Cutting又基于MapReduce，在Nutch搜索引擎實現(xiàn)了該功能。

2006年，當(dāng)時依然很厲害的Yahoo（雅虎）公司，招安了Doug?Cutting。

這里要補充說明一下雅虎招安Doug的背景：2004年之前，作為互聯(lián)網(wǎng)開拓者的雅虎，是使用Google搜索引擎作為自家搜索服務(wù)的。在2004年開始，雅虎放棄了Google，開始自己研發(fā)搜索引擎。所以。。。

加盟Yahoo之后，Doug?Cutting將NDFS和MapReduce進(jìn)行了升級改造，并重新命名為Hadoop（NDFS也改名為HDFS，Hadoop Distributed File?System）。

這個，就是后來大名鼎鼎的大數(shù)據(jù)框架系統(tǒng)——Hadoop的由來。而Doug?Cutting，則被人們稱為Hadoop之父。

Hadoop這個名字，實際上是Doug?Cutting他兒子的黃色玩具大象的名字。所以，Hadoop的Logo，就是一只奔跑的黃色大象。

我們繼續(xù)往下說。

還是2006年，Google又發(fā)論文了。

這次，它們介紹了自己的BigTable。這是一種分布式數(shù)據(jù)存儲系統(tǒng)，一種用來處理海量數(shù)據(jù)的非關(guān)系型數(shù)據(jù)庫。

Doug?Cutting當(dāng)然沒有放過，在自己的hadoop系統(tǒng)里面，引入了BigTable，并命名為HBase。

好吧，反正就是緊跟Google時代步伐，你出什么，我學(xué)什么。

所以，Hadoop的核心部分，基本上都有Google的影子。

2008年1月，Hadoop成功上位，正式成為Apache基金會的頂級項目。

同年2月，Yahoo宣布建成了一個擁有1萬個內(nèi)核的Hadoop集群，并將自己的搜索引擎產(chǎn)品部署在上面。

7月，Hadoop打破世界紀(jì)錄，成為最快排序1TB數(shù)據(jù)的系統(tǒng)，用時209秒。

此后，Hadoop便進(jìn)入了高速發(fā)展期，直至現(xiàn)在。

Hadoop的核心架構(gòu)

Hadoop的核心，說白了，就是HDFS和MapReduce。HDFS為海量數(shù)據(jù)提供了存儲，而MapReduce為海量數(shù)據(jù)提供了計算框架。

Hadoop核心架構(gòu)

讓我們來仔細(xì)看看，它們分別是怎么工作的。

首先看看HDFS。

整個HDFS有三個重要角色：NameNode（名稱節(jié)點）、DataNode（數(shù)據(jù)節(jié)點）和Client（客戶機）。

典型的主從架構(gòu)，用TCP/IP通信

NameNode：是Master節(jié)點（主節(jié)點），可以看作是分布式文件系統(tǒng)中的管理者，主要負(fù)責(zé)管理文件系統(tǒng)的命名空間、集群配置信息和存儲塊的復(fù)制等。NameNode會將文件系統(tǒng)的Meta-data存儲在內(nèi)存中，這些信息主要包括了文件信息、每一個文件對應(yīng)的文件塊的信息和每一個文件塊在DataNode的信息等。

DataNode：是Slave節(jié)點（從節(jié)點），是文件存儲的基本單元，它將Block存儲在本地文件系統(tǒng)中，保存了Block的Meta-data，同時周期性地將所有存在的Block信息發(fā)送給NameNode。

Client：切分文件；訪問HDFS；與NameNode交互，獲得文件位置信息；與DataNode交互，讀取和寫入數(shù)據(jù)。?

還有一個Block（塊）的概念：Block是HDFS中的基本讀寫單元；HDFS中的文件都是被切割為block（塊）進(jìn)行存儲的；這些塊被復(fù)制到多個DataNode中；塊的大小（通常為64MB）和復(fù)制的塊數(shù)量在創(chuàng)建文件時由Client決定。

我們來簡單看看HDFS的讀寫流程。

首先是寫入流程：

1 用戶向Client（客戶機）提出請求。例如，需要寫入200MB的數(shù)據(jù)。

2 Client制定計劃：將數(shù)據(jù)按照64MB為塊，進(jìn)行切割；所有的塊都保存三份。

3 Client將大文件切分成塊（block）。

4 針對第一個塊，Client告訴NameNode（主控節(jié)點），請幫助我，將64MB的塊復(fù)制三份。

5 NameNode告訴Client三個DataNode（數(shù)據(jù)節(jié)點）的地址，并且將它們根據(jù)到Client的距離，進(jìn)行了排序。

6 Client把數(shù)據(jù)和清單發(fā)給第一個DataNode。

7 第一個DataNode將數(shù)據(jù)復(fù)制給第二個DataNode。

8 第二個DataNode將數(shù)據(jù)復(fù)制給第三個DataNode。

9 如果某一個塊的所有數(shù)據(jù)都已寫入，就會向NameNode反饋已完成。

10 對第二個Block，也進(jìn)行相同的操作。

11 所有Block都完成后，關(guān)閉文件。NameNode會將數(shù)據(jù)持久化到磁盤上。

讀取流程：

1 用戶向Client提出讀取請求。

2 Client向NameNode請求這個文件的所有信息。

3 NameNode將給Client這個文件的塊列表，以及存儲各個塊的數(shù)據(jù)節(jié)點清單（按照和客戶端的距離排序）。

4 Client從距離最近的數(shù)據(jù)節(jié)點下載所需的塊。

（注意：以上只是簡化的描述，實際過程會更加復(fù)雜。）

再來看MapReduce。

MapReduce其實是一種編程模型。這個模型的核心步驟主要分兩部分：Map（映射）和Reduce（歸約）。

當(dāng)你向MapReduce框架提交一個計算作業(yè)時，它會首先把計算作業(yè)拆分成若干個Map任務(wù)，然后分配到不同的節(jié)點上去執(zhí)行，每一個Map任務(wù)處理輸入數(shù)據(jù)中的一部分，當(dāng)Map任務(wù)完成后，它會生成一些中間文件，這些中間文件將會作為Reduce任務(wù)的輸入數(shù)據(jù)。Reduce任務(wù)的主要目標(biāo)就是把前面若干個Map的輸出匯總到一起并輸出。

是不是有點暈？我們來舉個例子。

上圖是一個統(tǒng)計詞頻的任務(wù)。

1 Hadoop將輸入數(shù)據(jù)切成若干個分片，并將每個split（分割）交給一個map task（Map任務(wù)）處理。

2 Mapping之后，相當(dāng)于得出這個task里面，每個詞以及它出現(xiàn)的次數(shù)。

3 shuffle（拖移）將相同的詞放在一起，并對它們進(jìn)行排序，分成若干個分片。

4 根據(jù)這些分片，進(jìn)行reduce（歸約）。

5 統(tǒng)計出reduce task的結(jié)果，輸出到文件。

如果還是沒明白的吧，再舉一個例子。

一個老師有100份試卷要閱卷。他找來5個幫手，扔給每個幫手20份試卷。幫手各自閱卷。最后，幫手們將成績匯總給老師。很簡單了吧？

MapReduce這個框架模型，極大地方便了編程人員在不會分布式并行編程的情況下，將自己的程序運行在分布式系統(tǒng)上。

哦，差點忘了，在MapReduce里，為了完成上面這些過程，需要兩個角色：JobTracker和TaskTracker。

JobTracker用于調(diào)度和管理其它的TaskTracker。JobTracker可以運行于集群中任一臺計算機上。TaskTracker 負(fù)責(zé)執(zhí)行任務(wù)，必須運行于 DataNode 上。

1.0版本與2.0版本

2011年11月，Hadoop 1.0.0版本正式發(fā)布，意味著可以用于商業(yè)化。

但是，1.0版本中，存在一些問題：

1 擴展性差，JobTracker負(fù)載較重，成為性能瓶頸。

2 可靠性差，NameNode只有一個，萬一掛掉，整個系統(tǒng)就會崩潰。

3 僅適用MapReduce一種計算方式。

4 資源管理的效率比較低。

所以，2012年5月，Hadoop推出了 2.0版本 。

2.0版本中，在HDFS之上，增加了YARN（資源管理框架）層。它是一個資源管理模塊，為各類應(yīng)用程序提供資源管理和調(diào)度。

此外，2.0版本還提升了系統(tǒng)的安全穩(wěn)定性。

所以，后來行業(yè)里基本上都是使用2.0版本。目前Hadoop又進(jìn)一步發(fā)展到3.X版本。

Hadoop的生態(tài)圈

經(jīng)過時間的累積，Hadoop已經(jīng)從最開始的兩三個組件，發(fā)展成一個擁有20多個部件的生態(tài)系統(tǒng)。

在整個Hadoop架構(gòu)中，計算框架起到承上啟下的作用，一方面可以操作HDFS中的數(shù)據(jù)，另一方面可以被封裝，提供Hive、Pig這樣的上層組件的調(diào)用。

我們簡單介紹一下其中幾個比較重要的組件。

HBase：來源于Google的BigTable；是一個高可靠性、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫。

Hive：是一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，通過類SQL語句快速實現(xiàn)簡單的MapReduce統(tǒng)計，不必開發(fā)專門的MapReduce應(yīng)用，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。

Pig：是一個基于Hadoop的大規(guī)模數(shù)據(jù)分析工具，它提供的SQL-LIKE語言叫Pig Latin，該語言的編譯器會把類SQL的數(shù)據(jù)分析請求轉(zhuǎn)換為一系列經(jīng)過優(yōu)化處理的MapReduce運算。

ZooKeeper：來源于Google的Chubby；它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，簡化分布式應(yīng)用協(xié)調(diào)及其管理的難度。

Ambari：Hadoop管理工具，可以快捷地監(jiān)控、部署、管理集群。

Sqoop：用于在Hadoop與傳統(tǒng)的數(shù)據(jù)庫間進(jìn)行數(shù)據(jù)的傳遞。

Mahout：一個可擴展的機器學(xué)習(xí)和數(shù)據(jù)挖掘庫。

再上一張圖，可能看得更直觀一點：

Hadoop的優(yōu)點和應(yīng)用

總的來看，Hadoop有以下優(yōu)點：

高可靠性：這個是由它的基因決定的。它的基因來自Google。Google最擅長的事情，就是“垃圾利用”。Google起家的時候就是窮，買不起高端服務(wù)器，所以，特別喜歡在普通電腦上部署這種大型系統(tǒng)。雖然硬件不可靠，但是系統(tǒng)非常可靠。

高擴展性：Hadoop是在可用的計算機集群間分配數(shù)據(jù)并完成計算任務(wù)的，這些集群可以方便地進(jìn)行擴展。說白了，想變大很容易。

高效性：Hadoop能夠在節(jié)點之間動態(tài)地移動數(shù)據(jù)，并保證各個節(jié)點的動態(tài)平衡，因此處理速度非常快。

高容錯性：Hadoop能夠自動保存數(shù)據(jù)的多個副本，并且能夠自動將失敗的任務(wù)重新分配。這個其實也算是高可靠性。

低成本：Hadoop是開源的，依賴于社區(qū)服務(wù)，使用成本比較低。

基于這些優(yōu)點，Hadoop適合應(yīng)用于大數(shù)據(jù)存儲和大數(shù)據(jù)分析的應(yīng)用，適合于服務(wù)器幾千臺到幾萬臺的集群運行，支持PB級的存儲容量。

Hadoop的應(yīng)用非常廣泛，包括：搜索、日志處理、推薦系統(tǒng)、數(shù)據(jù)分析、視頻圖像分析、數(shù)據(jù)保存等，都可以使用它進(jìn)行部署。

目前，包括Yahoo、IBM、Facebook、亞馬遜、ucloud巴巴、ucloud、百度、ucloud等公司，都采用Hadoop構(gòu)建自己的大數(shù)據(jù)系統(tǒng)。

除了上述大型企業(yè)將Hadoop技術(shù)運用在自身的服務(wù)中外，一些提供Hadoop解決方案的商業(yè)型公司也紛紛跟進(jìn)，利用自身技術(shù)對Hadoop進(jìn)行優(yōu)化、改進(jìn)、二次開發(fā)等，然后對外提供商業(yè)服務(wù)。

比較知名的，是Cloudera公司。

它創(chuàng)辦于2008年，專業(yè)從事基于Hadoop的數(shù)據(jù)管理軟件銷售和服務(wù)，還提供Hadoop相關(guān)的支持、咨詢、培訓(xùn)等服務(wù)，有點類似于RedHat在Linux世界中的角色。前面我們提到的Hadoop之父，Doug Cutting，都被這家公司聘請為首席架構(gòu)師。

Hadoop和Spark

最后，我再介紹一下大家關(guān)心的Spark。

Spark同樣是Apache軟件基金會的頂級項目。它可以理解為在Hadoop基礎(chǔ)上的一種改進(jìn)。

它是加州大學(xué)伯克利分校AMP實驗室所開源的類Hadoop MapReduce的通用并行框架。相對比Hadoop，它可以說是青出于藍(lán)而勝于藍(lán)。

前面我們說了，MapReduce是面向磁盤的。因此，受限于磁盤讀寫性能的約束，MapReduce在處理迭代計算、實時計算、交互式數(shù)據(jù)查詢等方面并不高效。但是，這些計算卻在圖計算、數(shù)據(jù)挖掘和機器學(xué)習(xí)等相關(guān)應(yīng)用領(lǐng)域中非常常見。

而Spark是面向內(nèi)存的。這使得Spark能夠為多個不同數(shù)據(jù)源的數(shù)據(jù)提供近乎實時的處理性能，適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場景。

在相同的實驗環(huán)境下處理相同的數(shù)據(jù)，若在內(nèi)存中運行，那么Spark要比MapReduce快100倍。其它方面，例如處理迭代運算、計算數(shù)據(jù)分析類報表、排序等，Spark都比MapReduce快很多。

此外，Spark在易用性、通用性等方面，也比Hadoop更強。

所以，Spark的風(fēng)頭，已經(jīng)蓋過了Hadoop。

結(jié)語

以上，就是小棗君關(guān)于大數(shù)據(jù)相關(guān)技術(shù)的介紹。

小棗君個人覺得，相比于云計算技術(shù)來說，大數(shù)據(jù)的應(yīng)用范圍比較有限，并不是所有的公司都適用，也不是所有的業(yè)務(wù)場景都適用，沒有必要跟風(fēng)追捧，更不能盲目上馬。

対于個人來說，大數(shù)據(jù)系統(tǒng)的架構(gòu)非常龐大，內(nèi)容也非常復(fù)雜，入門起來會比較吃力（實踐練習(xí)倒是門檻很低，幾臺電腦足矣）。所以，如果不是特別渴望朝這個方向發(fā)展，可以不必急于學(xué)習(xí)它。或者說，可以先進(jìn)行初步的了解，后續(xù)如果真的要從事相關(guān)的工作，再進(jìn)行深入學(xué)習(xí)也不遲。

回答這個問題之前，首先要搞明白spark和Hadoop各自的定義以及用途，搞明白這個之后這個問題的答案也就出來了。

首先Apache Spark 是專為大規(guī)模數(shù)據(jù)處理而設(shè)計的快速通用的計算引擎。

Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)。

Spark是一個計算引擎，主要用來做數(shù)據(jù)計算用。其核心模塊包括Spark Core，Spark Streaming（流式計算），MLlib（集群學(xué)習(xí)），GraphX（圖計算模塊）。

Hadoop主要包括HDFS（分布式存儲）、MapReduce（并行計算引擎）、Yarn（資源調(diào)度）。

由此看來，Spark≈MapReduce，同時Spark相比于MapReduce有著更方便的函數(shù)處理，在計算速度，開發(fā)效率上更有著無法比擬的優(yōu)勢。Spark也支持外部的內(nèi)存管理組件（Alluxio等），不排除未來Spark也提供分布式文件存儲，目前來看沒戲。其現(xiàn)在的發(fā)展目標(biāo)主要集中在機器學(xué)習(xí)這塊，已經(jīng)提供了一體化的機器學(xué)習(xí)平臺。這一點Flink還差點事。目前在國內(nèi)更多的應(yīng)用場景是Spark+Hadoop，即使用Spark來做數(shù)據(jù)計算，用Hadoop的HDFS來做分布式文件存儲，用Yarn來做資源調(diào)度。

總結(jié)為以下四點，可以參考。

1、Hadoop底層使用MapReduce計算架構(gòu)，只有map和reduce兩種操作，表達(dá)能力比較欠缺，而且在MR過程中會重復(fù)的讀寫hdfs，造成大量的磁盤io讀寫操作，所以適合高時延環(huán)境下批處理計算的應(yīng)用；

2、Spark是基于內(nèi)存的分布式計算架構(gòu)，提供更加豐富的數(shù)據(jù)集操作類型，主要分成轉(zhuǎn)化操作和行動操作，包括map、reduce、filter、flatmap、groupbykey、reducebykey、union和join等，數(shù)據(jù)分析更加快速，所以適合低時延環(huán)境下計算的應(yīng)用；

3、spark與hadoop最大的區(qū)別在于迭代式計算模型。基于mapreduce框架的Hadoop主要分為map和reduce兩個階段，兩個階段完了就結(jié)束了，所以在一個job里面能做的處理很有限；spark計算模型是基于內(nèi)存的迭代式計算模型，可以分為n個階段，根據(jù)用戶編寫的RDD算子和程序，在處理完一個階段后可以繼續(xù)往下處理很多個階段，而不只是兩個階段。所以spark相較于mapreduce，計算模型更加靈活，可以提供更強大的功能。

4、但是spark也有劣勢，由于spark基于內(nèi)存進(jìn)行計算，雖然開發(fā)容易，但是真正面對大數(shù)據(jù)的時候，在沒有進(jìn)行調(diào)優(yōu)的輕局昂下，可能會出現(xiàn)各種各樣的問題，比如OOM內(nèi)存溢出等情況，導(dǎo)致spark程序可能無法運行起來，而mapreduce雖然運行緩慢，但是至少可以慢慢運行完。

Hadoop擁有強大的生態(tài)，作為一種分布式系統(tǒng)架構(gòu)，Hadoop適用于低成本、大規(guī)模的數(shù)據(jù)分析環(huán)境，能夠接受海量數(shù)據(jù)的存儲和運算，雖然Spark改進(jìn)了很多MapReduce的算法，但實際上更多的是作為Hadoop的一種補充。從性能方面來比較，Spark在于運算速度快。Spark還可以執(zhí)行批量處理，然而它真正擅長的是處理流工作負(fù)載、交互式查詢和機器學(xué)習(xí)。

相比MapReduce基于磁盤的批量處理引擎，Spark賴以成名之處是其數(shù)據(jù)實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列為是一個模塊。Spark有自己的頁面，因為雖然它可以通過YARN(另一種資源協(xié)調(diào)者)在Hadoop集群中運行，但是它也有一種獨立模式。它可以作為 Hadoop模塊來運行，也可以作為獨立解決方案來運行。MapReduce和Spark的主要區(qū)別在于，MapReduce使用持久存儲，而Spark使用彈性分布式數(shù)據(jù)集(RDDS)。

Spark之所以如此快速，原因在于它在內(nèi)存中處理一切數(shù)據(jù)。沒錯，它還可以使用磁盤來處理未全部裝入到內(nèi)存中的數(shù)據(jù)。