當某個數據集大大小超出單個物理機的存儲能力時，我們可以考慮使用集羣。管理跨網絡機器存儲的文件系統叫做分佈式文件系統(Distributed FileSystem)。隨着多節點的引入，相應的問題也就出現了，例如其中最重要的一個問題就是如何保證在某個節點失敗的情況下數據不會丟失。Hadoop中有一個核心子項目HDFS(Hadoop Distributed FileSystem)就是用來管理集羣的存儲問題的，當然在Hadoop中不僅僅只能使用HDFS，Hadoop中有一個通用的抽象的文件系統概念，這樣可以使Hadoop在不同種類的文件系統下運作，例如Hadoop可以與Amazon的S3文件系統集成起來一起使用。
HDFS的設計理念
1、存儲超大文件
這裏的“超大文件”是指幾百MB、GB甚至TB級別的文件。
2、流式數據訪問
HDFS是建立在最有效的數據處理模式是一次寫多次讀（write-once,read-many-times）的模式的概念之上的，HDFS存儲的數據集作爲hadoop的分析對象。在數據集生成後，長時間在此數據集上進行各種分析。每次分析都將設計該數據集的大部分數據甚至全部數據，因此讀取整個數據集的時間延遲比讀取第一條記錄的時間延遲更重要。（流式讀取最小化了硬盤的尋址開銷，只需要尋址一次，然後就一直讀啊讀。硬盤的物理構造導致尋址開銷的優化跟不上讀取開銷。所以流式讀取更加適合硬盤的本身特性。當然大文件的特點也更適合流式讀取。與流數據訪問對應的是隨機數據訪問，它要求定位、查詢或修改數據的延遲較小，比較適合於創建數據後再多次讀寫的情況，傳統關係型數據庫很符合這一點）
3、運行在普通廉價的服務器上HDFS設計理念之一就是讓它能運行在普通的硬件之上，即便硬件出現故障，也可以通過容錯策略來保證數據的高可用。
HDFS的不便之處
1、將HDFS用於對數據訪問要求低延遲的場景
由於HDFS是爲高數據吞吐量應用而設計的，必然以高延遲爲代價。
2、存儲大量小文件
HDFS中元數據（文件的基本信息）存儲在namenode的內存中，而namenode爲單點，小文件數量大到一定程度，namenode內存就吃不消了。
HDFS中的基本概念
1.Blocks
每個磁盤都有一個數據塊大小（block size），這是一次可以讀取或寫入數據的最小單位。HDFS中也有數據塊的概念，不過HDFS中的數據塊卻比一般磁盤的數據塊（一般爲512Byte）大得多。像普通磁盤文件系統那樣，HDFS把文件分割成block（下文如果沒有特別聲明，block都是指HDFS中的64MB大小的block）大小的數據塊，並獨立存儲起來。不過與普通磁盤文件系統不同的是，如果一個文件比單個block小，這個文件並不會整個block（如果一個幾百kb的小文件佔用了整個64MB大小的數據塊，那該造成多大的浪費啊）。
|
HDFS爲什麼要使用大數據塊 HDFS中的數據塊比普通磁盤文件系統要大得多，這麼做的原因是最小化文件系統中數據尋址的時間。通過設置一個較大的block大小，尋址數據的時間就會比傳輸數據的時間小得多，從而處理一個大文件（HDFS主要用來處理大數據的嘛）的時間就主要決定於數據傳輸的時間了。 |
在分佈式文件系統層面又抽象出一個block的概念可以帶來有以下好處：
1. 由於沒有一個文件必須存儲在單個磁盤上的要求了，從而單個文件可以比集羣中的任何一個節點的存儲空間還要大，這樣可以充分利用集羣的存儲能力。有可能（雖然不常見）一個文件會佔用整個集羣上所有節點的存儲空間。
2. 以block（而不是文件）作爲抽象單元簡化了存儲子系統。簡單是所有存儲系統的共同目標，在發生故障方式多種多樣的分佈式文件系統中尤爲重要。存儲子系統只需要處理block就可以了，從而簡化了存儲管理（因爲block是固定大小的，可以很容易的計算出某個磁盤最多可以存儲多少個block），而且還省去了元數據的管理負擔（因爲block只是需要存儲的一串數據，文件的諸如訪問權限之類的元數據不需要同block存儲在一起，從而可以通過另一個系統namenode單獨管理起來）。
3. 有了block，提供數據容錯和可用性的冗餘備份（replication）機制可以更好的工作。在HDFS中，爲了防止數據塊損壞，或者磁盤及機器當機，每一個block在不同機器上都有幾份備份（默認爲3）。如果一個block不能用了，HDFS會以一種對用戶透明的方式拷貝一份新的備份出來，從而把集羣的數據安全級別恢復到以前的水平（你也可以通過提高冗餘備份數來提高數據的安全級別）。
可以使用HDFS中的fsck命令在block層面交互，例如運行命令：
% hadoop fsck / -files -blocks
會列出文件系統中組成所有文件的blocks。
2. NameNode和DataNode
HDFS集羣中有兩種節點：NameNode和DataNode。NameNode管理整個文件系統的命名空間（namespace），它維護着整個文件系統樹以及樹中所有文件及目錄的元數據。這些信息在本地文件系統中以兩種形式永久保存：namespace image（包括namespace中所有文件的inode和block列表）和edit log（記錄了所有用戶對HDFS所做的更改操作）。NameNode也保存着構成給定文件的blocks的位置，但這些信息並不是永久保存在磁盤中的，因爲這些信息是在系統啓動時根據datanode的反饋信息重建、並且是定時基於datanode的報考更新的，具有很強的動態性。
客戶端（client）代表用戶（user）通過與NameNode和DataNode交互來訪問文件系統。client提供了一個類似POSIX（Portable Operating System Interface）的文件系統接口，所以用戶在編程中並不需要namenode和datanode的具體實現。
namenode是整個分佈式文件系統的一個單點故障（single point of failure），沒有了namenode整個分佈式文件系統就無法使用了，因爲我們無法從blocks中重構出相應的文件了。所以確保namenode能從失敗中及時恢復是很重要的一件事，我們可以從以下兩方面入手：
1. 第一種方法就是備份namenode中保存的永久信息（也就是上文中所提到的namespace image和edit log），namenode可以經過額外配置把它的永久信息保存到多個文件系統上去（這些多寫操作是同步和原子性的）。最常用的做法是把永久信息保存到本地文件系統和某個遠程NFS（Network FileSystem）上去。
2. 另一種可能的做法就是運行一個secondary namenode，儘管它的名字跟namenode聽起來差不多，但它的功能跟namenode卻不一樣。它最主要的工作就是把namespace image檢查點文件與edit log相融合（以防止edit log過大）並把融合後的namespace image保存在自己的本地文件系統上，同時發送這個新的備份給namenode。因爲需要大量CPU資源和跟namenode一樣大小內存的緣故， secondary namenode通常運行在另一個單獨的機器上（關於更多secondary
namenode運行的描述請參看這裏）。然後由於secondary
namenode上保存的狀態信息總是要滯後於namenode上的狀態信息的緣故（未融合的edit log記錄了這一部分改變），如果namenode完全失敗，數據肯定要丟失一部分。
通常的做法是把上述兩種方法結合起來，也即當namenode當機時，把遠端NFS上的namespace image拷貝到secondary namenode上，然後把secondary namenode當做namenode來運行。
3. Hadoop Fedoration
namenode在內存中保存着文件系統中每個文件和目錄的引用，但集羣規模擴大時，這便造成了一個瓶頸。於是在hadoop 2.x發行版中引入了一個新的概念：Hadoop Fedoration。它允許集羣擁有不止一個namenode，這樣每個namenode只負責維護文件系統中的一部分，例如一個namenode維護/user目錄，另一個namenode可以維護/share目錄。
在fedoration中，每個namenode維護兩部分信息：1）由namespace 元數據組成的namespace volume；2）包含其負責維護的某一部分文件系統中的的所有文件的block位置信息的block pool。namespace volume各自之間是獨立的，這就意味着namenode之間不用交互，而且某個namenode當機並不影響其他namenode的正常使用。相對於namespace volume而言，Block
pool並不是分區的，所以datanodes需要向集羣中的每個namenode註冊，並且可能要存儲來自多個block pool的數據。
要想使用帶有fedoration特性的cluster，用戶可以使用用戶端的掛載表來映射文件路徑到namenode。這個可以通過ViewFileSystem來配置，並使用viewfs:// URI.
（關於更多Hadoop Fedoration的內容請參看這裏）
4. HDFS High-Availabilty
雖然通過在多個文件系統備份namespace metadata和使用secondary namenode來定期合併namespace image和edit log以產生新的checkpoint可以保護集羣以免數據丟失。但這並沒有提供集羣的高可用性，因爲namenode本身仍然是一個單點故障——如果namenode當掉了，所有的客戶端，包括mapreduce作業都無法正常讀、寫以及查看文件了，因爲namenode是維護namespace metadata和提供file-to-block映射的唯一庫。
要想從失敗的namenode中恢復，管理員應啓動一個新的namenode，同時配置datanode和用戶使用這個新的namenode。這個新的namenode暫時還不能正常運作，直到它做完了以下幾件事：
1） 把namespace image備份加載入內存；
2） 重放edit log中的操作；
3） 從datanode中接受足夠的block report（也就是記錄各個datanode中block的信息以確定file-to-block映射），然後離開safe mode。
在有很多節點和文件的大的集羣中，這個操作可能要花費幾十分鐘的時間！！
Hadoop 2.x發行版通過加入對HDFS High-Availabilty的支持而有效避免了長時間的downtime。在這種實現中，有一對namenode，它們分別配置爲active和standby。當active
namenode當掉時，standby namenode立即接手繼續爲client提供服務，期間的中斷時間很小。爲了實現HDFS High-Availabilty，結構上發生了以下變化：
1） 兩個namenode使用一個高可用的共享設備（最初HA實現使用的是NFS來共享edit log，不過在未來的版本中會提供更多的選項，如構建於ZooKeeper之上的基於BookKeeper的系統）來存儲edit log，當standby namenode接手運行時，它就會立即重放edit log中的操作（同時它也充當着secondary namenode的角色，不停地合併老的namespace image和新的edit
log以免edit log過大），從而很快達到與active namenode當掉前的狀態。
2） datanode需要向兩個namenode發送block report，因爲block mapping是存放在內存，而不是磁盤中的。
3） 用戶端（client）必須被合適配置並採用一種對用戶透明的方式處理namenode的失敗恢復。綜合起來，如下圖所示：
|
edit log中都保存着哪些信息？ All mutations to the file system namespace, such as file renames, permission changes, file creations, block allocations, etc, are written to a persistent write-ahead log by the Name Node before returning success to a client call. In addition to this edit log, periodic checkpoints of the file system, called the fsimage, are also created and stored on-disk on the Name Node. Block locations, on the other hand, are stored only in memory. The locations of all blocks are received via “block reports” sent from the Data Nodes when the Name Node is started. |
有了以上改變做基礎，當active namenode當掉時，因爲standy namenode保存着最新的edit log（同時還有上個檢查點鏡像文件）和最新的block mapping，standy namenode可以在幾十秒內很快地接手繼續工作。在實際應用中測得的失敗恢復時間會長一些（大約一分鐘左右），因爲系統需要額外的時間確定active namenode確實已經當機了。
轉載請註明出處：http://www.cnblogs.com/beanmoon/archive/2012/12/08/2809315.html