Hadoop 2.x HDFS新特性

• HDFS聯邦
• HDFS HA(要用到Zookeeper)
• HDFS快照

解決了namenode單點得問題
高可用性
我有一個3000個主機，是不是得寫3000個hosts檔案，3000兩兩面密碼，所以在企業級應用得時候還是有問題得。
快照得功能：是恢復到某個時刻得檔案得內容。
操作命令與1.0x也是不同得。

回顧：HDFS兩層模型

Block Manager :具體資料塊得對映。

1. 當前HDFS架構和功能概述

我們先回顧一下HDFS功能。HDFS實際上具有兩個功能：名稱空間管理（Namespace management）和塊/儲存管理服務（block/storage management）。

1.1 名稱空間管理

HDFS的名稱空間包含目錄、檔案和塊。名稱空間管理：是指名稱空間支援對HDFS中的目錄、檔案和塊做類似檔案系統的建立、修改、刪除、列表檔案和目錄等基本操作。

1.2 塊/儲存管理

在塊儲存服務中包含兩部分工作：塊管理和物理儲存。這是一個更通用的儲存服務。其他的應用可以直接建立在Block Storage上，如HBase，Foreign Namespaces等。

1.2.1 塊管理

A) 處理Data Node向Name Node註冊的請求，處理datanode的成員關係，處理來自Data Node週期性的心跳。
B) 處理來自塊的報告資訊，維護塊的位置資訊。
C) 處理與塊相關的操作：塊的建立、刪除、修改及獲取塊資訊。
D) 管理副本放置（replica placement）和塊的複製及多餘塊的刪除。

1.2.2 物理儲存

所謂物理儲存就是：Data Node把塊儲存到本地檔案系統中，對本地檔案系統的讀、寫。

1.3 當前HDFS的架構

在當前的HDFS架構中（Hadoop v0.23之前），在整個HDFS叢集中只有一個名稱空間，並且只有單獨的一個Name Node，這個Name Node負責對這單獨的一個名稱空間進行管理。這也正是單點失效（Single Point Failure）的隱患所在。本文所講的HDFS Federation就是針對當前HDFS架構上的缺陷所做的改進，簡單說HDFS Federation就是使得HDFS支援多個名稱空間，並且允許在HDFS中同時存在多個Name Node。
簡單回顧一下目前HDFS的架構，如下圖所示。在整個HDFS叢集中只有一個Namenode，還有一個Backup Namenode。Namenode會實時將變化的HDFS的資訊同步給Backup Namenode。Backup Namenode顧名思義是用來做Namenode的備份的。Namenode中名稱空間以層次結構組織中儲存著檔名和BlockID的對應關係、BlockID和具體Block位置的對應關係。這個單獨的Namenode管理著數個Datanode，Block分佈在各個Datanode中，每個Datanode會週期性的向此Namenode傳送心跳訊息，報告自己所在Datanode的使用狀態。Block是用來儲存資料的最小單元，通常一個檔案會儲存在一個或者多個Block中，預設Block大小為64MB。

2. 單個Namenode的HDFS架構的侷限性

2.1 Namespace（名稱空間）的限制

由於Namenode在記憶體中儲存所有的元資料（metadata），因此單個Namenode所能儲存的物件（檔案+塊）數目受到Namenode所在JVM的heap size的限制。50G的heap能夠儲存20億（200 million）個物件，這20億個物件支援4000個datanode，12PB的儲存（假設檔案平均大小為40MB）。
隨著資料的飛速增長，儲存的需求也隨之增長。單個datanode從4T增長到36T，叢集的尺寸增長到8000個datanode。儲存的需求從12PB增長到大於100PB。

2.2 效能的瓶頸

由於是單個Namenode的HDFS架構，因此整個HDFS檔案系統的吞吐量受限於單個Namenode的吞吐量。毫無疑問，這將成為下一代MapReduce的瓶頸。

2.3 隔離問題

由於HDFS僅有一個Namenode，無法隔離各個程式，因此HDFS上的一個實驗程式就很有可能影響整個HDFS上執行的程式。那麼在HDFS Federation中，可以用不同的Namespace來隔離不同的使用者應用程式，使得不同Namespace Volume中的程式相互不影響。

