hadoop1.0 和 Hadoop 2.0 的區別

zzzzMing發表於2018-12-25
Hadoop

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節點。
Hadoop1.0總體結構
這個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主要架構
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)。
Hadoop Yarn

而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
一個故事告訴你什麼才是好的程式設計師

相關文章