Hadoop相對於RDBMS、HPC、志願計算的比較

Hadoop 提供了一個穩定的共用儲存和分析系統。儲存由HDFS 實現，分析由MapReduce 實現。縱然Hadoop 還有其他功能，但這些功能是它的核心所在。

相較於其他系統

MapReduce 似乎採用的是一種蠻力方法。即，針對每個查詢，每一個資料集-- 至少是很大一部分-- 都會被處理。但這正是它的能力。MapReduce 可以處理一批查詢，並且它針對整個資料集處理即席查詢並在合理時間內獲得結果的能力也是具有突破性的。它改變了我們對資料的看法，並且解放了以前儲存在磁帶和磁碟上的資料。它賦予我們對資料進行創新的機會。那些以前需要很長時間才能獲得答案的問題現在已經迎刃而解。

1. 關係型資料庫管理系統

為什麼我們不能使用資料庫加上更多磁碟來做大規模的批量分析？為什麼我們需要MapReduce？

這個問題的答案來自於磁碟機的另一個發展趨勢：定址時間的提高速度遠遠慢於傳輸速率的提高速度。定址就是將磁頭移動到特定位置進行讀寫操作的工序。它的特點是磁碟操作有延遲，而傳輸速率對應於磁碟的頻寬。如果資料的訪問模式受限於磁碟的定址，勢必會導致它花更長時間(相較於流)來讀或寫大部分資料。另一方面，在更新一小部分資料庫記錄的時候，傳統的B 樹(關係型資料庫中使用的一種資料結構，受限於執行尋找的速度)效果很好。但在更新大部分資料庫資料的時候，B 樹的效率就沒有MapReduce 的效率高，因為它需要使用排序/合并來重建資料庫。

