一：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”。