# 一、背景
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 訪問引導至適當的子群集。同時，它具有可擴充套件性，高可用性和容錯性。

![](http://img.blog.itpub.net/blog/2019/01/07/9758de077169ebfa.png?x-oss-process=style/bb)

Federation layer 包含多個元件。Router 是一個與 Namenode 具有相同介面的元件，根據 State Store 的後設資料資訊將客戶端請求轉發給正確的子叢集。State Store 元件包含了遠端掛載表（具有 ViewFS 特性，但在客戶端之間共享）和有關 SubCluster 的負載/空間資訊。

下圖架構中顯示每個子叢集增加了 Router（標記為“R”）和邏輯集中式（但物理分散式）的狀態儲存（State Store），以及每個 SubCluster 的 Namenodes（“NN”）和 Datanodes（“DN”）。這種方法與 YARN Federation（YARN-2915）具有相同的架構。

![](http://img.blog.itpub.net/blog/2019/01/07/1d92d08a1319f891.png?x-oss-process=style/bb)

## 2.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。

### 2.1.1 可用性與容錯性
Router 是無狀態的，所有 Router 同時提供服務。如果某個 Router 變成不可用，不影響其他任何 Router 提供服務。

客戶端配置他們的 DFS HA 客戶端（例如 ConfiguredFailoverProvider 或 RequestHedgingProxyProvider）與 Federation 中的所有 Router 配合使用。

為了實現高可用性和靈活性，多個 Router 可以監控相同的 Namenode 並把心跳傳送資訊到 State Store。 如果 Router 出現故障，這會增加資訊的恢復能力。

### 2.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 如果在一段時間內沒有心跳（例如，心跳間隔的五倍），則它已經死亡或處於安全模式。

### 2.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.2 State Store 元件

State Store 維護的資訊包括：

1. 子叢集的塊訪問負載，可用磁碟空間，HA 狀態等狀態；
2. 資料夾/檔案和子叢集之間的對映，即遠端 Mount Table；
3. Router 的狀態。State Store 的後端儲存是可配置的。 既可以可以儲存在檔案中，也可以存在 ZooKeeper 中。

### 2.2.1 Membership

Membership 反映了 Federation 中的 Namenode 的狀態。包括有關子叢集的資訊，例如儲存量和節點數量。Router 定期檢測一個或多個 Namenode 的資訊。

### 2.2.2 Mount Table

管理資料夾和子叢集之間的對映。 它與 ViewFS 中的 Mount Table 類似：`hdfs://tmp → hdfs://C0-1/tmp /* Folder tmp is mapped to folder tmp in subcluster C0-1 */`

### 2.2.3 Router State

為了跟蹤 Router 中 caches 的狀態，Router 將其版本資訊、狀態資訊等儲存在 State Store 中。

## 2.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 在滴滴的應用
## 3.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 月有餘。

## 3.2 相容性

直接引入 RBF 在執行 Hive 任務時會出現一些錯誤，例如 Wrong FS 等等。為此我們將 Hive 客戶端程式碼做了修改，使其相容 RBF。在 Hive 的後設資料儲存中，location 資訊儲存的是帶HDFS Schema 的絕對路徑資訊，在 Hive 程式碼中處理 move 邏輯時，我們都會將路徑做一個 resolve 得到實際的 HDFS 路徑，然後再進行處理，這樣可以避免該問題的出現。

## 3.3 RBF 社群貢獻

在實際測試中，我們也發現了 RBF 的一些效能問題和 BUG，包括 Quota 問題、mount-table cache 使用不當問題、mount-table 建立 znode 出現  Null 問題等等。在解決這些問題之後，將 patch 貢獻給了社群，大部分被社群接收，具體修復和最佳化如下：

- HDFS-13710：https://issues.apache.org/jira/browse/HDFS-13710
- HDFS-13821：https://issues.apache.org/jira/browse/HDFS-13821
- HDFS-13836：https://issues.apache.org/jira/browse/HDFS-13836
- HDFS-13844：https://issues.apache.org/jira/browse/HDFS-13844
- HDFS-13845：https://issues.apache.org/jira/browse/HDFS-13845
- HDFS-13854：https://issues.apache.org/jira/browse/HDFS-13854
- HDFS-13856：https://issues.apache.org/jira/browse/HDFS-13856
- HDFS-13857：https://issues.apache.org/jira/browse/HDFS-13857
- HDFS-13802：https://issues.apache.org/jira/browse/HDFS-13802
- HDFS-13852：https://issues.apache.org/jira/browse/HDFS-13852
- HDFS-14114：https://issues.apache.org/jira/browse/HDFS-14114

## 3.4 額外工作

除了貢獻給社群的一些工作，內部也有額外的一些對 RBF 的工作。RBF 的 WebUI 目前的顯示存在一些問題，節點數量、儲存總量的顯示為各個叢集之和，內部對儲存、節點數量的計算做了一些修改；為了更好的對接產品，對外增加了一些 API，方便產品服務透過 API 遠端增加 mount table 條目資訊，而不只是使用管理工具。

# 四、總結

Router-Based Federation 方案在滴滴內部已經上線，穩定執行了兩個多月的時間了，在運維和產品上提供了極大的便利。未來我們會繼續參與社群，為豐富 RBF 的功能以及提高其穩定性貢獻一份力量。

Router-Based HDFS Federation 在滴滴大資料的應用

相關文章