HDFS 的 Master/Slave 架構，使得其具有單點瓶頸，即隨著業務數據的大規模膨脹，Master 節點在元數據存儲與提供服務上都會存在瓶頸。為了克服 HDFS 單點瓶頸存在的擴展性、性能、隔離問題，社區提出了 Federation(https:// issues.apache. org/jira/browse/HDFS-1052 )方案來進行解決。
但是使用該方案之后，暴露給客戶的問題就是，同一個集群出現了多個命名空間(namespace)，客戶需要知道讀寫的數據在哪個命名空間下才可以進行操作。為了解決統一命名空間的問題，社區提出了基于客戶端(client-side)的解決方案 ViewFS(https:// issues.apache. org/jira/browse/HADOOP-7257 )，該方案會在客戶端做好配置，用戶目錄一對一的掛載到具體的命名空間目錄上，滴滴在解決 Federation 問題時使用的就是這個方案。
ViewFS 方案也存在一些問題：
對于已經發布出去客戶端升級比較困難;
對于新增目錄需要增加掛載配置，與產品對接，維護起來比較困難。
社區在 2.9 和 3.0 版本中發布了一個新的解決統一命名空間問題的方案 Router-Based Federation(https:// issues.apache. org/jira/browse/HDFS-10467 )，該方案是基于服務端進行實現的，在升級管理方面比較好維護，滴滴最近引入了該方案，并進行了一些改造。
Router-Based Federation 方案介紹
Router-Based Federation 對外提供了 Router 服務，包含在 Federation layer 中，如下圖所示。這個 Router 服務將允許用戶透明地訪問任何子集群，讓子集群獨立管理自己的 Blockpool。為了實現這些目標，Federation layer 必須將 Block 訪問引導至適當的子群集。同時，它具有可擴展性，高可用性和容錯性。
?
?
Federation layer 包含多個組件。Router 是一個與 Namenode 具有相同接口的組件，根據 State Store 的元數據信息將客戶端請求轉發給正確的子集群。State Store 組件包含了遠程掛載表(具有 ViewFS 特性，但在客戶端之間共享)和有關 SubCluster 的負載 / 空間信息。
下圖架構中顯示每個子集群增加了 Router(標記為“R”)和邏輯集中式(但物理分布式)的狀態存儲(State Store)，以及每個 SubCluster 的 Namenodes(“NN”)和 Datanodes(“DN”)。這種方法與 YARN Federation(YARN-2915)具有相同的架構。
?
?
1、Router 組件
系統中可以有多個的 Router，每個 Router 有兩個角色：
1)向客戶端提供一個全局 Namenode 接口并負責轉發請求正確的子群集中的 Active Namenode;
2)在 State Store 中維護關于 Namenode 的信息。
Router 在收到客戶端請求，根據 mount-table 中的信息查找正確的子集群，然后轉發對該集群請求到對應子集群 Active Namenode。在收到 Active Namenode 的響應結果之后，將結果返回給客戶端 。 為了提升性能，Router 可以緩存遠程掛載表條目和子集群的狀態。
對于 Namenode 信息的維護，Router 定期檢查一個 Namenode 的狀態和向 State Store 報告其高可用性(HA)狀態和負載 / 空間狀態。 為了提高 Namenode HA 的性能，Router 使用 State Store 中的高可用性狀態信息, 以將請求轉發到最有可能處于活動狀態的 Namenode。
1.1 可用性與容錯性
Router 是無狀態的，所有 Router 同時提供服務。如果某個 Router 變成不可用，不影響其他任何 Router 提供服務。
客戶端配置他們的 DFS HA 客戶端(例如 ConfiguredFailoverProvider 或 RequestHedgingProxyProvider)與 Federation 中的所有 Router 配合使用。
為了實現高可用性和靈活性，多個 Router 可以監控相同的 Namenode 并把心跳發送信息到 State Store。 如果 Router 出現故障，這會增加信息的恢復能力。
1.2 Safe Mode
如果 Router 不能連接到 State Store，它可能會錯誤地提供過期 locations 的訪問，讓 Federation 進入不一致的狀態。
為防止這種情況發生，當 Router 無法連接到 State Store 一段時間后，它會進入安全模式(類似于 Namenode 的 safe mode)。當客戶端嘗試訪問 safe mode 的 Router 時候，會拋出異常，客戶端的 Proxy 捕獲后，會嘗試連接其他的 Router。類似于 Namenode，Router 保持在這個安全模式，直到它確定 State Store 可用為止。
這可以防止 Router 啟動時出現不一致。 假定一個 Router 如果在一段時間內沒有心跳(例如，心跳間隔的五倍)，則它已經死亡或處于安全模式。
1.3 交互接口
為了與用戶和管理員進行交互，Router 公開了多個接口。包括 RPC、Admin、WebUI 。
RPC 實現了客戶端與 HDFS 交互的最常見接口。 目前僅支持使用普通 MapReduce，Spark 和 Hive ( on Tez，Spark 和 MapReduce)。一些高級特性，如快照、加密和分層存儲在未來版本實現。 所有未實現的功能都會拋出異常。
Admin 為管理員實現的一個 RPC 接口，包括從子集群獲取信息、添加 / 刪除條目到 mout table。也可以通過命令行獲取和修改 Federation 信息。WebUI 實現了一個可視化 Federation 狀態，模仿了當前的 Namenode UI，除此之外，還包含 mout table，每個子集群的成員信息以及 Router 的狀態。
2、State Store 組件
State Store 維護的信息包括：
1)子集群的塊訪問負載，可用磁盤空間，HA 狀態等狀態;
2)文件夾 / 文件和子集群之間的映射，即遠程 Mount Table;
3)Router 的狀態。State Store 的后端存儲是可配置的。 既可以可以存儲在文件中，也可以存在 ZooKeeper 中。
2.1 Membership
Membership 反映了 Federation 中的 Namenode 的狀態。包括有關子集群的信息，例如存儲量和節點數量。Router 定期檢測一個或多個 Namenode 的信息。
2.2 Mount Table
管理文件夾和子集群之間的映射。 它與 ViewFS 中的 Mount Table 類似：
?
2.3 Router State
為了跟蹤 Router 中 caches 的狀態，Router 將其版本信息、狀態信息等存儲在 State Store 中。
3、未來計劃
目前 RBF 只是實現了一些基本 Namenode 接口，有些接口并不支持，HDFS-13655( https://issues.apache.org/jira/browse/HDFS-13655 )中會實現一些不支持的協議接口;當前 RBF 的穩定性也還存在一些問題，HDFS-13891( https://issues.apache.org/jira/browse/HDFS-13891 )會跟蹤一些穩定性問題進而解決掉。
Router-Based Federation 在滴滴的應用
1、部署情況
社區 Hadoop 在 2.9 和 3.0 中發布了 RBF 這個 Feature，滴滴目前的 Hadoop 版本是 2.7.2，我們的做法是將 branch-2 分支里關于 RBF 的提交都移植到了我們的代碼中，做了一些必要的修改工作。
在滴滴的大數據集群中，Federation 拆成了 5 組 Namenode。經過性能測試，我們得出這樣的結論：一個 Router 對應服務一組 Namenode 不存在壓力，因此我們選擇部署 5 個 Router 來服務整個集群。目前 Router-Based Federation 方案在滴滴已經穩定運行 2 月有余。
2、兼容性
直接引入 RBF 在運行 Hive 任務時會出現一些錯誤，例如 Wrong FS 等等。為此我們將 Hive 客戶端代碼做了修改，使其兼容 RBF。在 Hive 的元數據存儲中，location 信息存儲的是帶 HDFS Schema 的絕對路徑信息，在 Hive 代碼中處理 move 邏輯時，我們都會將路徑做一個 resolve 得到實際的 HDFS 路徑，然后再進行處理，這樣可以避免該問題的出現。
3、RBF 社區貢獻
在實際測試中，我們也發現了 RBF 的一些性能問題和 BUG，包括 Quota 問題、mount-table cache 使用不當問題、mount-table 創建 znode 出現 Null 問題等等。在解決這些問題之后，將 patch 貢獻給了社區，大部分被社區接收，具體修復和優化如下：
?
?
4、額外工作
除了貢獻給社區的一些工作，內部也有額外的一些對 RBF 的工作。RBF 的 WebUI 目前的顯示存在一些問題，節點數量、存儲總量的顯示為各個集群之和，內部對存儲、節點數量的計算做了一些修改;為了更好的對接產品，對外增加了一些 API，方便產品服務通過 API 遠程增加 mount table 條目信息，而不只是使用管理工具。
總結
Router-Based Federation 方案在滴滴內部已經上線，穩定運行了兩個多月的時間了，在運維和產品上提供了極大的便利。未來我們會繼續參與社區，為豐富 RBF 的功能以及提高其穩定性貢獻一份力量。
作者：費輝
