HDFS 的 Master/Slave 架構(gòu)，使得其具有單點瓶頸，即隨著業(yè)務數(shù)據(jù)的大規(guī)模膨脹，Master 節(jié)點在元數(shù)據(jù)存儲與提供服務上都會存在瓶頸。為了克服 HDFS 單點瓶頸存在的擴展性、性能、隔離問題，社區(qū)提出了 Federation(https:// issues.apache. org/jira/browse/HDFS-1052 )方案來進行解決。

但是使用該方案之后，暴露給客戶的問題就是，同一個集群出現(xiàn)了多個命名空間(namespace)，客戶需要知道讀寫的數(shù)據(jù)在哪個命名空間下才可以進行操作。為了解決統(tǒng)一命名空間的問題，社區(qū)提出了基于客戶端(client-side)的解決方案 ViewFS(https:// issues.apache. org/jira/browse/HADOOP-7257 )，該方案會在客戶端做好配置，用戶目錄一對一的掛載到具體的命名空間目錄上，滴滴在解決 Federation 問題時使用的就是這個方案。

ViewFS 方案也存在一些問題：

對于已經(jīng)發(fā)布出去客戶端升級比較困難;

對于新增目錄需要增加掛載配置，與產(chǎn)品對接，維護起來比較困難。

社區(qū)在 2.9 和 3.0 版本中發(fā)布了一個新的解決統(tǒng)一命名空間問題的方案 Router-Based Federation(https:// issues.apache. org/jira/browse/HDFS-10467 )，該方案是基于服務端進行實現(xiàn)的，在升級管理方面比較好維護，滴滴最近引入了該方案，并進行了一些改造。

Router-Based Federation 方案介紹

Router-Based Federation 對外提供了 Router 服務，包含在 Federation layer 中，如下圖所示。這個 Router 服務將允許用戶透明地訪問任何子集群，讓子集群獨立管理自己的 Blockpool。為了實現(xiàn)這些目標，F(xiàn)ederation layer 必須將 Block 訪問引導至適當?shù)淖尤杭�。同時，它具有可擴展性，高可用性和容錯性。

 

 

Federation layer 包含多個組件。Router 是一個與 Namenode 具有相同接口的組件，根據(jù) State Store 的元數(shù)據(jù)信息將客戶端請求轉(zhuǎn)發(fā)給正確的子集群。State Store 組件包含了遠程掛載表(具有 ViewFS 特性，但在客戶端之間共享)和有關 SubCluster 的負載 / 空間信息。

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

 

 

1、Router 組件

系統(tǒng)中可以有多個的 Router，每個 Router 有兩個角色：

1)向客戶端提供一個全局 Namenode 接口并負責轉(zhuǎn)發(fā)請求正確的子群集中的 Active Namenode;

2)在 State Store 中維護關于 Namenode 的信息。

Router 在收到客戶端請求，根據(jù) mount-table 中的信息查找正確的子集群，然后轉(zhuǎn)發(fā)對該集群請求到對應子集群 Active Namenode。在收到 Active Namenode 的響應結(jié)果之后，將結(jié)果返回給客戶端 。 為了提升性能，Router 可以緩存遠程掛載表條目和子集群的狀態(tài)。

對于 Namenode 信息的維護，Router 定期檢查一個 Namenode 的狀態(tài)和向 State Store 報告其高可用性(HA)狀態(tài)和負載 / 空間狀態(tài)。 為了提高 Namenode HA 的性能，Router 使用 State Store 中的高可用性狀態(tài)信息, 以將請求轉(zhuǎn)發(fā)到最有可能處于活動狀態(tài)的 Namenode。

1.1 可用性與容錯性

Router 是無狀態(tài)的，所有 Router 同時提供服務。如果某個 Router 變成不可用，不影響其他任何 Router 提供服務。

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

為了實現(xiàn)高可用性和靈活性，多個 Router 可以監(jiān)控相同的 Namenode 并把心跳發(fā)送信息到 State Store。 如果 Router 出現(xiàn)故障，這會增加信息的恢復能力。

1.2 Safe Mode

如果 Router 不能連接到 State Store，它可能會錯誤地提供過期 locations 的訪問，讓 Federation 進入不一致的狀態(tài)。

為防止這種情況發(fā)生，當 Router 無法連接到 State Store 一段時間后，它會進入安全模式(類似于 Namenode 的 safe mode)。當客戶端嘗試訪問 safe mode 的 Router 時候，會拋出異常，客戶端的 Proxy 捕獲后，會嘗試連接其他的 Router。類似于 Namenode，Router 保持在這個安全模式，直到它確定 State Store 可用為止。