2.4 叢集的可用性

在只有一個Namenode的HDFS中，此Namenode的宕機無疑會導致整個叢集不可用。

2.5 Namespace和Block Management的緊密耦合

當前在Namenode中的Namespace和Block Management組合的緊密耦合關係會導致如果想要實現另外一套Namenode方案比較困難，而且也限制了其他想要直接使用塊儲存的應用。

2.6 為什麼縱向擴充套件目前的Namenode不可行？比如將Namenode的Heap空間擴大到512GB。

這樣縱向擴充套件帶來的第一個問題就是啟動問題，啟動花費的時間太長。當前具有50GB Heap Namenode的HDFS啟動一次大概需要30分鐘到2小時，那512GB的需要多久？
第二個潛在的問題就是Namenode在Full GC時，如果發生錯誤將會導致整個叢集宕機。
第三個問題是對大JVM Heap進行除錯比較困難。優化Namenode的記憶體使用價效比比較低。

為什麼要引入Federation

多namenodes和namespaces體系

聯邦和HA是完全不一樣得

• 聯邦是為了解決單節點
• HA是備份
  

從這個圖上：可以得出每個datanode都可能被上面得namespace所使用，每個namespace都有可能來自於下面很多個datanode得資料。整個叢集都是可用得。

引入Federation的最主要原因是簡單，其簡單性是與真正的分散式Namenode相比而言的。Federation能夠快速的解決了大部分單Namenode HDFS的問題。

Federation是簡單魯棒的設計，由於聯盟中各個Namenode之間是相互獨立的。Federation整個核心設計實現大概用了3.5個月。大部分改變是在Datanode、Config和Tools，而Namenode本身的改動非常少，這樣Namenode原先的魯棒性不會受到影響。比分散式的Namenode簡單，雖然這種實現的擴充套件性比起真正的分散式的Namenode要小些，但是可以迅速滿足需求。另外一個原因是Federation良好的向後相容性，已有的單Namenode的部署配置不需要任何改變就可以繼續工作。

因此Federation（聯盟）是未來可選的方案之一。在Federation架構中可以無縫的支援目前單Namenode架構中的配置。

1. HDFS Federation

HDFS Federation使用了多個獨立的Namenode/namespace來使得HDFS的命名服務能夠水平擴充套件。在HDFS Federation中的Namenode之間是聯盟關係，他們之間相互獨立且不需要相互協調。HDFS Federation中的Namenode提供了提供了名稱空間和塊管理功能。HDFS Federation中的datanode被所有的Namenode用作公共儲存塊的地方。每一個datanode都會向所在叢集中所有的Namenode註冊，並且會週期性的傳送心跳和塊資訊報告，同時處理來自Namenode的指令。

4.1 Federation HDFS與當前HDFS的比較

當前HDFS只有一個名稱空間（Namespace），它使用全部的塊。而Federation HDFS中有多個獨立的名稱空間（Namespace），並且每一個名稱空間使用一個塊池（block pool）。
當前HDFS中只有一組塊。而Federation HDFS中有多組獨立的塊。塊池（block pool）就是屬於同一個名稱空間的一組塊。
當前HDFS由一個Namenode和一組datanode組成。而Federation HDFS由多個Namenode和一組datanode，每一個datanode會為多個塊池（block pool）儲存塊。

4.2 Block Pool(塊池)

HDFS Federation得官方文件解釋
所謂Block pool(塊池)就是屬於單個名稱空間的一組block(塊)。
每一個datanode為所有的block pool儲存塊。
Datanode是一個物理概念，而block pool是一個重新將block劃分的邏輯概念。同一個datanode中可以存著屬於多個block pool的多個塊。Block pool允許一個名稱空間在不通知其他名稱空間的情況下為一個新的block建立Block ID。同時，一個Namenode失效不會影響其下的datanode為其他Namenode的服務。
當datanode與Namenode建立聯絡並開始會話後自動建立Block pool。每個block都有一個唯一的標識，這個標識我們稱之為擴充套件的塊ID（Extended Block ID）= BlockID+BlockID。這個擴充套件的塊ID在HDFS叢集之間都是唯一的，這為以後叢集歸併創造了條件。
Datanode中的資料結構都通過塊池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通過BPID索引。
在HDFS中，所有的更新、回滾都是以Namenode和BlockPool為單元發生的。即同一HDFS Federation中不同的Namenode/BlockPool之間沒有什麼關係。
Hadoop V0.23版本中Block Pool的管理功能依然放在了Namenode中，將來的版本中會將Block Pool的管理功能移動的新的功能節點中。

