字節跳動10萬節點HDFS集羣多機房架構演進之路

背景

現狀

HDFS 全稱是 Hadoop Distributed File System，其自己是 Apache Hadoop 項目的一個模塊，做爲大數據存儲的基石提供高吞吐的海量數據存儲能力。自從 2006 年 4 月份發佈以來，HDFS 目前依然有着很是普遍的應用，以字節跳動爲例，隨着公司業務的高速發展，目前 HDFS 服務的規模已經到達「雙 10」的級別：markdown

單集羣節點 10 萬臺級別
單集羣數據量達到 10EB 級別

主要使用場景包括架構

離線
- OLAP 查詢引擎存儲底座，包括 Hive/ClickHouse/Presto 等場景
- 機器學習離線訓練數據
近線
- ByteMQ
- 流式任務 Checkpoint

業界不少公司在維護 HDFS 服務時，採用的都是小集羣模式，即生產上部署多個隔離獨立的 HDFS 集羣知足業務的不一樣需求。字節跳動採用的是橫跨多個機房的聯邦大集羣部署模式，即 HDFS 只有一個集羣，這個集羣有多個 nameservice，可是底層的 DN 是橫跨 A/B/C 3 個機房的，因爲社區版 HDFS 沒有機房感知相關的支持，所以字節跳動 HDFS 團隊在這個功能上作了專門的設計和實現，本文會介紹這部分的工做。運維

動機

業務的迅猛發展和業務場景的多樣性給 HDFS 帶來了很大的挑戰，這裏列幾個比較有表明性的問題：機器學習

如何在容量上知足業務的發展需求
如何知足近線場景對低延遲的需求
如何知足關鍵業務的機房級別容災需求
如何高效運維如此超大規模的集羣

要回答這些問題須要 HDFS 從多個方向迭代優化，例如 DanceNN 的上線、運維平臺的建設等，本文不會介紹字節跳動 HDFS 全部的演進方案，而是聚焦在 HDFS 多機房架構的演進策略上，它直接回答了上面提到的兩個問題，即：oop

如何在容量上知足業務的發展需求：數據如何合理地在多個機房之間存放以便能經過其餘機房的資源進行快速擴容？
如何知足關鍵業務的容災需求：系統如何知足核心業務機房級別的容災需求？

社區版架構

字節跳動的 HDFS 技術脫胎於 Apache 社區的 HDFS，爲了方便你們理解內部版本的技術發展歷程，本小節咱們將先了解一下社區 HDFS 的架構。性能

圖(1) Apache 社區 HDFS 架構學習

從圖(1) 能夠看出，社區 HDFS 從架構上劃分能夠分爲 3 部分：大數據

Client：訪問 HDFS 的 client，主要經過 HDFS SDK 和 HDFS 進行交互，HDFS SDK 的實現比較重，不少 IO 處理邏輯都是在 SDK 實現，所以這裏單獨列爲架構的一部分。
元數據管理：即 NameNode，負責集羣的元數據管理，包括目錄樹和數據塊的位置信息。爲了解決元數據膨脹問題，社區提供了 Federation 的功能，引入了 NameService 的概念，簡單地說，每個 NameService 提供一個 NameSpace，爲了保證 NameNode 的高可用，一個 NameService 包含多個 NameNode 節點（通常是 2 個），這些 NameNode 節點以一主多備的模式工做。Federation 功能跟多機房架構並無必要的關聯，所以接下來討論咱們將不會涉及 Federation/NameService 等概念。
數據管理：即 DataNode，負責存放用戶的實際數據，前面提到 NameNode 一個功能是管理數據塊的位置信息，在具體實現上，NameNode 不會持久化這些塊的信息，而是靠 DataNode 主動彙報來維護。

到目前爲止，HDFS 集羣的多機房架構相關的方案基本都是元數據層完成的，所以接下來咱們的討論將會聚焦在元數據部分。在本文剩餘篇幅裏，除非特別聲明，不然相關術語都是指字節跳動版的 HDFS。優化

字節版架構

圖(2) 字節跳動 HDFS 架構spa

注：因爲 BookKeeper 自身的架構設計，NameNode(DanceNN)其實是須要經過 ZooKeeper 去發現 BookKeeper 的 endpoint 信息的，這裏爲了方便理解，沒有把這部分通訊關係畫出來。

