hadoop1.0 和 Hadoop 2.0 的區別

1.Hadoop概述

在Google三篇大數據論文發表以後，Cloudera公司在這幾篇論文的基礎上，開發出瞭如今的Hadoop。但Hadoop開發出來也並不是一路順風的，Hadoop1.0版本有諸多侷限。在後續的不斷實踐之中，Hadoop2.0橫空出世，然後Hadoop2.0逐漸成爲大數據中的主流。那麼Hadoop1.0究竟存在哪些缺陷，在它升級到Hadoop2.0的時候又作出了怎樣的調整，最終使得Hadoop2.0成爲大數據的基石呢？

2.Hadoop1.0

首先咱們來看hadoop1.0的總體結構。在hadoop1.0中有兩個模塊，一個是分佈式文件系統HDFS(Hadoop Distrbuted File System)。另外一個則是分佈式計算框架MapReduce。咱們分別來看看這兩個模塊的架構吧。

2.1HDFS1.0

對HDFS來講，其主要的運行架構則是master-slave架構，即主從架構。其中呢，master主節點稱之爲Namenode節點，而slave從節點稱爲DataNode節點。 這個NameNode的職責是什麼呢？

1. NameNode管理着整個文件系統，負責接收用戶的操做請求
2. NameNode管理着整個文件系統的目錄結構，所謂目錄結構相似於咱們Windows操做系統的體系結構
3. NameNode管理着整個文件系統的元數據信息，所謂元數據信息指定是除了數據自己以外涉及到文件自身的相關信息
4. NameNode保管着文件與block塊序列之間的對應關係以及block塊與DataNode節點之間的對應關係

在hadoop1.0中，namenode有且只有一個，雖然能夠經過SecondaryNameNode與NameNode進行數據同步備份，可是總會存在必定的延時，若是NameNode掛掉，可是若是有部份數據尚未同步到SecondaryNameNode上，仍是可能會存在着數據丟失的問題。

值得一提的是，在HDFS中,咱們真實的數據是由DataNode來負責來存儲的，可是數據具體被存儲到了哪一個DataNode節點等元數據信息則是由咱們的NameNode來存儲的。

這種架構實現的好處的簡單，但其侷限一樣明顯：

• 單點故障問題：由於NameNode含有咱們用戶存儲文件的所有的元數據信息，當咱們的NameNode沒法在內存中加載所有元數據信息的時候，集羣的壽命就到頭了。
• 拓展性問題：NameNode在內存中存儲了整個分佈式文件系統中的元數據信息，而且NameNode只能有一臺機器，沒法拓展。單臺機器的NameNode必然有到達極限的地方。
• 性能問題：當HDFS中存儲大量的小文件時，會使NameNode的內存壓力增長。
• 隔離性問題：單個namenode難以提供隔離性，即：某個用戶提交的負載很大的job會減慢其餘用戶的job。

2.2MapReduce

對MapReduce來講，一樣時一個主從結構，是由一個JobTracker（主）和多個TaskTracker（從）組成。

而JobTracker在hadoop1.0的MapReduce中作了不少事情，能夠說當爹又當媽。

1. 負責接收client提交給的計算任務。
2. 負責將接收的計算任務分配給各個的TaskTracker進行執行。
3. 經過heartbeat(心跳)來管理TaskTracker機器的狀況，同時監控任務task的執行情況。

這個架構的缺陷：

• 單點故障：依舊是單點故障問題，若是JobTracker掛掉了會致使MapReduce做業沒法執行。
• 資源浪費：JobTracker完成了太多的任務，形成了過多的資源消耗，當map-reduce job很是多的時候，會形成很大的內存開銷，潛在來講，也增長了JobTracker失效的風險，這也是業界廣泛總結出老Hadoop的Map-Reduce只能支持4000節點主機的上限；
• 只支持簡單的MapReduce編程模型：要使用Hadoop進行編程的話只能使用基礎的MapReduce，而沒法使用諸如Spark這些計算模型。而且它也不支持流式計算和實時計算。

