導讀：作為快手內部數據規模和機器規模最大的分佈式文件存儲系統，HDFS一直伴隨著快手業務的飛速發展而快速成長。
本文主要從以下三個層面，介紹下 HDFS系統在快手業務場景下的落地實踐：
HDFS架構介紹
快手HDFS 數據和集群規模介紹
快手HDFS 挑戰與實踐
01 HDFS架構介紹
HDFS 全名 Hadoop Distributed File System，是Apache Hadoop的子項目，也是業界使用最廣泛的開源分佈式文件系統。
核心思想是：將文件按照固定大小進行分片存儲，具備：強一致性、高容錯性、高吞吐性等
架構層面是典型的主從結構：
主節點：稱為NameNode，主要存放諸如目錄樹、文件分片信息、分片存放位置等元數據信息
-
從節點：稱為DataNode，主要用來存分片數據
HDFS官網架構
02 快手HDFS數據規模和集群規模介紹
快手HDFS 歷經 3 年的飛速發展，承載了整個快手幾乎全量的數據存儲，直接或間接的支持了上百種業務的發展。從最初的千臺規模，目前已經發展成擁有幾萬臺服務器、幾EB數據的超大規模存儲系統。
1. 業務類型
在整個數據平臺中，HDFS 系統是一個非常底層也是非常重要的存儲系統，除了常用的Hadoop生態開源組件之外，還承載諸如kafka、clickhouse等在線核心組件數據（ps：有興趣的同學可以私聊）
2. 集群規模
作為數據平臺中最底層的存儲系統，目前也是整個快手中機器規模和數據規模最大的分佈式存儲系統，單個HDFS集群擁有：
幾萬臺服務器
幾EB數據規模、幾百PB的EC數據量
每天擁有幾百PB的數據吞吐
幾十組NameService
幾百億元數據信息
百萬級Qps
03 快手HDFS挑戰與實踐
在數據爆炸式增長的過程中，HDFS 系統遇見的挑戰是非常大的。接下來，主要從HDFS架構四個比較核心的問題入手，重點介紹下快手的落地過程。
主節點擴展性問題
單NS性能瓶頸問題
節點問題
分級保障問題
1. 主節點擴展性問題
眾所周知，主節點擴展性問題是一個非常棘手，也是非常難解決的問題。當主節點壓力過大時，沒辦法通過擴容的手段來快速分擔主節點壓力。
隨著集群規模越來越大，問題也越來越嚴重。我們認為要解決這個問題，至少需要具備兩個能力：
具備快速新增NameService的能力
具備新增NS能快速分擔現存NS壓力的能力
無論社區2.0的Federation架構，還是社區最新3.0的Router Based Federation架構，都不能很好的滿足這兩個條件。綜合討論了多個方案之後，我們決定在社區最新3.0的RBF架構基礎上，進行深度定製開發，來解決主節點擴展性問題。
首先，我們介紹兩個業務場景的擴展性方案：
① 快手 FixedOrder && RbfBalancer機制
我們支持的第一個擴展性機制：FixedOrder機制
將一個路徑掛載到多個NS上，記為FixedOrderMountPoint
FixedOrderMountPoint下所有新建目錄或文件都寫到期望的NS（比如新增NS）
FixedOrderMountPoint下目錄或文件的訪問，通過探測的方式，可以有效的訪問到新老數據（增加FixedOrderMountPoint前後的文件或目錄）
利用這個機制，可以通過快速新增NS，來有效緩解熱點NS Qps壓力過大的問題。
除此之外，我們還研發了RbfBalancer機制，通過FastCp的方式，在業務完全透明的場景下將存量數據異步搬遷到新的NS裡，達到緩解老NS內存壓力的效果。由於老NS Qps壓力已經被快速分擔，所以異步數據遷移的進度，沒有強要求。
利用FixedOrder + RBFBalancer機制，通過擴容新NS並快速分擔老NS的壓力，來解決大多數場景的擴展性問題。
② 快手 DFBH 機制
眾所周知，分佈式開源組件中存在大量Staing路徑，比如：Yarn Staing路徑、Spark Staing路徑、Hive scratchdir路徑、Kafka Partition路徑等，這一類路徑有兩個特點：
Qps非常大，需要多個NS承擔
具有短暫的生命週期
針對這一類路徑 ，我們引入了DFBH機制，來解決主節點擴展性問題：
通過一致性Hash實現多NS間Qps負載均衡
利用動態FixedOrder機制，在不搬遷數據的場景下，實現透明擴縮容NS
實現的核心思想是：
每個路徑依據多組一致性Hash列表計算出歸屬NS，組合成FixedOrder
將增量數據寫到期望NS 中 ，存量數據依舊可見
隨著生命週期推移，逐步回退到最普通的一致性Hash策略
社區貢獻
除了完善多個擴展性方案之外，我們還解決了大量RBF正確性、性能、資源隔離等穩定性問題，同時也積極為社區提供大量BugFix，有興趣的同學可以參考下：
https://issues.apache.org/jira/browse/HDFS-15300
https://issues.apache.org/jira/browse/HDFS-15238
https://issues.apache.org/jira/browse/HDFS-14543
https://issues.apache.org/jira/browse/HDFS-14685
https://issues.apache.org/jira/browse/HDFS-14583
https://issues.apache.org/jira/browse/HDFS-14812
https://issues.apache.org/jira/browse/HDFS-14721
https://issues.apache.org/jira/browse/HDFS-14710
https://issues.apache.org/jira/browse/HDFS-14728
https://issues.apache.org/jira/browse/HDFS-14722
https://issues.apache.org/jira/browse/HDFS-14747
https://issues.apache.org/jira/browse/HDFS-14741
https://issues.apache.org/jira/browse/HDFS-14565
https://issues.apache.org/jira/browse/HDFS-14661
2. 單NS性能瓶頸問題
眾所周知，HDFS 架構中NameNode 的實現中有一把全局鎖，很容易就達到處理瓶頸。社區最新3.0提出了一個Observer Read架構，通過讀寫分離的架構，嘗試提升單個NameService的處理能力，但是最新的架構問題比較多。
針對單NS性能瓶頸這個問題，我們嘗試從兩個階段解決：
快手特色ObserverRead架構，從讀寫分離角度提升NS處理能力【重點介紹】
優化NameNode全局鎖，從提升單NN處理能力角度提升NS處理能力【進行中】
快手特色ObserverRead架構
快手特色ObserverRead架構是基於最新的RBF框架落地的，在客戶端完全透明的場景下，實現動態負載路由讀請求的功能，提升整個NS處理能力。
相比社區的ObserverRead架構，快手特色ObserverRead架構有幾個非常明顯的優勢：
整個架構，基於RBF框架實現，客戶端完全透明
Router檢測NN節點狀態，實現動態負載路由讀請求
Standby、Active節點可以支持讀請求
Observer節點支持快速擴容
在整個最新架構落地過程中，也解決了社區ObserverRead架構大量穩定性問題，比如：
MSync RPC穩定性問題
Observer Reader卡鎖問題
NameNode Bootstrap失敗問題
Client Interrupt導致無效重試問題（HDFS-13609）
3. 慢節點問題
隨著集群規模越來越大，慢節點問題也越來越明顯，經常導致作業出現長尾Task、訓練“卡住”等問題。
慢節點問題主要體現在從節點DataNode上，主要是因為物理指標負載比較大，比如：網卡流量、磁盤Util、Tcp 異常等。
針對這個問題，我們從兩個大的方向著手解決：
慢節點規避
慢節點根因優化
① 慢節點規避
主要從事先規避和事中熔斷兩個角度來實現HDFS層面的慢節點規避機制。
事先規避，即客戶端在讀寫數據前，NameNode依據DN的負載信息進行排序，優先返回低負載的DN。
其判斷依據主要有：負載指標（CPU使用率、磁盤Util、網卡流量、讀寫吞吐量）；客戶端上報慢節點。
事中熔斷，即客戶端在讀寫數據過程中，通過吞吐閾值實時感知慢節點，進行實時慢節點摘除功能。
通過事先規避和事中熔斷機制，能有效地解決長尾Task、訓練“卡住”等問題。
② 慢節點根因優化
從資源利用率最大化的角度出發，從節點DataNode機器是和Yarn NodeManager混布的。
通過硬件指標採集發現：Yarn MapReduce的shuffle功能對硬件繁忙程度貢獻度非常大，所以我們從Yarn Shuffle優化和DN內部機制優化兩個角度嘗試從根因入手解決慢節點問題。
這裡，我主要介紹下DN內部優化邏輯，主要包括：
在線目錄層級降維
即DN在不停讀寫的場景下，實現block存儲目錄的降維工作，極大地縮減磁盤元數據信息。
DataSet全局鎖優化
將DN內部全局鎖細粒度化，拆分成BlockPool + Volume 層級，降低BlockPool之間、磁盤之間的相互影響。
Du操作優化
將定期的DU操作，通過內存結構計算單磁盤BP使用量。
選盤策略優化
添加負載選盤策略，優先選擇負載比較低的磁盤。
4. 分級保障問題
眾所周知，快手經常有一些大型活動，比如春節活動、電商活動、拉新活動等，而且整個活動過程中還伴隨著無數個例行任務。
瞬間的洪峰流量，可能會導致HDFS系統滿載，甚至過載。
為了在HDFS 系統滿載的場景下儘可能的保障高優先級任務正常運行，所以我們將所有任務抽象成高優先級、中優先級和低優先級任務，同時HDFS系統支持分級保障功能，來滿足這個需求。
我們主要從NameNode和DataNode兩個角色入手，支持分級保障功能。
NameNode分級保障功能
我們深度定製了NameNode Rpc框架，將隊列拆分成優先級隊列，Handler依據資源配比依次處理不同優先級隊列請求。與此同時，通過壓力感知模塊，實時感知各個優先級請求的壓力，並動態調整資源配比，從而實現：
未滿載時，按照資源配配比處理請求
滿載時，資源傾向高優，優先處理高優請求
DataNode分級保障功能
由於DataNode內部是通過獨佔線程方式與客戶端進行數據IO的，所以我們在每個磁盤上添加了磁盤限速器。
當磁盤資源達到上限後，高優先級請求到來時，會強佔低優先級資源。除此之外，我們還添加了閾值調整模塊，實時感知相關指標，動態調整磁盤限速器閾值，來控制單盤壓力。
5. 快手HDFS架構圖
最後，我們介紹下目前快手HDFS 系統的最新架構。
整個架構整體分為三層，分別是：路由層、元信息層和數據層。
① 路由層
由一組無狀態的Router服務組成，Router間通過ZK來共享掛載點信息等，主要用於轉發客戶端的元信息請求。
② 元信息層
由多組相互獨立的NameService組成，每組NameService內主要有一臺Active NameNode服務、一臺Standby NameNode服務、N臺Observer NameNode服務組成。
其中：
Active和Standby通過ZKFC實現動態HA切換的功能
Active主要承擔寫請求壓力
Standby除了承擔定期Checkpoint功能外，還支持部分讀請求
Observer主要分擔讀請求壓力
③ 數據層
由一組無狀態的從節點(DataNode)組成，主要用來存在數據；通過心跳、塊彙報等Rpc與主節點保持最新狀態。
04 結尾
快手HDFS 經歷了3年的發展，從最初的幾百臺節點支持PB級數據量的小規模集群，到現在的擁有幾萬臺節點支持EB級數據量的超大規模集群。我們團隊用無數個黑夜，經歷了數據爆炸式增長的過程，抗住了巨大壓力，踩了無數的坑，同時也積累大量經驗。
當然，快手依舊處於飛速發展過程中，我們團隊依舊不忘初心，懷著敬畏之心，繼續匠心前行。
PS：快手-數據平臺火熱招聘中，包括數據架構研發工程師、數據產品Java後端開發、數據產品經理等熱門崗位，聯繫方式：[email protected]”
今天的分享就到這裡，謝謝大家。
在文末分享、點贊、在看，給個3連擊唄~
分享嘉賓：
徐增強，快手分佈式存儲高級研發工程師。主要負責HDFS系統 的運維和研發工作，Hadoop、Kafka活躍Contributor，主要關注分佈式存儲技術領域。
歡迎大家留言討論
👆 👆 👆
HDFS ACL權限設置
最後說一句(求關注，別白嫖我)
掃一掃，我們的故事就開始了。
另外公眾號改變了推送規則，大家看文章不要忘記點擊最下方的在看，點贊按鈕，這樣微信自動識別為常看公眾號，否則很可能推送的文章可能淹沒在別的文章找不到，謝謝大家。
讓我知道你在看
