一：Haddop版本介紹

0.20.x版本最後演化成了現在的1.0.x版本

0.23.x版本最後演化成了現在的2.x版本

hadoop 1.0 指的是1.x(0.20.x),0.21,0.22

hadoop 2.0 指的是2.x,0.23.x

CDH3,CDH4分別對應了hadoop1.0 hadoop2.0

二、Hadoop1.X與Hadoop2.X區別

1、HDFS的改進

1.1 Hadoop1.x時代的HDFS架構

　　在Hadoop1.x中的NameNode只可能有一個，雖然可以通過SecondaryNameNode與NameNode進行資料同步備份，但是總會存在一定的延時，如果NameNode掛掉，但是如果有部份資料還沒有同步到SecondaryNameNode上，還是可能會存在著資料丟失的問題

該架構包含兩層：Namespace 和 Block Storage Service；

　　其中，Namespace 層面包含目錄、檔案以及塊的資訊，支援對Namespace相關檔案系統的操作，如增加、刪除、修改以及檔案和目錄的展示；

　　而Block Storage Service層面又包含兩個部分：

　　①Block Management（塊管理）維護叢集中DataNode的基本關係，它支援資料塊相關的操作，如：建立資料塊，刪除資料塊等，同時，它也會管理副本的複製和存放。

　　②Physical Storage（物理儲存）儲存實際的資料塊並提供針對資料塊的讀寫服務。

　　當前HDFS架構只允許整個叢集中存在一個Namespace，而該Namespace被僅有的一個NameNode管理。這個架構使得HDFS非常容易實現，但是，它（見上圖）在具體實現過程中會出現一些模糊點，進而導致了很多侷限性（下面將要詳細說明），當然這些侷限性只有在擁有大叢集的公司，像baidu，騰訊等出現。

  Hadoop1.x的HDFS架構的侷限：

（1）Block Storage和namespace高耦合

當前namenode中的namespace和block management的結合使得這兩層架構耦合在一起，難以讓其他可能namenode實現方案直接使用block storage。

（2）NameNode擴充套件性

HDFS的底層儲存是可以水平擴充套件的（解釋：底層儲存指的是datanode，當叢集儲存空間不夠時，可簡單的新增機器已進行水平擴充套件），但namespace不可以。當前的namespace只能存放在單個namenode上，而namenode在記憶體中儲存了整個分散式檔案系統中的元資料資訊，這限制了叢集中資料塊，檔案和目錄的數目。

（3）NameNode效能

檔案操作的效能制約於單個Namenode的吞吐量，單個Namenode當前僅支援約60K的task，而下一代Apache MapReduce將支援多餘100K的併發任務，這隱含著要支援多個Namenode。

（4）隔離性

現在大部分公司的叢集都是共享的，每天有來自不同group的不同使用者提交作業。單個namenode難以提供隔離性，即：某個使用者提交的負載很大的job會減慢其他使用者的job，單一的namenode難以像HBase按照應用類別將不同作業分派到不同namenode上。

1.2 HDFS Federation

　　（1）全新的Feration架構

　　在Hadoop2.x中，HDFS的變化主要體現在增強了NameNode的水平擴充套件（Horizontal Scalability）及高可用性（HA）->【這不就是針對我們剛剛提到到的Hadoop1.x HDFS架構的侷限性而做的改進，麼麼嗒！】，可以同時部署多個NameNode，這些NameNode之間是相互獨立，也就是說他們不需要相互協調，DataNode同時在所有NameNode中註冊，作為他們共有的儲存節點，並定時向所有的這些NameNode傳送心跳塊使用情況的報告，並處理所有NameNode向其傳送的指令。

該架構引入了兩個新的概念：儲存塊池（Block Pool） 和 叢集ID（ClusterID）；

　　①一個Bock Pool 是塊的集合，這些塊屬於一個單一的Namespace。DataNode儲存著叢集中所有Block Pool中的塊。Block Pool的管理相互之間是獨立的。這意味著一個Namespace可以獨立的生成塊ID，不需要與其他Namespace協調。一個NameNode失敗不會導致Datanode的失敗，這些Datanode還可以服務其他的Namenode。

　　一個Namespace和它的Block Pool一起稱作名稱空間向量（Namespace Volume）。這是一個自包含單元。當一個NameNode/Namespace刪除後，對應的Block Pool也會被刪除。當叢集升級時，每個Namespace Volume也會升級。

　　②叢集ID（ClusterID）的加入，是用於確認叢集中所有的節點，也可以在格式化其它Namenode時指定叢集ID，並使其加入到某個叢集中。

　　（2）HDFS Federation與老HDFS架構的比較

①老HDFS架構只有一個名稱空間（Namespace），它使用全部的塊。而HDFS Federation 中有多個獨立的名稱空間（Namespace），並且每一個名稱空間使用一個塊池（block pool）。

②老HDFS架構中只有一組塊。而HDFS Federation 中有多組獨立的塊。塊池（block pool）就是屬於同一個名稱空間的一組塊。