好處

4.3 Datanode的改進

在datanode中，對應於每個Namnode都有一條相應的執行緒。每個datanode會去每一個Namenode註冊，並且週期性的給所有的Namenode傳送心跳及datanode的使用報告。Datanode還會給Namenode傳送其所在的block pool的block report（塊報告）。由於有多個Namenode同時存在，因此任何一個Namenode都可以隨時動態加入、刪除和更新。

4.4 Federation中的其他方面的改進

提供了工具，對於Namenode的初始化和退役的監控和管理。
允許在datanode級別或者block pool級別的負載均衡。
Datanode的後臺守護程序，為Federation所做的磁碟和目錄掃描。
提供了顯示Namenode的Block pool的使用狀態的Web UI。
還提供了對全部叢集儲存使用狀態的UI展示。
在Web UI中列出了所有的Namenode及其細節，如Namenode-BlockPoolID和儲存的使用狀態，失去聯絡的、活的和死的塊資訊。還有前往各個Namenode Web UI的連結。
Datanode退役狀態的展示。

4.5 多名稱空間的管理問題

在一個叢集中需要唯一的名稱空間還是多個名稱空間，核心問題名稱空間中資料的共享和訪問的問題。使用全域性唯一的名稱空間是解決資料共享和訪問的一種方法。在多名稱空間下，我們還可以使用Client Side Mount Table方式做到資料共享和訪問。

如上圖所示，每個深色三角形代表一個獨立的名稱空間，上方淺色的三角形代表從客戶角度去訪問下方的子名稱空間。各個深色的名稱空間Mount到淺色的表中，客戶可以訪問不同的掛載點來訪問不同的名稱空間，這就如同在Linux系統中訪問不同掛載點一樣。這就是HDFS Federation中名稱空間管理的基本原理：將各個名稱空間掛載到全域性mount－table中，就可以做將資料到全域性共享；同樣的名稱空間掛載到個人的mount-table中，這就成為應用程式可見的名稱空間檢視。

看起來像是整體得，聯邦制。

4.6 Namespace Volume（名稱空間卷）

一個Namespace和它的Block Pool合在一起稱作Namespace Volume。Namespace Volume是一個獨立完整的管理單元。當一個Namenode/Namespace被刪除，與之相對應的Block Pool也也被刪除。在升級時每一個Namespace Volume也會整體作為一個單元。

4.7 ClusterID

在HDFS Federation中添加了Cluster ID用來區分叢集中的每個節點。當格式化一個Namenode時，這個ClusterID會自動生成或者手動提供。在格式化同一叢集中其他Namenode時會用到這個ClusterID。

4.8 HDFS Federation對老版本的HDFS是相容的

這種相容性可以使得已有的Namenode配置不需要任何改變繼續工作。
具體的如何配置和管理Federation HDFS，

未解決得問題

配置

一般情況下，大型得公司才會使用。

格式化名稱節點

通俗得解釋

可以貼切得解釋：聯邦

把每個namenode看出拼圖上得小塊，小塊之間不重疊，沒有複製備份得機制，有個小塊失效了，但是地圖基本輪廓還是有的，以目錄為單位對映到namenode上，不能使用hash對映，導致每個目錄下面都有壞掉得檔案，現在根據目錄來對映得效率感覺很低，但是損壞率低。

HDFS快照

一個單獨得節點壞掉了，但是可以重別的地方恢復過來，有個很麻煩得事情，誤操作導致得資料不可挽回，我可以把某個時刻某個資料保留下來，我誤操作以後，在恢復到某個時刻。

資料整合工具

把bar復原
S0 是備份得快照

HDFS得C得api

yum -y install gcc gcc-c++ autoconf make

執行java得程式

都可以到官網上去查得到