Preface
HDFS Federation 是 Hadoop 最新發布版本 Hadoop-0.23.0 中為解決 HDFS 單點故障而提出的 namenode 水平擴展方案。該方案允許 HDFS 創建多個namespace以提高集群的擴展性和隔離性。本篇文章主要介紹了HDFS Federation 的設計動機和基本原理。
1. 當前 HDFS 概況
1.1 當前 HDFS 架構
當前 HDFS 包含兩層結構：
* Namespace 管理目錄，文件和數據塊。它支持常見的文件系統操作，如創建文件，修改文件，刪除文件等。
* Block Storage 有兩部分組成：
當前 HDFS 架構只允許整個集群中存在一個 namespace，而該 namespace 被僅有的一個 namenode 管理。這個架構使得 HDFS 非常容易實現，但是，它（見上圖）在具體實現過程中會出現一些模糊點，進而導致了很多局限性（下面將要詳細說明），當然這些局限性只有在擁有大集群的公司，像 baidu，騰訊 等出現。
1.2 當前 HDFS 局限性
Block Storage 和 namespace 高耦合
當前 namenode 中的 namespace 和 block management 的結合使得這兩層架構耦合在一起，難以讓其他可能 namenode 實現方案直接使用block storage。
namenode 擴展性
HDFS 的底層存儲是可以水平擴展的（解釋：底層存儲指的是 datanode，當集群存儲空間不夠時，可簡單的添加機器已進行水平擴展），但 namespace 不可以。當前的 namespace 只能存放在單個 namenode 上，而 namenode 在內存中存儲了整個分佈式文件系統中的元數據信息，這限制了集群中數據塊，文件和目錄的數目。
性能
文件操作的性能製約於單個 namenode 的吞吐量，單個 namenode 當前僅支持約 60K 的 task，而下一代 Apache MapReduce 將支持多餘 100K 的並發任務，這隱含著要支持多個 namenode。
隔離性
現在大部分公司的集群都是共享的，每天有來自不同 group 的不同用戶提交作業。單個 namenode 難以提供隔離性，即：某個用戶提交的負載很大的 job 會減慢其他用戶的job，單一的 namenode 難以像 HBase 按照應用類別將不同作業分派到不同 namenode 上。
2. HDFS Federation
2.1 為什麼採用 Federation
採用 Federation 的最主要原因是簡單，Federation 能夠快速的解決了大部分單 Namenode 的問題。Federation 整個核心設計實現大概用了4個月。大部分改變是在 Datanode、Config 和 Tools，而 Namenode 本身的改動非常少，這樣 Namenode 原先的魯棒性不會受到影響。這使得該方案與之前的 HDFS 版本兼容。
2.2 Federation 架構
為了水平擴展 namenode，federation 使用了多個獨立的 namenode/namespace。這些 namenode 之間是聯合的，也就是說，他們之間相互獨立且不需要互相協調，各自分工，管理自己的區域。分佈式的 datanode 被用作通用的數據塊存儲存儲設備。每個 datanode 要向集群中所有的 namenode 註冊，且週期性地向所有 namenode 發送心跳和塊報告，並執行來自所有 namenode 的命令。
一個 block pool 由屬於同一個namespace的數據塊組成，每個 datanode 可能會存儲集群中所有 block pool 的數據塊。每個 block pool 內部自治，也就是說各自管理各自的 block，不會與其他 block pool 交流。一個 namenode 掛掉了，不會影響其他 namenode。某個 namenode 上的 namespace 和它對應的 block pool 一起被稱為 namespace volume。它是管理的基本單位。當一個 namenode/nodespace 被刪除後，其所有 datanode 上對應的 block pool 也會被刪除。當集群升級時，每個 namespace volume 作為一個基本單元進行升級。
2.3 Federation 關鍵技術點
命名空間管理
Federation 中存在多個命名空間，如何劃分和管理這些命名空間非常關鍵。在 Federation 中並採用 “文件名hash”的方法，因為該方法的 locality 非常差，比如：查看某個目錄下面的文件，如果採用文件名 hash 的方法存放文件，則這些文件可能被放到不同 namespace 中， HDFS 需要訪問所有 namespace，代價過大。為了方便管理多個命名空間，HDFS Federation 採用了經典的 Client Side Mount Table。
如上圖所示，下面四個深色三角形代表一個獨立的命名空間，上方淺色的三角形代表從客戶角度去訪問的子命名空間。各個深色的命名空間 Mount 到淺色的表中，客戶可以訪問不同的掛載點來訪問不同的命名空間，這就如同在 Linux 系統中訪問不同掛載點一樣。這就是 HDFS Federation 中命名空間管理的基本原理：將各個命名空間掛載到全局 mount-table 中，就可以做將數據到全局共享；同樣的命名空間掛載到個人的 mount-table 中，這就成為應用程序可見的命名空間視圖。
2.4 主要優點
擴展性和隔離性
支持多個 namenode 水平擴展整個文件系統的 namespace。可按照應用程序的用戶和種類分離 namespace volume，進而增強了隔離性。
通用存儲服務
Block Pool抽象層為HDFS的架構開啟了創新之門。分離 block storage layer 使得：
設計簡單
Federation 整個核心設計實現大概用了4個月。大部分改變是在 Datanode、Config 和 Tools 中，而 Namenode 本身的改動非常少，這樣 Namenode 原先的魯棒性不會受到影響。雖然這種實現的擴展性比起真正的分佈式的 Namenode 要小些，但是可以迅速滿足需求，另外 Federation 具有良好的向後兼容性，已有的單 Namenode 的部署配置不需要任何改變就可以繼續工作.
3. HDFS Federation 不足
單點故障問題
HDFS Federation 並沒有完全解決單點故障問題。雖然 namenode/namespace 存在多個，但是從單個 namenode/namespace 看，仍然存在單點故障：如果某個 namenode 掛掉了，其管理的相應的文件便不可以訪問。Federation 中每個 namenode 仍然像之前HDFS上實現一樣，配有一個 secondary namenode，以便主 namenode 掛掉一下，用於還原元數據信息。
負載均衡問題
HDFS Federation 採用了 Client Side Mount Table 分攤文件和負載，該方法更多的需要人工介入已達到理想的負載均衡。
Supplement
* HDFS Federation ppt in Apache Hadoop India Summit 2011
* IBM Knowledge center - Configuring HDFS federation