這可以防止 Router 啟動時出現(xiàn)不一致。 假定一個 Router 如果在一段時間內(nèi)沒有心跳(例如，心跳間隔的五倍)，則它已經(jīng)死亡或處于安全模式。

1.3 交互接口

為了與用戶和管理員進行交互，Router 公開了多個接口。包括 RPC、Admin、WebUI 。

RPC 實現(xiàn)了客戶端與 HDFS 交互的最常見接口。 目前僅支持使用普通 MapReduce，Spark 和 Hive ( on Tez，Spark 和 MapReduce)。一些高級特性，如快照、加密和分層存儲在未來版本實現(xiàn)。 所有未實現(xiàn)的功能都會拋出異常。

Admin 為管理員實現(xiàn)的一個 RPC 接口，包括從子集群獲取信息、添加 / 刪除條目到 mout table。也可以通過命令行獲取和修改 Federation 信息。WebUI 實現(xiàn)了一個可視化 Federation 狀態(tài)，模仿了當前的 Namenode UI，除此之外，還包含 mout table，每個子集群的成員信息以及 Router 的狀態(tài)。

2、State Store 組件

State Store 維護的信息包括：

1)子集群的塊訪問負載，可用磁盤空間，HA 狀態(tài)等狀態(tài);

2)文件夾 / 文件和子集群之間的映射，即遠程 Mount Table;

3)Router 的狀態(tài)。State Store 的后端存儲是可配置的。 既可以可以存儲在文件中，也可以存在 ZooKeeper 中。

2.1 Membership

Membership 反映了 Federation 中的 Namenode 的狀態(tài)。包括有關子集群的信息，例如存儲量和節(jié)點數(shù)量。Router 定期檢測一個或多個 Namenode 的信息。

2.2 Mount Table

管理文件夾和子集群之間的映射。 它與 ViewFS 中的 Mount Table 類似：

 

2.3 Router State

為了跟蹤 Router 中 caches 的狀態(tài)，Router 將其版本信息、狀態(tài)信息等存儲在 State Store 中。

3、未來計劃

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

Router-Based Federation 在滴滴的應用

1、部署情況

社區(qū) Hadoop 在 2.9 和 3.0 中發(fā)布了 RBF 這個 Feature，滴滴目前的 Hadoop 版本是 2.7.2，我們的做法是將 branch-2 分支里關于 RBF 的提交都移植到了我們的代碼中，做了一些必要的修改工作。

在滴滴的大數(shù)據(jù)集群中，F(xiàn)ederation 拆成了 5 組 Namenode。經(jīng)過性能測試，我們得出這樣的結(jié)論：一個 Router 對應服務一組 Namenode 不存在壓力，因此我們選擇部署 5 個 Router 來服務整個集群。目前 Router-Based Federation 方案在滴滴已經(jīng)穩(wěn)定運行 2 月有余。

2、兼容性

直接引入 RBF 在運行 Hive 任務時會出現(xiàn)一些錯誤，例如 Wrong FS 等等。為此我們將 Hive 客戶端代碼做了修改，使其兼容 RBF。在 Hive 的元數(shù)據(jù)存儲中，location 信息存儲的是帶 HDFS Schema 的絕對路徑信息，在 Hive 代碼中處理 move 邏輯時，我們都會將路徑做一個 resolve 得到實際的 HDFS 路徑，然后再進行處理，這樣可以避免該問題的出現(xiàn)。

3、RBF 社區(qū)貢獻

在實際測試中，我們也發(fā)現(xiàn)了 RBF 的一些性能問題和 BUG，包括 Quota 問題、mount-table cache 使用不當問題、mount-table 創(chuàng)建 znode 出現(xiàn) Null 問題等等。在解決這些問題之后，將 patch 貢獻給了社區(qū)，大部分被社區(qū)接收，具體修復和優(yōu)化如下：

 

 

4、額外工作

除了貢獻給社區(qū)的一些工作，內(nèi)部也有額外的一些對 RBF 的工作。RBF 的 WebUI 目前的顯示存在一些問題，節(jié)點數(shù)量、存儲總量的顯示為各個集群之和，內(nèi)部對存儲、節(jié)點數(shù)量的計算做了一些修改;為了更好的對接產(chǎn)品，對外增加了一些 API，方便產(chǎn)品服務通過 API 遠程增加 mount table 條目信息，而不只是使用管理工具。

總結(jié)

Router-Based Federation 方案在滴滴內(nèi)部已經(jīng)上線，穩(wěn)定運行了兩個多月的時間了，在運維和產(chǎn)品上提供了極大的便利。未來我們會繼續(xù)參與社區(qū)，為豐富 RBF 的功能以及提高其穩(wěn)定性貢獻一份力量。

作者：費輝

標簽： 大數(shù)據(jù)的應用

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。