對比圖(1) 和圖(2)，咱們能夠發現，字節跳動的 HDFS 依然保留了社區 HDFS 的核心架構，同時也加入了一些特有的功能，包括：

DanceNN，即字節跳動用 C++從新實現的 NameNode，協議上基本兼容社區版的 NameNode。除非特別說明，不然後面出現 DanceNN、NameNode 均指代 DanceNN。
NNProxy，即 NameNode Proxy，爲 Federation 功能提供統一的 Namespace，因爲跟多機房架構直接關係不大，這裏再也不詳細展開。
BookKeeper，即 Apache BookKeeper，其做用是跟社區的 JournaNode 是同樣的，就是爲 Active 和 Standby NameNode 提供一個共享的 editlog 存儲方案，這是實現 NameNode 的 HA 方法的基礎。

值得一提的是，BookKeeper 自己提供了機房級別的保存配置策略，這是 HDFS 多機房容災方案的基礎，這個特性確保了 HDFS NameNode 提供跨機房容災能力，後面咱們將繼續深刻討論。

演進

雙機房

前面提到當前 HDFS 的大集羣是橫跨 A/B/C 的多機房模式，具體的演進順序是 A -> A,B -> A,B,C ，如今也保持了直接擴展到更多機房的能力。本小節將着重介紹 A -> A,B 的雙機房演進過程，後面的多機房架構的設計思想主要仍是雙機房架構的擴展。

數據放置

圖(3) 字節跳動 HDFS 雙機房 DataNode 結構

HDFS 雙機房數據放置方案在設計上總結起來能夠描述以下：

A/B 機房的 DN 直接跨機房組成一個雙機房集羣，向相同的 NameNode 彙報。
每個文件在寫的時候會保證每一個機房至少存在一個副本，數據實時寫到兩個機房。
每一個 Client 在讀取文件的時候，優先讀取本機房的副本，避免產生大量的跨機房讀帶寬。

這個設計的好處就是存儲層對上層應用屏蔽了集羣細節，計算資源能夠直接無感分配。該設計結合離線數據一寫多讀的特色，充分考慮跨機房帶寬的合理使用。

因爲寫帶寬通常不會有突發，機房間的離線帶寬能夠支撐同步寫的需求，所以數據能夠兩個機房同步放置至少一個副本。
離線查詢容易有大的突發請求，所以須要確保常規狀態下沒有突發的跨機房讀帶寬。

在實現上關鍵是 DanceNN 加入了機房的感知能力，DanceNN 在 client 進行數據操做時加入對機房拓撲的識別，因爲 DanceNN 對外的協議沒有改動，所以上層應用不須要作感知改動。

容災設計

前面介紹了雙機房架構裏數據放置的設計，它解決了容量擴展的問題，可是並無解決機房級別的容災問題，儘管 NameNode 以一主多備的形式實現了高可用，可是全部 NameNode 仍是放在一個機房，在字節跳動基礎架構的容災體系裏，是須要作到機房級別的容災。因爲 HDFS 的數據已經實現了多機房數據副本的同步寫入，爲了達成容災的目標，只須要把元數據也演進到雙機房架構便可實現機房級別的容災。前面咱們所說的 HDFS 的元數據組件其實包含了兩部分，即 NameNode 和 NameNode Proxy(NNProxy)，因爲 NNProxy 是無狀態的轉發服務，所以元數據的多機房架構咱們只須要關注在 NameNode 設計上。

圖(4) 字節跳動 HDFS NameNode 體系

從圖(4) 能夠看出 NameNode 包含了 3 個關鍵模塊：

Apache ZooKeeper，爲 Apache BookKeeper 提供元數據服務。
Apache BookKeeper，爲 NameNode 的高可用方案提供 EditLog 共享存儲方案。
DanceNN，即字節跳動自研的高性能 NameNode 實現。

這 3 者構成一個分層的單向依賴關係鏈， DanceNN -> BookKeeper -> ZooKeeper，所以這 3 者能夠獨立完成雙機房的容災方案，最終在總體上呈現一個雙機房容災的 NameNode 元數據服務。

組件	多機房方案
ZooKeeper	一個 ZK ensemble 由 5 臺 server 組成，這 5 臺 server 分佈在 3 個機房，分佈比例爲 A:B:C = 2:2:1
BookKeeper	一個 BK cluster 一般由 14 臺 server 組成，分佈在 2 個機房，分佈比例爲 1:1
DanceNN	一個 NameService 包含 5 個 DanceNN，這個 5 個 DanceNN 分佈在 2 個機房，分佈比例爲 3:2，工做模式爲 1 active + 4standby

