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

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

ViewFS 方案也存在一些問題：

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

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

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

Router-Based Federation 方案介紹

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

 

 

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

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

 

 

1、Router 組件

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

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

2)在 State Store 中維護(hù)關(guān)于 Namenode 的信息。

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

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

1.1 可用性與容錯性

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

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

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

1.2 Safe Mode

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

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

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

1.3 交互接口

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

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

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

2、State Store 組件

State Store 維護(hù)的信息包括：

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

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

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

2.1 Membership

Membership 反映了 Federation 中的 Namenode 的狀態(tài)。包括有關(guān)子集群的信息，例如存儲量和節(jié)點(diǎn)數(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 只是實(shí)現(xiàn)了一些基本 Namenode 接口，有些接口并不支持，HDFS-13655( https://issues.apache.org/jira/browse/HDFS-13655 )中會實(shí)現(xiàn)一些不支持的協(xié)議接口;當(dāng)前 RBF 的穩(wěn)定性也還存在一些問題，HDFS-13891( https://issues.apache.org/jira/browse/HDFS-13891 )會跟蹤一些穩(wěn)定性問題進(jìn)而解決掉。

Router-Based Federation 在滴滴的應(yīng)用

1、部署情況

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

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

2、兼容性

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

3、RBF 社區(qū)貢獻(xiàn)

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

 

 

4、額外工作

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

總結(jié)

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

作者：費(fèi)輝

標(biāo)簽： 大數(shù)據(jù)的應(yīng)用

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