hadoop1.x與hadoop2.x在HDFS和MapReduce上的區別
HDFS改進
·hadoop1.x的HDFS體系架構
在Hadoop1.x中的NameNode只可能有一個，雖然可以通過SecondaryNameNode與NameNode進行資料同步備份，但是總會存在一定的延時，如果NameNode掛掉，但是如果有部份資料還沒有同步到SecondaryNameNode上，還是可能會存在著資料丟失的問題。
下面順便介紹一下SecondaryNameNode在Hadoop1.x的作用：(1).HA(高可靠性)的一個解決方案,但不支援熱備,配置即可。
(2).執行過程：從NameNode上下載元資料資訊（fsimage,edits），然後把二者合併，生成新的fsimage，在本地儲存，並將其推送到NameNode，替換舊的fsimage.
切換——下載——
如圖：
Hadoop1.x體系HDFS架構如圖：
該架構包含兩層：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.1HDFS Federation（HDFS聯邦）
（1）全新的Feration架構
在Hadoop2.x中，HDFS的變化主要體現在增強了NameNode的水平擴充套件（Horizontal Scalability）及高可用性（HA）->【這不就是針對我們剛剛提到到的Hadoop1.x HDFS架構的侷限性而做的改進，麼麼嗒！】，可以同時部署多個NameNode，這些NameNode之間是相互獨立，也就是說他們不需要相互協調，DataNode同時在所有NameNode中註冊，作為他們共有的儲存節點，並定時向所有的這些NameNode傳送心跳塊使用情況的報告，並處理所有NameNode向其傳送的指令。該架構如圖2所示：
該架構引入了兩個新的概念：儲存塊池（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.2 NameNode的HA
Hadoop中的NameNode好比是人的心臟，非常重要，絕對不可以停止工作。在Hadoop1.x時代，只有一個NameNode。如果該NameNode資料丟失或者不能工作，那麼整個叢集就不能恢復了。這是Hadoop1.x中的單點問題，也是Hadoop1.x不可靠的表現，如圖1所示。Hadoop2的出現解決了這個問題，也被稱為HA。
Hadoop2中HDFS的HA主要指的是可以同時啟動2個NameNode。其中一個處於工作（Active）狀態，另一個處於隨時待命（Standby）狀態。這樣，當一個NameNode所在的伺服器宕機時，可以在資料不丟失的情況下，手工或者自動切換到另一個NameNode提供服務。在hadoop的執行過程中，有時候會發生一些意想不到的事情，例如磁碟陣列的損壞，機器的宕機錯誤，以及及群管理員想對叢集進行升級配置，此時我們會聯想到hadoop HA(高可用性)。具體說，例如就是在一個叢集上同時執行兩個namenode，一個是active狀態，另一個是standby狀態。當節點執行失敗或者需要停止的時候，就是啟動那個備份的namenode，standbynamenode的功能和active完全相同，要達到這種水平，需要做下面的兩件事情。第一：我們必須要同步日誌檔案，也就是說activenamenode的執行中的映象檔案以及日誌需要在兩個namenode之間進行同步，這裡就引入了Journal這個概念。當active節點執行的時候，需要把自己的日誌檔案時時的寫入journal中去，於此同時standbynamenode就從其中讀取日誌檔案。任何一個時刻，只有有一個寫，一個讀。這樣還不夠，我們還需要讓datanode也要與standBynamenode進行時刻的通訊。有了上面的這兩點，我們就可以在一個叢集上同時執行兩個namenode來保證叢集的高可用性。(FailoverController:故障管理控制器)。
如圖3所示，它展示了一個在Hadoop2下實現HA的一種方式結構：
下面對上圖做一下簡單的介紹：
（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狀態。
在Hadoop2.0.0之前，NameNode(NN)在HDFS叢集中存在單點故障（singlepoint of failure），每一個叢集中存在一個NameNode，如果NN所在的機器出現了故障，那麼將導致整個叢集無法利用，直到NN重啟或者在另一臺主機上 啟動NN守護執行緒。主要在兩方面影響了HDFS的可用性：
（1）、在不可預測的情況下，如果NN所在的機器崩潰了，整個叢集將無法利用，直到NN被重新啟動；
（2）、在可預知的情況下，比如NN所在的機器硬體或者軟體需要升級，將導致叢集宕機。
HDFS的高可用性將通過在同一個叢集中執行兩個NN（active NN & standby NN）來解決上面兩個問題，這種方案允許在機器破潰或者機器維護快速地啟用一個新的NN來恢復故障。
在典型的HA叢集中，通常有兩臺不同的機器充當NN。在任何時間，只有一臺機器處於Active狀態；另一臺機器是處於Standby狀態。Active NN負責叢集中所有客戶端的操作；而StandbyNN主要用於備用，它主要維持足夠的狀態，如果必要，可以提供快速的故障恢復。
為了讓 Standby NN的狀態和Active NN保持同步，即元資料保持一致，它們都將會和JournalNodes守護程序通訊。當Active NN執行任何有關名稱空間的修改，它需要持久化到一半以上的JournalNodes上(通過editslog持久化儲存)，而StandbyNN負責觀察edits log的變化，它能夠讀取從JNs中讀取edits資訊，並更新其內部的名稱空間。一旦ActiveNN出現故障，Standby NN將會保證從JNs中讀出了全部的Edits，然後切換成Active狀態。Standby NN讀取全部的edits可確保發生故障轉移之前，是和ActiveNN擁有完全同步的名稱空間狀態。
為了提供快速的故障恢復，StandbyNN也需要儲存叢集中各個檔案塊的儲存位置。為了實現這個，叢集中所有的Database將配置好Active NN和StandbyNN的位置，並向它們傳送塊檔案所在的位置及心跳。
Hadoop2.2.0中HDFS的高可用性實現原理
在任何時候，叢集中只有一個NN處於Active 狀態是極其重要的。否則，在兩個Active NN的狀態下NameSpace狀態將會出現分歧，這將會導致資料的丟失及其它不正確的結果。為了保證這種情況不會發生，在任何時間，JNs只允許一個 NN充當writer。在故障恢復期間，將要變成Active 狀態的NN將取得writer的角色，並阻止另外一個NN繼續處於Active狀態。
為了部署HA叢集，你需要準備以下事項：
（1）、NameNodemachines：執行Active NN和Standby NN的機器需要相同的硬體配置；
（2）、JournalNode machines：也就是執行JN的機器。JN守護程序相對來說比較輕量，所以這些守護程序可以可其他守護執行緒（比如NN，YARN ResourceManager）執行在同一臺機器上。在一個叢集中，最少要執行3個JN守護程序，這將使得系統有一定的容錯能力。當然，你也可以執行3 個以上的JN，但是為了增加系統的容錯能力，你應該執行奇數個JN（3、5、7等），當執行N個JN，系統將最多容忍(N-1)/2個JN崩潰。在HA叢集中，Standby
NN也執行namespace狀態的checkpoints，所以不必要執行Secondary NN、CheckpointNode和BackupNode；事實上，執行這些守護程序是錯誤的。