在實現上，這裏面的關鍵就是 DanceNN 的 editlog 機房寫策略，由於 DanceNN 在作主備切換的時候，若是 editlog 無法保持同步，那麼服務是不可用的，得益於 BookKeeper 的機房感知的數據放置功能，DanceNN 能夠經過這些策略來完成雙機房容災方案。

常態下，editlog 會以 4 個副本存放到 BookKeeper 上，這 4 個副本的機房分佈比例爲 1:1。
容災場景下，DanceNN 能夠快速切換成單機房模式，editlog 依然以 4 個副本存放，可是存儲策略變爲單機房存儲，歷史的 editlog 也能正常消費。

旁路系統

前面已經介紹完了 HDFS 雙機房方案的主體設計，可是事實上一個方案的推動落地除了架構上的迭代演進以外，還須要一系列的旁路系統來配合支持，包括：

Balancer：須要感知機房放置
Mover：須要保證數據的實際放置知足多機房策略
運維繫統
- 在 federation 架構下，多個 nameservice 須要保證切主的效率
- 運維操做預案：提早預判相關可能的故障，而且能在運維繫統上執行
業務的平穩過渡方案，儘量少地減小對業務干擾

限於篇幅，本文不會對這些展開細節描述，感興趣的同窗能夠再交流。

多機房

HDFS 多機房架構是對雙機房架構的擴展，其研發直接動機是機房的資源供應短缺問題，例如 2020 年 B 機房幾乎就沒有資源供應，可是在公司新的主機房 C 卻有較爲充裕的資源。一開始咱們是嘗試將 C 機房做爲一個獨立的集羣提供服務，可是發現業務的血緣關係太過複雜，遷移成本過高，所以選擇了基於雙機房機房擴展到多機房的方法，該方案須要知足這些需求。

合理使用跨機房帶寬
兼容已有的雙機房方案
遷移成本儘量小
符合字節跳動的機房級別容災標準

最終的設計方案爲：

數據放置策略支持多機房，同時兼容已有的雙機房放置策略
NameNode 的容災方案策略不變，由於在多機房架構下，HDFS 依然只保證一個機房範圍的故障容災

相應的旁路系統也作相應的調整，儘管 HDFS 底層提供了數據放置在多個機房的策略，可是在離線場景中，用戶只能選擇 2 個機房存放，例如 A/B， B/C，A/B，這個運營上的策略選擇是綜合考慮了穩定性、帶寬使用的合理性以及資源的合理利用以後肯定的，核心目標仍是保障業務的平穩發展，從後續實踐下來看，這個策略是一個很是正確的選擇。

結語

根據咱們的不徹底調研，字節跳動 HDFS 的多機房架構在業界中是有本身獨特的路線，這個中緣由主要仍是公司業務高速發展和機房建設方向在業界中也是獨樹一幟的，這些因素驅動 HDFS 進行本身獨特迭代演進，從結果來看是達到預期，例如 2020 年 C 機房的充分使用，在 B 機房沒有資源供應的狀況下依然保障了業務的平穩；2021 春晚活動，爲近線業務例如 ByteMQ、流式 CheckPoint 等提供了多機房的容災策略保障。

最後，HDFS 的多機房架構依然在持續迭代，中長期來看，不排除有更多新機房的出現，這些都給 HDFS 多機房架構提出更多的挑戰，原來多機房方案的基礎條件再也不具有，所以 HDFS 團隊已經開啓相關功能的迭代，敬請期待！

加入咱們

字節跳動大數據存儲團隊是大數據存儲領域行業領軍者，負責整個字節跳動全球大數據存儲基礎設施的建設，支持今日頭條、抖音、西瓜視頻，番茄小說、電商、遊戲以及教育等衆多產品線，管理數十EB的數據。咱們長期致力於超大規模存儲系統的技術演進，包括訪問加速，數據流轉、成本優化、高效運維和服務可用性等方向，歡迎更多同窗加入咱們，一塊兒構建下一代10EB級別的存儲系統，工做地點是上海，感興趣能夠聯繫 fandi.3@bytedance.com 並註明大數據存儲方向。