Router-Based HDFS Federation 在滴滴大數據的應用

出品 | 滴滴技術

做者 | 費輝

1.背景

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 ），該方案是基於服務端進行實現的，在升級管理方面比較好維護，滴滴最近引入了該方案，並進行了一些改造。

2.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）具備相同的架構。

一、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 的狀態。

二、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 相似：hdfs://tmp → hdfs://C0-1/tmp /* Folder tmp is mapped to folder tmp in subcluster C0-1 */

2.3 Router State

爲了跟蹤 Router 中 caches 的狀態，Router 將其版本信息、狀態信息等存儲在 State Store 中。

三、將來計劃

目前 RBF 只是實現了一些基本 Namenode 接口，有些接口並不支持，HDFS-13655（https://issues.apache.org/jira/browse/HDFS-13655 ）中會實現一些不支持的協議接口；當前 RBF 的穩定性也還存在一些問題，HDFS-13891（https://issues.apache.org/jira/browse/HDFS-13891 ）會跟蹤一些穩定性問題進而解決掉。

3.Router-Based Federation 在滴滴的應用

一、部署狀況

社區 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 月有餘。

二、兼容性

直接引入 RBF 在運行 Hive 任務時會出現一些錯誤，例如 Wrong FS 等等。爲此咱們將 Hive 客戶端代碼作了修改，使其兼容 RBF。在 Hive 的元數據存儲中，location 信息存儲的是帶HDFS Schema 的絕對路徑信息，在 Hive 代碼中處理 move 邏輯時，咱們都會將路徑作一個 resolve 獲得實際的 HDFS 路徑，而後再進行處理，這樣能夠避免該問題的出現。

三、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

四、額外工做

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

4.總結

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