3.Hadoop2.0

Hadoop2.0比起Hadoop1.0來講，最大的改進是加入了資源調度框架Yarn，咱們依舊分爲HDFS和Yarn/MapReduce2.0兩部分來說述Hadoop的改進。

3.1HDFS2.0

針對Hadoop1.0中NameNode制約HDFS的擴展性問題，提出HDFSFederation以及高可用HA。此時NameNode間相互獨立，也就是說它們之間不須要相互協調。且多個NameNode分管不一樣的目錄進而實現訪問隔離和橫向擴展。

這樣NameNode的可拓展性天然而然可用增長，據統計Hadoop2.0中最多能夠達到10000個節點同時運行，而且這樣的架構改進也解決了NameNode單點故障問題。

再來講說高可用(HA),HA主要指的是能夠同時啓動2個NameNode。其中一個處於工做(Active)狀態，另外一個處於隨時待命（Standby）狀態。這樣，當一個NameNode所在的服務器宕機時，能夠在數據不丟失的狀況下，手工或者自動切換到另外一個NameNode提供服務。

3.2Yarn/MapReduce2

針對Hadoop1.0中MR的不足，引入了Yarn框架。Yarn框架中將JobTracker資源分配和做業控制分開，分爲Resource Manager(RM)以及Application Master(AM)。

而Yarn框架做爲一個通用的資源調度和管理模塊，同時支持多種其餘的編程模型，好比最出名的Spark。

Yarn的主要三個組件以下：

• Resource Manager：ResourceManager包含兩個主要的組件：定時調用器(Scheduler)以及應用管理器(ApplicationManager)。

  1. 定時調度器(Scheduler)：定時調度器負責嚮應用程序分配資源，它不作監控以及應用程序的狀態跟蹤，而且它不保證會重啓因爲應用程序自己或硬件出錯而執行失敗的應用程序。

  2. 應用管理器(ApplicationManager)：應用程序管理器負責接收新任務，協調並提供在ApplicationMaster容器失敗時的重啓功能。

• Application Master：每一個應用程序的ApplicationMaster負責從Scheduler申請資源，以及跟蹤這些資源的使用狀況以及任務進度的監控。

• Node Manager：NodeManager是ResourceManager在每臺機器的上代理，負責容器的管理，並監控他們的資源使用狀況（cpu，內存，磁盤及網絡等），以及向ResourceManager/Scheduler提供這些資源使用報告。

關於Hadoop1.0和2.0的一點點感悟

沒有什麼是一開始就完美的，當下最流行的Hadoop也同樣。從上面說的，咱們能夠知道Hadoop1.0是比較簡陋的，這樣作的目的就是爲了易於實現。Hadoop這樣作也契合了敏捷開發的原則，也能夠說契合產品經理口中的最小可行性產品（MVP），就是先實現一個簡單些，但核心功能齊全的版本出來，讓市場對其進行檢驗，而有告終果以後再進行拓展升級。

在當時那種許多公司都苦惱於沒有本身的大數據環境的狀況下，Hadoop一炮而紅。這時候再根據市場，也就是開源社區給出的反饋，不斷迭代，更新升級。最終成爲大數羣山中最爲堅固的一座山峯。

咱們在平時的產品開發中應該也要像Hadoop學習，先作出最小可行性產品出來，再在後面進行更新升級，不斷完善。固然這對一些完美主義者來講，可能會讓他感到比較痛苦。

你看，世間的事可能是相通，技術的發展過程其實也暗合產品之道。有時候咱們或許能夠跳出技術以外，思考它背後產品的邏輯，這其中又有哪些是咱們能夠學習的，這些一樣是珍貴的寶藏，所謂他山之石，能夠攻玉，莫過於此~~

以上~

---

推薦閱讀： 從分治算法到 MapReduce Actor併發編程模型淺析 大數據存儲的進化史 --從 RAID 到 Hadoop Hdfs 一個故事告訴你什麼纔是好的程序員