說道Hadoop，就要先講到大數(shù)據(jù)。
上個世紀，好遠。。。九十年代后，開始，數(shù)據(jù)開始大量的產(chǎn)生，總之到了快沒法弄的程度了。
比如說之前90年代，一個1G的硬盤，傳輸速度4.4M每秒，讀取全盤大概需要5分鐘。
現(xiàn)在呢，一個1T的硬盤，傳輸速度100M每秒，橫掃全盤2個半小時，讀取全部數(shù)據(jù)的話。。。。。不知道多長時間。
簡單幾句帶過，也就是說，數(shù)據(jù)太多了，我們該如何解決快速讀取的問題。
那么就提出了分布式。
也就是說，我們用一頭牛去拉不動火車，就沒必要培養(yǎng)一頭又大又壯能拉動火車的牛，只需要多弄些牛就可以了，小孩子都懂。
這樣呢，問題就出現(xiàn)了，如何分配合控制這么多牛，就是我們的著手要解決的問題了。那么這個道理就是分布式，一個簡單的減少讀取數(shù)據(jù)時間的方法，就是同時從多塊硬盤上讀取。
如果我們有100塊硬盤，每個存儲所有數(shù)據(jù)的1％，然后并行讀取，那么幾分鐘就能操作完成。但是只使用硬盤容量的1％的話，就太浪費資源了。這樣，我們可以將數(shù)據(jù)分為100個數(shù)據(jù)集，每個數(shù)據(jù)集1T，并實現(xiàn)共享磁盤的訪問。
可以想像，這樣便可以大量縮短數(shù)據(jù)分析的時間。有點像再說P2P下載哈。但是象我剛才說到的，處理多個硬盤數(shù)據(jù)的并行操作，還有很多問題。
一般來說呢，
第一，是如何解決硬盤故障問題，硬盤越多，故障概率越高。
現(xiàn)在解決的方式就是建立副本。比如RAID方式，冗余磁盤陣列?；蛘咴贖adoop中所采用的HDFS，也是一種方式，只是方法不同。
第二個問題，數(shù)據(jù)分開存儲到100塊硬盤上，那么，我們使用的時候而必須要合并使用。
在Hadoop中采用MapReduce來提供這個問題的解決方法。
MapReduce和HDFS是Hadoop中的兩個重要部分，MapReduce提供了一個編程模型，將磁盤讀寫問題進行抽象。我們可以理解HDFS像是數(shù)據(jù)庫，而MapReduce那么像是SQL語句和引擎一樣運作。
MapReduce將數(shù)據(jù)抽象成并演變成為對一個數(shù)據(jù)集（key/value對組成的集合）的計算。這個計算是由map和reduce兩部分所完成的，也就是將數(shù)據(jù)抽象成為map和reduce兩個對外的接口。
那么，簡而言之，Hadoop能做到提供一個穩(wěn)定可靠的共享存儲和分析系統(tǒng)。
其中，
HDFS實現(xiàn)存儲
MapReduce實現(xiàn)分析處理
當然Hadoop還有其他功能，但是這兩部分是我們所需要知道的，最重要的。
Hadoop和其他系統(tǒng)的比較
關(guān)于MapReduce的每個查詢基本上都需要處理整個map（整個數(shù)據(jù)集）或者至少要用到數(shù)據(jù)集的一大部分數(shù)據(jù)。
MapReduce是一個批量查詢處理器，它能夠在合理的時間范圍內(nèi)處理針對整個數(shù)據(jù)集的即時查詢（Ad hoc）。
注：Ad hoc 查詢（即席查詢）是信息學的一個術(shù)語。是拉丁語常用短語，意思是“特設(shè)的、特定目的的（地）、即席的、臨時的”
優(yōu)點：解放了以前存儲在磁盤上的數(shù)據(jù)。能在短時間內(nèi)處理以前很長時間才能獲得的結(jié)果。
事例：使用Hadoop處理用戶日志。即席查詢找出用戶的地理分布。通過整合大量數(shù)據(jù)，并使用MapReduce分析，
可以了解到我們以前不曾留意的數(shù)據(jù)，運用這些數(shù)據(jù)可以改善我們現(xiàn)有的服務(wù)。
那么，我們需要解釋一下，為什么上面的事情一樣可以用關(guān)系型數(shù)據(jù)庫來做到批量分析，而要用MapReduce。簡單的從存儲數(shù)據(jù)開始說起，硬盤是我們存儲數(shù)據(jù)的主要介質(zhì)，這里面就出現(xiàn)個問題：
首先，硬盤讀取數(shù)據(jù)之前需要尋址，尋找到分散在硬盤上的各個地址上的數(shù)據(jù)，那么這里產(chǎn)生兩個時間問題，
第一是硬盤的尋址時間，第二是硬盤數(shù)據(jù)的傳輸時間。
尋址操作需要磁頭在硬盤上不斷移動而在指定的位置進行讀寫。隨著硬盤技術(shù)的發(fā)展，尋址時間的提高遠遠落后于數(shù)據(jù)傳輸速率的進步。這導致磁盤大量的尋址操作成為數(shù)據(jù)存儲的瓶頸，而數(shù)據(jù)傳輸速率取決于硬盤總線的帶寬。
對大量數(shù)據(jù)進行訪問中，包含由大量的磁盤尋址工作，那么讀取大量數(shù)據(jù)集就會花更長的時間。
和關(guān)系型數(shù)據(jù)庫比較
那么HDFS和傳統(tǒng)的RDBMS各有什么優(yōu)缺點呢？
HDFS采用的是流式數(shù)據(jù)讀取模式，而流式數(shù)據(jù)讀取模式主要取決于數(shù)據(jù)的傳輸速率。RDBMS呢？采用的傳統(tǒng)的B樹，RDBMS中使用的B樹結(jié)構(gòu)，受限制于尋址的比例。
一般來說，對于大數(shù)據(jù)量的讀取流式模式的效率要遠遠高于B樹。但是當，只更新一小部分數(shù)據(jù)的話，那么傳統(tǒng)的B樹更有優(yōu)勢。
因為在大數(shù)據(jù)量更新時，B樹需要使用sort/merge（排序/合并）來重建數(shù)據(jù)庫。也就是說，可以將MapReduce看作RDBMS的一個補充。
MapReduce適合以批處理的方式處理需要分析的整個數(shù)據(jù)集。它適合一次性寫入，多次的讀取的應(yīng)用。
RDBMS適用于point query（點查詢）和更新，數(shù)據(jù)集被建立索引后，數(shù)據(jù)庫能夠提供快速的數(shù)據(jù)檢索和少量的數(shù)據(jù)更新。它更適合持續(xù)更新的數(shù)據(jù)集。
| RDBMS | MapReduce | |
| 數(shù)據(jù)大小 | GB | TB |
| 訪問 | 交互式和批處理 | 批處理 |
| 更新 | 多次讀寫 | 一次寫入多次讀取 |
| 結(jié)構(gòu) | 靜態(tài)模式 | 動態(tài)模式 |
| 完整性 | 高 | 低 |
| 橫向擴展 | 非線性 | 線性 |
MapReduce和RDBMS之間的另外一個區(qū)別在于他們所操作的數(shù)據(jù)集的結(jié)構(gòu)化程度。
結(jié)構(gòu)化數(shù)據(jù)（structured data）是具有既定格式的實體化數(shù)據(jù)，比如XML等滿足特定格式要求的數(shù)據(jù)表，比如數(shù)據(jù)庫表中的定義好的特定類型的字段。
半結(jié)構(gòu)化數(shù)據(jù)（semi-structured data）屬于比較松散，雖然可能有格式，單常常被視而不見，所以它只能用作數(shù)據(jù)結(jié)構(gòu)的一般說明。比如，單元格組成的網(wǎng)格中，每個單元都可以保存任何形式的數(shù)據(jù)。
非結(jié)構(gòu)化數(shù)據(jù)（unstructured data）沒有特定的結(jié)構(gòu)。比如，文本文件，圖片，視頻。
MapReduce對于非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)的讀取是非常有效的，這時因為MapReduce只有在讀取數(shù)據(jù)時才對數(shù)據(jù)進行解釋。也就是說，MapReduce輸入的key和value并不是固定的屬性，而是又分析數(shù)據(jù)的用戶來指定的，就像object map。
而，RDBMS的數(shù)據(jù)往往是規(guī)范的（normalized），以能夠保持其數(shù)據(jù)的完整性且不含冗余。但是這種規(guī)范的數(shù)據(jù)卻給MapReduce的讀取帶來了麻煩，因為它使用異地操作進行記錄的讀取工作，并且，MapReduce的核心價值之一，就是可以進行高速流式讀寫操作。
例如：web server上的日志就是一個典型的非結(jié)構(gòu)化非規(guī)范化的數(shù)據(jù)記錄，大家都知道，
所以MapReduce非常適合分析各種咋樣的日志，比如用戶登陸日志。MapReduce是一種線性可伸縮的編程模式。
程序猿可以編寫兩個方法，分別為map和reduce，每個方法定義一個［key/value對集合］到另一個［key/value對集合］的映射。而這些方法并不需要關(guān)心數(shù)據(jù)集及其所用集群的大小，因此可以原封不動地應(yīng)用到［小規(guī)模的數(shù)據(jù)集］或是 ［大規(guī)模的數(shù)據(jù)集］。
注：就是說方法寫好后，數(shù)據(jù)大小無需考慮，方法都是一樣的。
另外一點，如果輸入的數(shù)據(jù)量是原來的兩倍，那么運行的時間也是原來的兩倍，但是，如果把集群的大小擴大到原來的兩倍，那么運行的時間就和原來一樣了。這個特性比RDBMS好哈，都懂哈！不過現(xiàn)在很多RDBMS開始向著這方面發(fā)展，而，MapReduce也開始具有了數(shù)據(jù)庫的一些特性。凌亂了～！
Hadoop與其他傳統(tǒng)工作方式的比較
這里大概可以粗略講到網(wǎng)格計算。
High Performance Computing（HPC高性能計算）和Grid Computing（網(wǎng)格計算）的組織，多年來一直在研究大數(shù)據(jù)處理方法。一般主要采用類似于消息傳遞接口MPI（Message Passing Interface）的API。
HPC的方法是將任務(wù)分散到集群中的各臺計算機上，這些計算機訪問由存儲區(qū)域網(wǎng)絡(luò)（Storage Area Network，SAN）組成的共享文件系統(tǒng)。
注：儲區(qū)域網(wǎng)絡(luò)（Storage Area Network，SAN）是一種連接外接存儲設(shè)備和服務(wù)器的架構(gòu)。包括磁盤陣列，磁帶柜等各種技術(shù)實現(xiàn)。該架構(gòu)的特點是，連接到服務(wù)器的存儲設(shè)備，將被操作系統(tǒng)視為直接連接的存儲設(shè)備進行使用。
MapReduce實現(xiàn)計算節(jié)點數(shù)據(jù)本地化。
這種組成比較適用于計算密集型任務(wù)，但是如果節(jié)點需要使用更大量的數(shù)據(jù)進行計算時，那么很多計算節(jié)點（也就是網(wǎng)格中計算單元）會由于網(wǎng)絡(luò)帶寬的瓶頸而變的空閑，且，一直等待數(shù)據(jù)的到來，這時候MapReduce就開始有用了。
MapReduce可以盡量把計算節(jié)點上存儲數(shù)據(jù)，以實現(xiàn)數(shù)據(jù)的本地快速訪問。而數(shù)據(jù)本地化（data locality）也正是MapReduce的一個核心特性。
當我們現(xiàn)在意識到網(wǎng)絡(luò)帶寬是我們系統(tǒng)架構(gòu)中最寶貴的資源的時候，MapReduce則通過顯式網(wǎng)絡(luò)拓撲結(jié)構(gòu)來盡量保留帶寬資源并且顯式網(wǎng)絡(luò)拓撲結(jié)構(gòu)并沒有降低MapReduce的計算密集型的數(shù)據(jù)分析能力。
MapReduce無需考慮底層數(shù)據(jù)控制。
消息傳遞接口MPI給了程序員很大的控制空間，需要程序員顯式的控制數(shù)據(jù)流機制，包括底層的功能模塊（soket通信接口）和上層的數(shù)據(jù)分析算法。
而MapReduce則在更高層次上去運行，也就是程序員只需要考慮如何操作數(shù)據(jù)集（key/value對）就可以了。
MapReduce無需考慮節(jié)點失效。
大規(guī)模分布式計算的問題在于，如何很好的協(xié)調(diào)各進程之間關(guān)系。如何在處理一個計算過程處理失效的問題中，在無法知道一個遠程的進程是否已經(jīng)失效的情況下，還要繼續(xù)去完成整個計算。
而，MapReduce給我們的是，無需考慮系統(tǒng)的部分失效的問題，因為MapReduce的系統(tǒng)實現(xiàn)能夠檢測到失敗的map或者reduce任務(wù)，并讓某個其他節(jié)點正常的機器來重新執(zhí)行這些失敗的任務(wù)。
MapReduce采用無共享（shared-nothing）框架來實現(xiàn)失敗檢測，這樣需要在各任務(wù)之間彼此獨立運行。這樣，程序員就無需考慮各任務(wù)的執(zhí)行順序，至少是無關(guān)緊要的事情。
相比之下MPI雖然控制權(quán)比較大，但是也同樣加大了編程難度。（If there is great power comes great responsibility）
那么，MapReduce是個相當嚴格的模型，用戶被限定于使用操作特定的數(shù)據(jù)集（key/value對）。相對應(yīng)的mapper和reducer彼此之間可以做的協(xié)調(diào)是極其有限度的，僅僅是傳遞key/value對。
MapReduce適合于普通的分析和計算么？
其實，MapReduce是用于構(gòu)建搜索引擎的索引，并且能夠非常好的完成。許多算法可以使用MapReduce來表達，從圖形圖像分析到各類機遇圖像的分析，再到機器學習，都可以。MapReduce是由Google的工程師開發(fā)的，靈感來自于傳統(tǒng)的函數(shù)式編程，分布式計算和數(shù)據(jù)庫社區(qū)。
它的優(yōu)秀，能夠完成我們的大部分需求。
和志愿計算的比較
志愿計算呢，就是很多志愿者將自己的計算機空閑出來的CPU時間志愿貢獻出來，用來協(xié)助計算一些大型的計算事務(wù)。
比較有名的項目：
加利福尼亞大學的SETI@home，
全稱：Search for Extra-Terrestrial Intelligence（搜索外星智慧）項目。
志愿者把自己計算機的CPU空閑時間貢獻出來分析無線天文射電望遠鏡的返回數(shù)據(jù)，借此尋找外星智慧生命信號。
可以通過 http://setiathome.berkeley.edu/ 注冊參加，或者式了解這個項目。
其他還有很多類似的項目，可以下載BOINCManager來參加這些項目為人類作出些貢獻。
下載地址 http://boinc.berkeley.edu/download.php
這里用到志愿計算，志愿計算項目就是將需要解決的問題分成多個塊，每個塊被稱為一個工作單元或者（work unit）或者任務(wù)（task）。并將他們發(fā)到世界各地的電腦上進行分析。
完成分析后，將數(shù)據(jù)發(fā)回到服務(wù)器合并，客戶端回獲得另外一個工作單元。為了防止欺騙星文，每個工作單元被分配到三個不同的機器上進行執(zhí)行，并且至少收到兩個相同的結(jié)果才被接受。
這里看來志愿計算和MapReduce看上去很相似，都是將問題分為獨立的單元，然后進行并行計算。但，還是由很大的差異。
志愿計算問題是CPU高度密集的，比較適合世界上成千上萬的計算機上運行，因為計算時間遠遠大于傳輸數(shù)據(jù)的時間。而，志愿者貢獻的是CPU周期，而不是網(wǎng)絡(luò)帶寬。
MapReduce的設(shè)計目標在于服務(wù)于那些只需要數(shù)分鐘或者幾小時就可以完成的即時任務(wù)，并運行于內(nèi)部通過高速網(wǎng)絡(luò)相互連接的網(wǎng)絡(luò)內(nèi)，并且這個網(wǎng)絡(luò)內(nèi)的計算機需要由可靠的，定制的硬件構(gòu)成。此外，志愿計算需要在接入護兩旺的不可信的計算機上長時間運行，這些計算機具有不同的帶寬，且對數(shù)據(jù)本地化沒有太多要求。
聯(lián)系客服