③老HDFS架構由一個Namenode和一組datanode組成。而HDFS Federation 由多個Namenode和一組Datanode，每一個Datanode會為多個塊池（block pool）儲存塊。

1.3 NameNode的HA

　　Hadoop中的NameNode好比是人的心臟，非常重要，絕對不可以停止工作。在Hadoop1.x時代，只有一個NameNode。如果該NameNode資料丟失或者不能工作，那麼整個叢集就不能恢復了。這是Hadoop1.x中的單點問題，也是Hadoop1.x不可靠的表現，如圖1所示。Hadoop2的出現解決了這個問題，也被稱為HA。

　　Hadoop2中HDFS的HA主要指的是可以同時啟動2個NameNode。其中一個處於工作（Active）狀態，另一個處於隨時待命（Standby）狀態。這樣，當一個NameNode所在的伺服器宕機時，可以在資料不丟失的情況下，手工或者自動切換到另一個NameNode提供服務。

（1）這些NameNode之間通過共享儲存同步edits資訊，保證資料的狀態一致。多個NameNode之間共享資料，可以通過Network File System（NFS）或者Quorum Journal Node。前者是通過Linux共享的檔案系統，屬於作業系統層面的配置；後者是Hadoop自身的東西，屬於軟體層面的配置。

　　（2）DataNode同時向兩個NameNode彙報塊資訊。這是讓Standby NameNode保持叢集最新狀態的必需步驟。

　　（3）使用Zookeeper來進行心跳監測監控，在Active NameNode失效時自動切換Standby NameNode為Active狀態。

2、MapReduce的改進

2.1 Hadoop1.x時代的MapReduce

　　在Hadoop1.x時代，Hadoop中的MapReduce實現是做了很多的事情，而該框架的核心Job Tracker則是既當爹又當媽的意思。

（1）首先使用者程式 （JobClient） 提交了一個 job，job 的資訊會發送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與叢集中的機器定時通訊 (heartbeat), 需要管理哪些程式應該跑在哪些機器上，需要管理所有 job 失敗、重啟等操作。

　　（2）TaskTracker 是 Map-reduce 叢集中每臺機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況。

　　（3）TaskTracker 同時監視當前機器的 tasks 執行狀況。TaskTracker 需要把這些資訊通過 heartbeat傳送給JobTracker，JobTracker 會蒐集這些資訊以給新提交的 job 分配執行在哪些機器上。

Hadoop1.x的MapReduce框架的主要侷限：

（1）JobTracker 是 Map-reduce 的集中處理點，存在單點故障；

（2）JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的記憶體開銷，潛在來說，也增加了 JobTracker 失效的風險，這也是業界普遍總結出老 Hadoop 的 Map-Reduce 只能支援 4000 節點主機的上限；

2.2 Hadoop2中新方案：YARN+MapReduce

　　首先的不要被YARN給迷惑住了，它只是負責資源排程管理。而MapReduce才是負責運算的傢伙，所以YARN  != MapReduce2. 

YARN 並不是下一代MapReduce（MRv2），下一代MapReduce與第一代MapReduce（MRv1）在程式設計介面、資料處理引擎（MapTask和ReduceTask）是完全一樣的， 可認為MRv2重用了MRv1的這些模組，不同的是資源管理和作業管理系統，MRv1中資源管理和作業管理均是由JobTracker實現的，集兩個功能於一身，而在MRv2中，將這兩部分分開了。 其中，作業管理由ApplicationMaster實現，而資源管理由新增系統YARN完成，由於YARN具有通用性，因此YARN也可以作為其他計算框架的資源管理系統，不僅限於MapReduce，也是其他計算框架（例如Spark）的管理平臺。

Hadoop1時代中MapReduce可以說是啥事都幹，而Hadoop2中的MapReduce的話則是專門處理資料分析，而YARN則做為資源管理器而存在。

該架構將JobTracker中的資源管理及任務生命週期管理（包括定時觸發及監控），拆分成兩個獨立的服務，用於管理全部資源的ResourceManager以及管理每個應用的ApplicationMaster，ResourceManager用於管理嚮應用程式分配計算資源，每個ApplicationMaster用於管理應用程式、排程以及協調。一個應用程式可以是經典的MapReduce架構中的一個單獨的Job任務，也可以是這些任務的一個DAG（有向無環圖）任務。ResourceManager及每臺機上的NodeManager服務，用於管理那臺主機的使用者程序，形成計算架構。每個應用程式的ApplicationMaster實際上是一個框架具體庫，並負責從ResourceManager中協調資源及與NodeManager(s)協作執行並監控任務。

（1）ResourceManager包含兩個主要的元件：定時呼叫器(Scheduler)以及應用管理器(ApplicationManager)。

　　①定時排程器(Scheduler)：

　　定時排程器負責嚮應用程式分配資源，它不做監控以及應用程式的狀態跟蹤，並且它不保證會重啟由於應用程式本身或硬體出錯而執行失敗的應用程式。

　　②應用管理器(ApplicationManager)：

　　應用程式管理器負責接收新任務，協調並提供在ApplicationMaster容器失敗時的重啟功能。