在許多情況下，MapReduce 能夠被視為一種RDBMS(關係型資料庫管理系統)的補充。(兩個系統之間的差異見表1-1)。MapReduce 很適合處理那些需要分析整個資料集的問題，以批處理的方式，尤其是Ad Hoc(自主或即席)分析。RDBMS 適用於點查詢和更新(其中，資料集已經被索引以提供低延遲的檢索和短時間的少量資料更新）。MapReduce 適合資料被一次寫入和多次讀取的應用，而關係型資料庫更適合持續更新的資料集。

 

 

MapReduce 和關係型資料庫之間的另一個區別是它們操作的資料集中的結構化資料的數量。結構化資料是擁有準確定義的實體化資料，具有諸如XML 文檔或資料庫表定義的格式，符合特定的預定義模式。這就是RDBMS 包括的內容。另一方面，半結構化資料比較寬鬆，雖然可能有模式，但經常被忽略，所以它只能用作資料結構指南。例如，一張試算表，其中的結構便是儲存格組成的網格，儘管其本身可能儲存任何形式的資料。非結構化資料沒有什麼特別的內部結構，例如純文字或映像資料。MapReduce 對於非結構化或半結構化資料非常有效，因為它被設計為在處理時間內解釋資料。換句話說：MapReduce 輸入的鍵和值並不是資料固有的屬性，它們是由分析資料的人來選擇的。

關係型資料往往是規範的，以保持其完整性和刪除冗餘。正常化為MapReduce 帶來問題，因為它使讀取記錄成為一個非本地操作（即需要從其他主機上拷貝自己需要的資料），並且MapReduce 的核心假設之一就是，它可以進行(高速)流的讀寫。Web 服務器日誌是記錄集的一個很好的非正常化例子(例如，用戶端主機名稱每次都以全名來指定，即使同一用戶端可能會出現很多次)，這也是MapReduce 非常適合用於分析各種記錄檔的原因之一。

MapReduce 是一種線性可伸縮的編程模型。程式員編寫兩個函數-- map 函數和Reduce 函數-- 每一個都定義一個鍵/值對集映射到另一個。這些函數無視資料的大小或者它們正在使用的叢集的特性，這樣它們就可以原封不動地應用到小規模資料集或者大的資料集上。更重要的是，如果放入兩倍的資料量，啟動並執行時間會少於兩倍。但是如果是兩倍大小的叢集，一個任務任然只是和原來的一樣快。這不是一般的SQL 查詢的效果。

隨著時間的推移，關係型資料庫和MapReduce 之間的差異很可能變得模糊。關係型資料庫都開始吸收MapReduce 的一些思路(如ASTER DATA 的和GreenPlum 的資料庫)，另一方面，基於MapReduce 的進階查詢語言(如Pig 和Hive)使MapReduce 的系統更接近傳統的資料庫編程人員。

2. 格線運算

高效能運算(High Performance Computing，HPC)和格線運算社區多年來一直在做大規模的資料處理，它們使用的是訊息傳遞介面(Message Passing Interface，MPI)這樣的API。從廣義上講，高效能運算的方法是將作業分配給一個機器叢集，這些機器訪問共用檔案系統，由一個存放區域網路(Storage Area Network，SAN)進行管理。這非常適用於以主計算密集型為主的作業，但當節點需要訪問的大資料量(數百GB 的資料，這是MapReduce 實際開始"發光"的起點)時，這會成為一個問題，因為網路頻寬成為"瓶頸"，所以計算節點閑置下來了。

MapReduce 嘗試在計算節點本機存放區資料，因此資料訪問速度會因為它是本機資料而比較快。 這項"資料本地化"功能，成為MapReduce 的核心功能並且也是它擁有良好效能的原因之一。意識到網路頻寬在資料中心環境是最有價值的資源(到處複製資料會很容易的把網路頻寬飽和)之後，MapReduce 便通過顯式網路拓撲結構不遺餘力地加以保護。請注意，這種安排不會排除MapReduce 中的高CPU 流量分析。

MPI 賦予程式員很大的控制，但也要求顯式控制資料流機制，需要使用傳統的C 語言的功能模組完成(例如socket)，以及更進階的演算法來進行分析。而MapReduce 卻是在更高層面上完成任務，即程式員從鍵/值對函數的角度來考慮，同時資料流是隱含的。

在一個大規模分散式運算平台上協調進程是一個很大的挑戰。最困難的部分是恰當的處理失效與錯誤-- 在不知道一個遠程進程是否已經失敗的時候-- 仍然需要繼續整個計算。MapReduce 將程式員從必須考慮失敗任務的情況中解放出來，它檢測失敗的map 或者reduce任務，在健康的機器上重新安排任務。MapReduce 能夠做到這一點，因為它是一個無共用的架構，這意味著各個任務之間彼此並不依賴。(這裡講得稍微簡單了一些，因為mapper 的輸出是反饋給reducer 的，但這由MapReduce 系統控制。在這種情況下，相對於返回失敗的map，應該對返回reducer 給予更多關注，因為它必須確保它可以檢索到必要的map 輸出，如果不行，必須重新運行相關的map 從而產生必要的這些輸出。)因此，從程式員的角度來看，執行任務的順序是無關緊要的。相比之下，MPI 程式必須顯式地管理自己的檢查點和恢複機制，從而把更多控制權交給程式員，但這樣會加大編程的難度。

MapReduce 聽起來似乎是一個相當嚴格的編程模型，而且在某種意義上看的確如此：我們被限定於鍵/值對的類型(它們按照指定的方式關聯在一起)，mapper 和reducer 彼此間的協作有限，一個接一個地運行(mapper 傳輸鍵/值對給reducer)。對此，一個很自然的問題是：你是否能用它做點兒有用或普通的事情？

答案是肯定的。MapReduce 作為一個建立搜尋索引產品系統，是由Google 的工程師們開發出來的，因為他們發現自己一遍又一遍地解決相同的問題(MapReduce 的靈感來自傳統的函數式編程、分散式運算和資料庫社區)，但它後來被應用於其他行業的其他許多應用。我們驚喜地看到許多演算法的變體在MapReduce 中得以表示，從映像圖形分析，到基於圖表的問題，再到機器學習演算法 。它當然不能解決所有問題，但它是一個很普遍的資料處理工具。

3. 志願計算

人們第一次聽說Hadoop 和MapReduce 的時候，經常會問："和SETI@home 有什麼區別？"SETI，全稱為Search for Extra-Terrestrial Intelligence(搜尋外星人)，運行著一個稱為SETI@home 的項目(http://setiathome.berkeley.edu)。在此項目中，志願者把自己電腦CPU的空閑時間貢獻出來分析無線天文望遠鏡的資料藉此尋外星智慧生命訊號。SETI@home 是最有名的擁有許多志願者的項目，其他的還有Great Internet Mersenne Prime Search(搜尋大素數)與Folding@home 項目(瞭解蛋白質構成及其與疾病之間的關係)。志願計算項目通過將他們試圖解決的問題分為幾個他們成為工作單元的塊來工作，並將它們送到世界各地的電腦上進行分析。例如，SETI@home 的工作單元大約是0.35 MB 的無線電望遠鏡資料，並且一個典型的電腦需要數小時或數天來分析。完成分析後，結果發送回伺服器，用戶端獲得的另一項工作單元。作為防止欺騙的預防措施，每個工作單元必須送到三台機器上並且需要有至少兩個結果相同才會被接受。雖然SETI@home 在表面上可能類似於MapReduce(將問題分為獨立的塊，然後進行並行計算)，但差異還是顯著的。SETI@home 問題是CPU 高度密集型的，使其適合運行於世界各地成千上萬台電腦上，因為相對於其計算時間而言，傳輸工作單元的時間微不足道 。志願者捐獻的是CPU 週期，而不是頻寬。

MapReduce 被設計為用來運行那些需要數分鐘或數小時的作業，這些作業在一個聚集頻寬很高的資料中心中可信任的專用硬體裝置上運行。相比之下，SETI@home 項目是在接入互連網的不可信的電腦上運行，這些電腦的網速不同，而且資料也不在本地。