　　（2）ApplicationMaster：每個應用程式的ApplicationMaster負責從Scheduler申請資源，以及跟蹤這些資源的使用情況以及任務進度的監控。

　　（3）NodeManager：NodeManager是ResourceManager在每臺機器的上代理，負責容器的管理，並監控他們的資源使用情況（cpu，記憶體，磁碟及網路等），以及向 ResourceManager/Scheduler提供這些資源使用報告。

    23、具體變化

2.3.1、配置檔案的路徑

在1.x中，Hadoop的配置檔案是放在$HADOOP_HOME/conf目錄下的，關鍵的配置檔案在src目錄都有對應的存放著預設值的檔案，如下：

配置檔案	預設值配置檔案
$HADOOP_HOME/conf/core-site.xml	$HADOOP_HOME/src/core/core-default.xml
$HADOOP_HOME/conf/hdfs-site.xml	$HADOOP_HOME/src/hdfs/hdfs-default.xml
$HADOOP_HOME/conf/mapred-site.xml	$HADOOP_HOME/src/mapred/mapred-default.xml

我們在$HADOOP_HOME/conf下面配置的core-site.xml等的值，就是對預設值的一個覆蓋，如果沒有在conf下面的配置檔案中設定，那麼就使用src下面對應檔案中的預設值，這個在使用過程中非常方便，也非常有助於我們理解。

Hadoop可以說是雲端計算的代名詞，其也有很多衍生的產品，不少衍生的配置方式都遵從Hadoop的這種配置方式，如HBase的配置檔案也是$HBase/conf目錄，核心配置的名稱就是hbase-site.xml，如果學習了Hadoop再去學習HBase，從配置的理解上來說，就會有一種親切的感覺。

可是在2.x中，Hadoop的架構發生了變化，而配置檔案的路徑也發生了變化，放到了$HADOOP_HOME/etc/hadoop目錄，這樣修改的目的，應該是讓其更接近於Linux的目錄結構吧，讓Linux使用者理解起來更容易。Hadoop 2.x中配置檔案的幾個主要的變化：

l 去除了原來1.x中包括的$HADOOP_HOME/src目錄，該目錄包括關鍵配置檔案的預設值；

l 預設不存在mapred-site.xml檔案，需要將當前mapred-site.xml.template檔案copy一份並重命名為mapred-site.xml，並且只是一個具有configuration節點的空檔案；

l 預設不存在mapred-queues.xml檔案，需要將當前mapred-queues.xml.template檔案copy一份並重命名為mapred-queues.xml；

l 刪除了master檔案，現在master的配置在hdfs-site.xml通過屬性dfs.namenode.secondary.http-address來設定，如下：

<property>         <name>dfs.namenode.secondary.http-address</name>         <value>nginx1:9001</value> </property>

l 增加了yarn-env.sh，用於設定ResourceManager需要的環境變數，主要需要修改JAVA_HOME；

l 增加yarn-site.xml配置檔案，用於設定ResourceManager；

2.3.2、命令檔案目錄的變化

在1.x中，所有的命令檔案，都是放在bin目錄下，沒有區分客戶端和服務端命令，並且最終命令的執行都會呼叫hadoop去執行；而在2.x中將服務端使用的命令單獨放到了sbin目錄，其中有幾個主要的變化：

l 將./bin/hadoop的功能分離。在2.x中./bin/hadoop命令只保留了這些功能：客戶端對檔案系統的操作、執行Jar檔案、遠端拷貝、建立一個Hadoop壓縮、為每個守護程序設定優先順序及執行類檔案，另外增加了一個檢查本地hadoop及壓縮庫是否可用的功能，詳情可以通過命令“hadoop -help”檢視。

而在1.x中，./bin/hadoop命令還包括：NameNode的管理、DataNode的管理、 TaskTracker及JobTracker的管理、服務端對檔案系統的管理、檔案系統的檢查、獲取佇列 資訊等，詳情可以通過命令“hadoop -help”檢視。

l 增加./bin/hdfs命令。./bin/hadoop命令的功能被剝離了，並不是代表這些命令不需要了，而是將這些命令提到另外一個名為hdfs的命令中，通過hdfs命令可以對NameNode格式化及啟動操作、啟動datanode、啟動叢集平衡工具、從配置庫中獲取配置資訊、獲取使用者所在組、執行DFS的管理客戶端等，詳細可以通過“hdfs -help”檢視。

l 增加./bin/yarn命令。原來1.x中對JobTracker及TaskTracker的管理，放到了新增的yarn命令中，該命令可以啟動及管理ResourceManager、在每臺slave上面都啟一個NodeManager、執行一個JAR或CLASS檔案、列印需要的classpath、列印應用程式報告或者殺死應用程式等、列印節點報告等，詳情可以通過命令“yarn -help”檢視。

l 增加./bin/mapred命令。該命令可以用於執行一個基於管道的任務、計算MapReduce任務、獲取佇列的資訊、獨立啟動任務歷史服務、遠端目錄的遞迴拷貝、建立hadooop壓縮包，詳情可以通過“./mapred -help”。

參考資料