做大數(shù)據(jù)方向繞不開的第一個(gè)存儲(chǔ)組件基本就是 HDFS。我剛開始接觸分布式存儲(chǔ)的時(shí)候也踩過不少坑以為 Hadoop 就是跑 MapReduce以為 HDFS 只是“把文件切開放在多臺(tái)機(jī)器上”后來真正上手搭集群、調(diào)參數(shù)、排查丟數(shù)據(jù)問題才發(fā)現(xiàn)這套文件系統(tǒng)的設(shè)計(jì)遠(yuǎn)比想象中復(fù)雜。這次借“Hadoop HDFS 分布式存儲(chǔ)系統(tǒng)入門、配置、使用及架構(gòu)原理分析”這個(gè)主題把 HDFS 從理論到實(shí)戰(zhàn)完整梳理一遍希望對(duì)剛?cè)腴T分布式存儲(chǔ)、或者準(zhǔn)備深入理解 Hadoop 生態(tài)的朋友有幫助。這篇內(nèi)容主要拆成四塊先說清楚 HDFS 到底解決了什么現(xiàn)實(shí)問題然后從架構(gòu)層面把 NameNode、DataNode、副本機(jī)制這些核心組件講明白再手把手帶你完成一套可運(yùn)行的集群環(huán)境搭建與基礎(chǔ)配置最后落到真實(shí)使用場(chǎng)景里的命令操作、讀寫流程、容錯(cuò)機(jī)制以及我在實(shí)際項(xiàng)目中踩過的坑和調(diào)優(yōu)思路。無論你是數(shù)據(jù)工程師、后端開發(fā)者還是準(zhǔn)備面試大數(shù)據(jù)崗位的求職者都能從里面找到可以直接用的東西。1. 為什么需要 HDFS單機(jī)存儲(chǔ)的物理極限與分布式文件系統(tǒng)的誕生邏輯1.1 單機(jī)硬盤在數(shù)據(jù)量面前有多脆弱很多初學(xué)者會(huì)有一個(gè)疑問我直接用普通文件系統(tǒng)不就行了為什么非要搞一套分布式文件系統(tǒng)這個(gè)問題的答案只有親手遇到“單塊磁盤裝不下、單機(jī)讀寫速度跟不上”的時(shí)候才最有體會(huì)。假設(shè)你管理的是每天產(chǎn)生幾百 GB 日志的在線業(yè)務(wù)系統(tǒng)一個(gè)月就是 10 TB 級(jí)別一年百 TB。單臺(tái)服務(wù)器的磁盤容量撐死幾十 TB即便用 RAID 陣列把多塊硬盤拼一起也繞不開兩個(gè)硬瓶頸容量上限和并行吞吐。RAID 確實(shí)能解決一部分可靠性問題比如 RAID1 鏡像、RAID5 校驗(yàn)但它仍然是單機(jī)維度的方案——整機(jī)故障、控制器故障、擴(kuò)容停機(jī)任何一個(gè)都?jí)蚰愫纫粔?。HDFS 的思路完全不同它不追求“把一塊盤做到巨大”而是用一堆普通服務(wù)器組成一個(gè)邏輯上的超大文件系統(tǒng)。橫向擴(kuò)展加節(jié)點(diǎn)就能加容量和吞吐單臺(tái)服務(wù)器壞了也不影響整體數(shù)據(jù)可用性。這種“用便宜機(jī)器堆出可靠存儲(chǔ)”的思路和傳統(tǒng)存儲(chǔ)陣列相比性價(jià)比和擴(kuò)展性優(yōu)勢(shì)非常明顯。1.2 HDFS 的適用邊界和它的“取舍”很多剛接觸 HDFS 的人容易把它當(dāng)成一個(gè)“萬能文件系統(tǒng)”這是第一個(gè)認(rèn)知誤區(qū)。HDFS 的幾個(gè)設(shè)計(jì)目標(biāo)決定了它只適合特定場(chǎng)景大文件優(yōu)先HDFS 默認(rèn)把文件切成 128 MB 的數(shù)據(jù)塊目的是減少尋址開銷、提高順序讀寫的吞吐。適合日志、監(jiān)控?cái)?shù)據(jù)、離線數(shù)倉的原始數(shù)據(jù)、訓(xùn)練樣本集這種動(dòng)輒數(shù) GB 甚至數(shù) TB 的大文件。反過來幾 KB 的小文件如果大量存在會(huì)給 NameNode 內(nèi)存帶來極大壓力。寫一次讀多次HDFS 的文件不支持修改只支持追加寫入和刪除適合“數(shù)據(jù)落地后基本不變”的場(chǎng)景。如果你需要頻繁修改既有文件的中間內(nèi)容HDFS 是要說“不”的。順序讀寫性能優(yōu)秀隨機(jī)讀寫性能弱HDFS 的定位是批量數(shù)據(jù)處理不是數(shù)據(jù)庫。OLTP 型的高并發(fā)隨機(jī)讀寫千萬別往 HDFS 上放那是自找麻煩。高延遲而非低延遲因?yàn)樯婕熬W(wǎng)絡(luò)傳輸、副本同步、元數(shù)據(jù)查詢HDFS 的文件訪問延遲通常以秒級(jí)甚至更高級(jí)別計(jì)適合離線和準(zhǔn)實(shí)時(shí)場(chǎng)景不適合在線業(yè)務(wù)直接掛載讀寫。想明白這些邊界后面選型才不會(huì)走偏。我見過不少團(tuán)隊(duì)把 HDFS 當(dāng)成普通 NAS 用結(jié)果小文件一大堆、NameNode 頻頻告警、查詢性能慘不忍睹后來洗數(shù)據(jù)洗到崩潰——那些坑都是可以在設(shè)計(jì)階段避開的。2. HDFS 架構(gòu)核心拆解兩個(gè)進(jìn)程角色、數(shù)據(jù)塊與元數(shù)據(jù)2.1 NameNode 和 DataNode主節(jié)點(diǎn)管“目錄”從節(jié)點(diǎn)管“貨”HDFS 是典型的主從架構(gòu)整個(gè)系統(tǒng)只有一個(gè)主節(jié)點(diǎn)角色稱為 NameNode配合若干從節(jié)點(diǎn)角色 DataNode 協(xié)同工作。把 HDFS 類比成一個(gè)大型倉庫NameNode 就是倉庫的管理員它不直接搬貨只記三樣賬——文件系統(tǒng)的目錄樹、每個(gè)文件由哪些數(shù)據(jù)塊組成、每個(gè)數(shù)據(jù)塊實(shí)際存放在哪些 DataNode 上。而DataNode 就是負(fù)責(zé)搬貨的工人它們真正在本地磁盤上存放數(shù)據(jù)塊文件并定期向管理員匯報(bào)“我這邊貨都正?！薄拔疫@邊新加了貨”。NameNode 在內(nèi)存中維護(hù)整個(gè)文件系統(tǒng)的元數(shù)據(jù)包括文件與目錄的命名空間文件到數(shù)據(jù)塊的映射關(guān)系數(shù)據(jù)塊到 DataNode 的映射關(guān)系這個(gè)映射在 DataNode 啟動(dòng)后會(huì)通過塊上報(bào)動(dòng)態(tài)構(gòu)建這意味著NameNode 的內(nèi)存大小直接決定了整個(gè)集群能容納的文件數(shù)量。通常每個(gè)文件/目錄對(duì)象大約需要 150~200 字節(jié)的元數(shù)據(jù)開銷所以一臺(tái) NameNode 內(nèi)存 64 GB 時(shí)能支撐的文件數(shù)大約在三千萬到四千萬這個(gè)量級(jí)。HDFS 沒有把元數(shù)據(jù)也拆散存在多臺(tái)機(jī)器上就是為了保證元數(shù)據(jù)的一致性和操作效率。代價(jià)是 NameNode 成為集群的單點(diǎn)這也是后來出現(xiàn) HA高可用方案要解決的核心問題。DataNode 的角色相對(duì)簡(jiǎn)單收到寫數(shù)據(jù)請(qǐng)求后在本地磁盤創(chuàng)建數(shù)據(jù)塊文件定期默認(rèn) 3 秒向 NameNode 發(fā)送心跳默認(rèn)每 10 分鐘上報(bào)一次本節(jié)點(diǎn)上的所有塊信息收到刪除或復(fù)制指令后執(zhí)行相應(yīng)操作。DataNode 本身不保存任何 HDFS 文件目錄級(jí)信息宕機(jī)恢復(fù)后只需要重新向 NameNode 注冊(cè)然后做塊上報(bào)即可。2.2 數(shù)據(jù)塊、副本因子和機(jī)架感知可靠性從設(shè)計(jì)里長(zhǎng)出HDFS 數(shù)據(jù)塊Block是文件存儲(chǔ)的最小單位默認(rèn)大小 128 MB。文件上傳時(shí)被切成若干個(gè) block每個(gè) block 按照集群配置的副本因子默認(rèn) 3在多個(gè) DataNode 上各存一份。3 副本設(shè)計(jì)并不是拍腦袋定的它能在容忍兩臺(tái)/一個(gè)機(jī)架故障和存儲(chǔ)成本之間達(dá)到平衡。副本要存到哪三臺(tái)機(jī)器上涉及 HDFS 非常出名的“機(jī)架感知”策略。假設(shè)你在普通機(jī)架上默認(rèn)副本放置邏輯大致是第一個(gè)副本放在客戶端所在節(jié)點(diǎn)如果客戶端不在集群內(nèi)則隨機(jī)選一個(gè)節(jié)點(diǎn)。第二個(gè)副本放在與第一個(gè)副本不同機(jī)架的某個(gè)節(jié)點(diǎn)。第三個(gè)副本放在與第二個(gè)副本相同機(jī)架的另一個(gè)節(jié)點(diǎn)。這樣的布局既保證了容錯(cuò)機(jī)架間至少有一份副本又兼顧了讀取性能和寫入帶寬。生產(chǎn)環(huán)境里正確配置機(jī)架感知腳本非常重要否則 HDFS 會(huì)把“同一機(jī)架”誤判成“同一節(jié)點(diǎn)”副本分布不合理數(shù)據(jù)可靠性大打折扣。副本不是永遠(yuǎn)不變的HDFS 的 BlockPool 后臺(tái)線程會(huì)周期性地檢查每個(gè)數(shù)據(jù)塊的副本數(shù)量發(fā)現(xiàn)少于配置值就啟動(dòng)復(fù)制補(bǔ)副本發(fā)現(xiàn)多于配置值就刪除多余副本。副本因子也可以在文件或目錄級(jí)別單獨(dú)設(shè)置比如臨時(shí)數(shù)據(jù)可以只保留 1 副本核心數(shù)據(jù)可以設(shè)置 5 副本甚至更多。3. 從零搭建一套可運(yùn)行的 HDFS 環(huán)境版本選擇、配置項(xiàng)詳解與啟動(dòng)驗(yàn)證3.1 選型先看版本Apache Hadoop 與生態(tài)兼容性動(dòng)手搭建之前先確定用哪個(gè)發(fā)行版。Hadoop 開源社區(qū)目前主要能看到兩條路線Apache Hadoop 原生版直接從官網(wǎng)拿裸發(fā)行包自己搭完全掌控適合學(xué)習(xí)、二次開發(fā)或?qū)Π姹炯儍舳扔幸蟮膱F(tuán)隊(duì)。商業(yè)發(fā)行版通常內(nèi)置了更友好的管理界面、安全補(bǔ)丁和企業(yè)支持適合生產(chǎn)環(huán)境圖省心但學(xué)習(xí)場(chǎng)景不一定需要。大多數(shù)學(xué)習(xí)場(chǎng)景我建議直接用 Apache Hadoop 的穩(wěn)定版。版本上重點(diǎn)注意兩個(gè)點(diǎn)一個(gè)是和 JDK 版本的兼容性Hadoop 3.x 一般要求 JDK 8 或 11另一個(gè)是確保你的 Hadoop 版本和后續(xù)生態(tài)組件Hive、Spark、Flink 等兼容否則后面集成階段會(huì)出現(xiàn)各種莫名其妙的依賴沖突。部署形式也可以分為三種真實(shí)多節(jié)點(diǎn)集群最好有三臺(tái)以上機(jī)器、偽分布式單機(jī)一臺(tái)機(jī)器模擬所有角色、容器化部署用 Docker 快速起多節(jié)點(diǎn)。如果是入門學(xué)習(xí)偽分布式配置最簡(jiǎn)單適合快速跑通流程想真正理解副本復(fù)制、數(shù)據(jù)均衡、節(jié)點(diǎn)故障轉(zhuǎn)移這些機(jī)制還是建議至少起三節(jié)點(diǎn)集群。3.2 核心配置文件core-site.xml、hdfs-site.xml 與關(guān)鍵參數(shù)Hadoop 的配置集中放在etc/hadoop/目錄下最常改動(dòng)的是core-site.xml和hdfs-site.xml。下面列出一套三節(jié)點(diǎn)集群的最小可用配置思路。core-site.xml里最重要的參數(shù)是默認(rèn)文件系統(tǒng)地址property namefs.defaultFS/name valuehdfs://namenode-host:9820/value /property9820是 NameNode RPC 通信端口在 Hadoop 3.x 里默認(rèn)就是這個(gè)老版本常用8020或9000。hdfs-site.xml里需要配置的參數(shù)更多逐個(gè)說清楚property namedfs.namenode.name.dir/name value/data/hdfs/namenode/value /property property namedfs.datanode.data.dir/name value/data/hdfs/datanode-1,/data/hdfs/datanode-2/value /property property namedfs.replication/name value3/value /property property namedfs.blocksize/name value134217728/value /propertydfs.namenode.name.dirNameNode 元數(shù)據(jù)落盤目錄。生產(chǎn)環(huán)境中強(qiáng)烈建議配置在同一服務(wù)器的多塊磁盤上或者至少兩塊不同物理磁盤降低單盤故障導(dǎo)致元數(shù)據(jù)丟失的風(fēng)險(xiǎn)。dfs.datanode.data.dirDataNode 數(shù)據(jù)塊存儲(chǔ)目錄可以配多個(gè)目錄逗號(hào)分隔HDFS 會(huì)自動(dòng)做目錄間數(shù)據(jù)均衡。dfs.replication默認(rèn)副本數(shù)三節(jié)點(diǎn)集群配置為 3 沒有問題。dfs.blocksize單位是字節(jié)134217728 即 128 MB。此外還有幾個(gè)在生產(chǎn)環(huán)境里非常重要的參數(shù)dfs.namenode.handler.countNameNode 處理 RPC 請(qǐng)求的線程數(shù)默認(rèn) 10在高并發(fā)訪問下明顯偏低生產(chǎn)環(huán)境一般調(diào)到 50~100 甚至更高。粗略估算公式是20 * log2(集群節(jié)點(diǎn)數(shù))但這個(gè)值不絕對(duì)。dfs.datanode.handler.countDataNode 處理數(shù)據(jù)傳輸?shù)木€程數(shù)默認(rèn) 10負(fù)載較高時(shí)可以適當(dāng)上調(diào)。dfs.heartbeat.interval心跳間隔默認(rèn) 3 秒。不要隨意把心跳間隔調(diào)得過大因?yàn)?Namenode 對(duì) DataNode 是否宕機(jī)的判定依賴心跳超時(shí)超時(shí)時(shí)間默認(rèn)是10 * 心跳間隔。調(diào)太大會(huì)拖慢故障感知速度。配置好之后啟動(dòng)前一定要做的最關(guān)鍵一步是格式化 NameNode 元數(shù)據(jù)。hdfs namenode -format這個(gè)命令會(huì)在dfs.namenode.name.dir指定的目錄下生成初始的 fsimage 文件和 edit log。格式化命令只能執(zhí)行一次重復(fù)格式化會(huì)導(dǎo)致集群 ID 變化DataNode 啟動(dòng)后會(huì)因?yàn)?clusterID 不匹配而無法注冊(cè)到 NameNode屆時(shí)如果數(shù)據(jù)重要恢復(fù)成本極高。所以我的習(xí)慣是格式化之前先確認(rèn)目錄里沒有以前殘留的重要數(shù)據(jù)格式化完立刻看一眼日志輸出里的clusterID。3.3 啟動(dòng)集群與基礎(chǔ)驗(yàn)證方法三節(jié)點(diǎn)分別啟動(dòng)角色進(jìn)程的方式有很多最直接的是手工啟動(dòng)# 在 NameNode 所在節(jié)點(diǎn)執(zhí)行 hdfs --daemon start namenode # 在每個(gè) DataNode 所在節(jié)點(diǎn)執(zhí)行 hdfs --daemon start datanode啟動(dòng)后用jps命令查看進(jìn)程是否都在jps # NameNode 節(jié)點(diǎn)上應(yīng)該看到 NameNode # DataNode 節(jié)點(diǎn)上應(yīng)該看到 DataNode然后訪問 NameNode 的 Web 界面默認(rèn)端口是9870Hadoop 3.x打開后能看到集群整體狀態(tài)、已用空間、DataNode 節(jié)點(diǎn)列表、數(shù)據(jù)塊數(shù)量等信息。如果你的瀏覽器打不開先檢查防火墻和dfs.namenode.http-address的配置。命令行驗(yàn)證集群狀態(tài)hdfs dfsadmin -report這條命令會(huì)輸出每個(gè) DataNode 的存儲(chǔ)容量、已使用空間、剩余空間、數(shù)據(jù)塊數(shù)量?？吹剿?DataNode 都處于In Service狀態(tài)說明集群健康。4. HDFS 實(shí)際使用文件操作命令、Java API 開發(fā)與權(quán)限設(shè)計(jì)4.1 高頻命令行操作不只是 put 和 getHDFS 的所有文件操作都可以通過hdfs dfs命令完成。下面整理的是我日常工作中使用頻率最高的幾個(gè)命令命令作用示例hdfs dfs -put local hdfs上傳本地文件到 HDFShdfs dfs -put access.log /logs/hdfs dfs -get hdfs local下載 HDFS 文件到本地hdfs dfs -get /logs/access.log ./hdfs dfs -cat hdfs查看文件內(nèi)容hdfs dfs -cat /logs/access.loghdfs dfs -tail hdfs查看文件末尾內(nèi)容適合監(jiān)測(cè)增長(zhǎng)中的日志hdfs dfs -tail -f /logs/access.loghdfs dfs -ls -R hdfs遞歸列出目錄內(nèi)容hdfs dfs -ls -R /logshdfs dfs -mkdir -p hdfs遞歸創(chuàng)建目錄hdfs dfs -mkdir -p /etl/day20250101hdfs dfs -rm -R hdfs刪除文件或目錄hdfs dfs -rm -R /tmp/olddatahdfs dfs -chmod -R 755 hdfs遞歸修改權(quán)限hdfs dfs -chmod -R 755 /sharedhdfs dfs -du -h hdfs查看目錄/文件大小hdfs dfs -du -h /logs幾個(gè)命令行使用上的細(xì)節(jié)值得特別注意Hadoop 3.x 里hdfs dfs -tail -f可以實(shí)時(shí)跟蹤文件追加內(nèi)容排查正在寫入的日志文件很好用但前提是寫入方是通過 HDFS 的 append 操作追加數(shù)據(jù)不是文件落地后覆蓋。-put上傳大文件時(shí)如果想要看到實(shí)時(shí)進(jìn)度可以加-progress。上傳過程中如果中斷HDFS 會(huì)保留已經(jīng)寫好的部分塊重新上傳時(shí)會(huì)從斷點(diǎn)恢復(fù)Hadoop 2.7 支持但前提是使用相同的文件路徑和 dfs 客戶端。刪除文件默認(rèn)進(jìn)入回收站而不是立即物理刪除?；厥照鹃_關(guān)是fs.trash.interval默認(rèn)是 0即不啟用回收站。數(shù)據(jù)安全敏感的團(tuán)隊(duì)一定要把回收站打開否則誤刪一個(gè)生產(chǎn)目錄直接全量丟失搶救都無從談起。上百萬個(gè)小文件做完-put后檢查一下 NameNode 的內(nèi)存使用你會(huì)對(duì)“小文件撐爆元數(shù)據(jù)”的說法有非常直觀的體會(huì)。4.2 Java API 開發(fā)寫文件、讀文件與目錄操作雖然大部分離線任務(wù)都會(huì)用 Hive 或 Spark 替代手寫 Java API但理解和掌握底層 API 依然很重要。HDFS 的 Java API 核心類是FileSystem獲取文件系統(tǒng)實(shí)例的推薦方式是Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://namenode-host:9820); FileSystem fs FileSystem.get(conf);寫文件的經(jīng)典流程Path path new Path(/data/demo.txt); FSDataOutputStream out fs.create(path); out.write(hello hdfs.getBytes(UTF-8)); out.close();注意fs.create()返回的FSDataOutputStream是帶緩沖的寫完數(shù)據(jù)后要么調(diào)用close()要么調(diào)用hflush()否則數(shù)據(jù)可能還留在客戶端緩沖區(qū)服務(wù)端感知不到。與本地文件寫入不同HDFS 的close()會(huì)觸發(fā)一次完整的寫入鏈路結(jié)束流程因此不要在一個(gè)循環(huán)里反復(fù)打開關(guān)閉流性能會(huì)很差。讀文件的經(jīng)典流程Path path new Path(/data/demo.txt); FSDataInputStream in fs.open(path); BufferedReader reader new BufferedReader(new InputStreamReader(in)); String line; while ((line reader.readLine()) ! null) { System.out.println(line); } reader.close();FSDataInputStream最重要的特性是支持seek()隨機(jī)定位。很多分布式計(jì)算框架正是利用這一點(diǎn)讓多個(gè)計(jì)算任務(wù)并行讀取同一個(gè)大文件的不同區(qū)間互不干擾。這也是 HDFS 能夠支持 MapReduce、Spark 這類框架進(jìn)行數(shù)據(jù)本地性讀取的基礎(chǔ)能力。目錄操作和刪除操作fs.mkdirs(new Path(/data/2025/01)); fs.delete(new Path(/data/tmp), true);第二個(gè)參數(shù)true表示遞歸刪除。如果你的代碼里刪錯(cuò)了目錄且沒有啟用回收站那數(shù)據(jù)就真的沒了。4.3 權(quán)限模型超級(jí)用戶、組與權(quán)限位的協(xié)作方式HDFS 的權(quán)限模型與 POSIX 類似但有兩點(diǎn)不同需要特別留意。第一HDFS 默認(rèn)不校驗(yàn)客戶端主機(jī)的真實(shí)身份只要你偽造成超級(jí)用戶hdfs就能繞過大部分權(quán)限檢查。所以生產(chǎn)環(huán)境必須開啟dfs.permissions.enabledtrue并且最好結(jié)合 Kerberos 做身份認(rèn)證否則權(quán)限體系形同虛設(shè)。第二HDFS 的 sticky bit 作用在目錄上時(shí)只有目錄 owner 才能刪除目錄中的文件多用戶共用的臨時(shí)目錄默認(rèn)就設(shè)置了這個(gè)位。權(quán)限排查是日常技術(shù)支持中非常常見的場(chǎng)景用戶報(bào)“寫入失敗”先看目錄權(quán)限再查 owner 和 group最后確認(rèn)是否啟用了 ACL 擴(kuò)展。HDFS 支持在傳統(tǒng) POSIX 權(quán)限基礎(chǔ)上增加 ACL命令是hdfs dfs -setfacl在處理多租戶共享目錄時(shí)非常有用。5. 讀寫鏈路全追蹤從客戶端請(qǐng)求到數(shù)據(jù)落盤的完整過程5.1 寫文件流程流水線復(fù)制與確認(rèn)機(jī)制HDFS 寫入流程值得反復(fù)琢磨因?yàn)樗w現(xiàn)了很多分布式系統(tǒng)設(shè)計(jì)上的巧思。整體順序大致如下客戶端調(diào)用create()向 NameNode 發(fā)出創(chuàng)建文件請(qǐng)求。NameNode 檢查文件是否已存在、父目錄是否存在、客戶端是否有權(quán)限。校驗(yàn)通過后在內(nèi)存中創(chuàng)建文件元數(shù)據(jù)并返回一個(gè)輸出流給客戶端?？蛻舳碎_始寫入數(shù)據(jù)時(shí)把數(shù)據(jù)切分成一個(gè)個(gè)數(shù)據(jù)包默認(rèn) 64 KB放入本地緩沖區(qū)。當(dāng)前緩沖區(qū)累計(jì)到一定大小后客戶端向 NameNode 發(fā)起申請(qǐng)請(qǐng)求返回“為下一個(gè) block 分配一組 DataNode”。NameNode 按照副本放置策略返回一組 DataNode 列表例如[DN1, DN2, DN3]。客戶端與 DN1 建立連接DN1 再與 DN2 建立連接DN2 再與 DN3 建立連接形成一個(gè)復(fù)制管道。客戶端按順序把數(shù)據(jù)包推給 DN1DN1 邊落盤邊把數(shù)據(jù)包轉(zhuǎn)發(fā)給 DN2DN2 再轉(zhuǎn)發(fā)給 DN3。每個(gè)數(shù)據(jù)包寫入成功后會(huì)沿著管道反向回傳確認(rèn)包?？蛻舳耸盏剿懈北镜拇_認(rèn)后才認(rèn)為這個(gè)數(shù)據(jù)包寫成功并繼續(xù)發(fā)送下一個(gè)數(shù)據(jù)包。一個(gè) block 寫完客戶端再向 NameNode 申請(qǐng)下一組 DataNode重復(fù)上述過程。所有 block 寫完后客戶端調(diào)用close()NameNode 將文件標(biāo)記為“已關(guān)閉”狀態(tài)寫入完成。整個(gè)鏈路的精髓在于“流水線復(fù)制”數(shù)據(jù)不是由客戶端分別復(fù)制三分再逐臺(tái)發(fā)送而是邊寫邊轉(zhuǎn)發(fā)大大減少了網(wǎng)絡(luò)傳輸量和單點(diǎn)壓力。也正因?yàn)槿绱薍DFS 適合大塊順序?qū)懸驗(yàn)樾K隨機(jī)寫的網(wǎng)絡(luò)交互成本實(shí)在太高。5.2 讀文件流程元數(shù)據(jù)定位與就近讀取讀文件流程比寫文件簡(jiǎn)單但同樣很講究客戶端調(diào)用open()向 NameNode 請(qǐng)求文件信息。NameNode 返回文件的每個(gè) block 對(duì)應(yīng)的 DataNode 列表比如“block A 在 DN1/DN2/DN3block B 在 DN3/DN4/DN5”?？蛻舳藢?duì) DataNode 列表做排序優(yōu)先選擇與客戶端同機(jī)架的節(jié)點(diǎn)其次選擇同機(jī)房的節(jié)點(diǎn)。這個(gè)排序邏輯由網(wǎng)絡(luò)拓?fù)涓兄獩Q定。客戶端與最優(yōu)先的 DataNode 建立連接按塊讀取數(shù)據(jù)。讀取過程中如果某個(gè) DataNode 讀取失敗客戶端自動(dòng)切換至下一個(gè)副本并向 NameNode 報(bào)告該 DataNode 異常。讀取性能的關(guān)鍵在于“數(shù)據(jù)本地性”。如果你的計(jì)算框架在 DN1 機(jī)器上跑 Container而 Client 去 DN3 上讀 block A 的副本雖然功能上沒問題但網(wǎng)絡(luò)傳輸開銷成倍增加。日常做數(shù)據(jù)傾斜排查、跑批任務(wù)性能分析時(shí)一定要關(guān)注輸入數(shù)據(jù)的本地命中率。5.3 追加寫與截?cái)郒DFS 的寫操作邊界HDFS 的append操作只允許在文件末尾追加數(shù)據(jù)不能修改已存在的中間內(nèi)容。如果業(yè)務(wù)確實(shí)需要修改既有數(shù)據(jù)常規(guī)做法是讀出來變換后再寫一個(gè)新文件或者用 Hive 的分區(qū)覆蓋策略。另外一個(gè)非常隱蔽又重要的操作是truncate——它能把文件截?cái)嗟街付ㄩL(zhǎng)度但有一個(gè)前提條件截?cái)嗪蟮拈L(zhǎng)度必須正好落在某個(gè) block 的邊界上否則 HDFS 會(huì)拒絕執(zhí)行。換句話說它做的是“整塊級(jí)截?cái)唷辈皇亲止?jié)級(jí)操作這點(diǎn)和本地文件系統(tǒng)的語義有明顯差異。6. 高可用與容錯(cuò)副本策略、故障轉(zhuǎn)移和一致性保證6.1 副本放置策略的高級(jí)配置與數(shù)據(jù)均衡問題前文提過默認(rèn)的三副本放置策略但在生產(chǎn)環(huán)境中不同業(yè)務(wù)場(chǎng)景對(duì)副本策略的需求差異很大冷數(shù)據(jù)存儲(chǔ)如歷史歸檔日志可以用 1 副本甚至結(jié)合糾刪碼EC策略來節(jié)省存儲(chǔ)成本。核心業(yè)務(wù)數(shù)據(jù)如訂單明細(xì)、財(cái)務(wù)數(shù)據(jù)可以設(shè)置 3 副本或 5 副本并且把機(jī)架感知能力用足保證跨冗余電源域也有副本。臨時(shí)中間結(jié)果副本設(shè) 1 即可磁盤空間能省則省。副本因子調(diào)整的命令hdfs dfs -setrep -R 2 /data/history但要注意setrep只是修改了文件的配置副本數(shù)實(shí)際補(bǔ)齊副本的過程由后臺(tái)線程異步完成不會(huì)立刻生效。調(diào)整完可以觀察hdfs fsck /data/history -files -blocks的輸出確認(rèn)副本數(shù)量逐步穩(wěn)定到目標(biāo)值。數(shù)據(jù)均衡是另一個(gè)必須主動(dòng)關(guān)注的點(diǎn)。擴(kuò)容新節(jié)點(diǎn)后新節(jié)點(diǎn)磁盤空間可能是 0而老節(jié)點(diǎn)已經(jīng)用了 80%。執(zhí)行均衡命令hdfs balancer -threshold 5該命令會(huì)把數(shù)據(jù)塊從高負(fù)載節(jié)點(diǎn)遷移到低負(fù)載節(jié)點(diǎn)直到集群中每個(gè)節(jié)點(diǎn)的磁盤使用率差異小于5%。balancer會(huì)在后臺(tái)慢慢跑通過設(shè)置dfs.datanode.balance.bandwidthPerSec限制帶寬建議從 20 MB/s 起步別把線上集群的網(wǎng)絡(luò)帶寬占滿影響業(yè)務(wù)。6.2 NameNode 故障與 HA從單點(diǎn)到雙活的技術(shù)演進(jìn)HDFS 早期最被詬病的就是 NameNode 單點(diǎn)故障。在支持 HA 之前NameNode 進(jìn)程掛了整個(gè) HDFS 就不可寫了恢復(fù)要等元數(shù)據(jù)鏡像和日志重新加載時(shí)間長(zhǎng)則十幾分鐘甚至更久。HA 機(jī)制的引入改變了這一局面。HA 的核心是引入兩個(gè) NameNode一個(gè)是 Active 節(jié)點(diǎn)一個(gè)是 Standby 節(jié)點(diǎn)Active NameNode 對(duì)外提供服務(wù)處理所有元數(shù)據(jù)操作。Standby NameNode 持續(xù)從 JournalNodes一般三臺(tái)讀取編輯日志并應(yīng)用到自身內(nèi)存實(shí)現(xiàn)元數(shù)據(jù)實(shí)時(shí)同步。Active 和 Standby 之間通過zkfcZooKeeper FailoverController進(jìn)行健康監(jiān)測(cè)和自動(dòng)切換。當(dāng) Active NameNode 進(jìn)程異常時(shí)ZooKeeper 感知到自動(dòng)觸發(fā)故障轉(zhuǎn)移把 Standby 提升為 Active。過程中客戶端會(huì)短暫感知到連接失敗但整體可用性從“無限期宕機(jī)”提升到了秒級(jí)恢復(fù)。在配置 HA 時(shí)有一個(gè)特別容易踩坑的地方兩個(gè) NameNode 的 namespace ID 必須保持一致否則 DataNode 會(huì)向兩個(gè) NameNode 都發(fā)起注冊(cè)導(dǎo)致腦裂。HA 的正確初始化流程一般是先格式化其中一個(gè) NameNode再通過hdfs namenode -bootstrapStandby同步另一個(gè)節(jié)點(diǎn)。這個(gè)操作順序如果沒有嚴(yán)格按照官方文檔執(zhí)行后面很容易出現(xiàn)“Active 和 Standby 同時(shí)有元數(shù)據(jù)”的混亂局面。6.3 租約機(jī)制寫文件的并發(fā)保護(hù)HDFS 是單寫者模型一個(gè)文件同一時(shí)刻只允許一個(gè)客戶端寫入。這是通過租約機(jī)制實(shí)現(xiàn)的客戶端寫文件時(shí)需要持有一個(gè)租約租約有過期時(shí)間。如果某個(gè)客戶端寫入過程中宕機(jī)或失聯(lián)租約不會(huì)自動(dòng)釋放需要等待租約過期后下一個(gè)客戶端才能重新接管寫權(quán)限。租約恢復(fù)的操作由 NameNode 的后臺(tái)線程執(zhí)行默認(rèn)租約軟超時(shí)是 60 秒硬超時(shí) 60 秒之后即可由其他客戶端強(qiáng)制恢復(fù)。在這個(gè)機(jī)制下最常見的坑是客戶端發(fā)起了create()但一直不寫數(shù)據(jù)或者寫入很少數(shù)據(jù)后保持連接不關(guān)閉導(dǎo)致租約一直續(xù)期其他程序無法往同一個(gè)文件寫數(shù)據(jù)。遇到這種問題排查思路是hdfs debug recovery lease -path file -retries 3去查看和修復(fù)租約。但在執(zhí)行修復(fù)前一定要確認(rèn)原寫入端真的已經(jīng)退出否則可能出現(xiàn)兩邊同時(shí)搶寫導(dǎo)致數(shù)據(jù)錯(cuò)亂。7. 我在 HDFS 實(shí)戰(zhàn)中反復(fù)踩過的坑與調(diào)優(yōu)心得7.1 小文件問題元數(shù)據(jù)壓垮 NameNode 的隱形殺手這是 HDFS 使用中遇到最多、影響也最大的問題。大量小文件意味著大量元數(shù)據(jù)對(duì)象NameNode 內(nèi)存很快就撐不住。更致命的是計(jì)算引擎處理時(shí)每個(gè)小文件都要啟動(dòng)一個(gè) Map 任務(wù)任務(wù)調(diào)度開銷比數(shù)據(jù)處理本身還大。我處理過的最極端案例中一個(gè) 3 TB 的數(shù)據(jù)目錄里存了 260 萬個(gè)小文件平均每個(gè)文件 1.2 MB。業(yè)務(wù)跑一個(gè) Spark 任務(wù)光打開文件列表就花了將近 20 分鐘。解決思路有三種合并小文件定期把目錄下的小文件讀出來按業(yè)務(wù)維度合并成 128 MB 級(jí)別的大文件。合并后文件數(shù)可能降到原來的萬分之一查詢性能提升數(shù)個(gè)量級(jí)。使用 Hive 的歸檔功能ARCHIVE對(duì)小文件做 HAR 打包Hive 讀的時(shí)候按目錄訪問而不是按文件訪問能有效減少 NameNode 壓力?？刂圃搭^上傳粒度寫入端盡量做批量緩沖攢夠一個(gè) block 大小再落盤。很多 Flume 或 Kafka Producer 的上游任務(wù)就是因?yàn)?Flush 閾值設(shè)置太激進(jìn)而制造出海量小文件。HDFS 3.x 之后引入了基于 Erasure Coding糾刪碼的存儲(chǔ)策略可以大幅降低副本冗余成本比如用 RS-6-3 策略把 6 個(gè)數(shù)據(jù)塊加 3 個(gè)校驗(yàn)塊組織成一組存儲(chǔ)開銷只有 1.5 倍比 3 副本的 3 倍節(jié)約一半空間。但 EC 策略不適合隨機(jī)讀寫場(chǎng)景主要用于冷數(shù)據(jù)歸檔。如果你在做存儲(chǔ)成本優(yōu)化EC 絕對(duì)值得好好研究。7.2 心跳參數(shù)與故障感知速度的矛盾生產(chǎn)環(huán)境中管理期望“機(jī)器掛了馬上能感知”但網(wǎng)絡(luò)閃斷和進(jìn)程假死是常態(tài)。把心跳間隔從 3 秒改到 1 秒確實(shí)能更快感知故障但會(huì)讓 DataNode 和 NameNode 之間產(chǎn)生大量心跳請(qǐng)求浪費(fèi)資源甚至可能引發(fā) NameNode RPC 隊(duì)列堆積。我的調(diào)優(yōu)經(jīng)驗(yàn)是不要為了“更快”盲目調(diào)小心跳間隔而應(yīng)該優(yōu)先保證集群的穩(wěn)定性和元數(shù)據(jù)一致性。如果確實(shí)需要快速故障切換應(yīng)該依靠 HA 機(jī)制而不是單純壓縮心跳時(shí)間。正常情況下保持默認(rèn) 3 秒心跳配合 10 倍超時(shí)判斷已經(jīng)足夠應(yīng)對(duì)絕大多數(shù)場(chǎng)景。7.3 磁盤故障后的數(shù)據(jù)恢復(fù)流程DataNode 的磁盤壞掉是分布式存儲(chǔ)集群里最常見的事故。單塊盤掛了只是少了一份副本NameNode 會(huì)標(biāo)記該塊副本數(shù)不足然后自動(dòng)從其他地方復(fù)制補(bǔ)全。但如果同時(shí)壞掉兩塊盤且其中包含同一個(gè) block 的兩份副本那就真的會(huì)有數(shù)據(jù)丟失風(fēng)險(xiǎn)。處理磁盤故障的標(biāo)準(zhǔn)動(dòng)作是確認(rèn)壞盤路徑。使用hdfs dfsadmin -report查看 DataNode 狀態(tài)。在dfs.datanode.data.dir中把壞盤目錄摘除重啟該 DataNode。觀察 NameNode 界面的塊復(fù)制任務(wù)是否自動(dòng)啟動(dòng)。使用hdfs fsck path -files -blocks -locations檢查目標(biāo)目錄的健康狀態(tài)。這里面最容易犯的錯(cuò)誤是直接格式化壞盤所在的掛載點(diǎn)而忽略了目錄中可能還有其他正常磁盤的數(shù)據(jù)。如果你是多個(gè)目錄共享一塊物理盤掛掉一個(gè)目錄全沒了但不代表其他 DataNode 也沒有該 block 的副本所以千萬不要慌張重建集群讓 HDFS 自行復(fù)制恢復(fù)往往是最快最安全的方式。7.4 千萬慎用rm -rf與數(shù)據(jù)回收站運(yùn)維 HDFS 期間團(tuán)隊(duì)里發(fā)生過不止一次誤刪事故。HDFS 中的rm命令沒有本地文件系統(tǒng)的二次確認(rèn)機(jī)制一條命令下去目錄就沒了。強(qiáng)烈建議把回收站功能打開property namefs.trash.interval/name value1440/value /property單位是分鐘1440 表示保留一天之后回收站文件才會(huì)被徹底刪除。誤刪之后可以通過如下命令恢復(fù)hdfs dfs -mv /user/hdfs/.Trash/Current/data/important /data/important注意回收站的路徑通常是/user/當(dāng)前用戶/.Trash/Current/不同用戶有各自的回收站目錄恢復(fù)前先確認(rèn)文件在不在。回收站確實(shí)會(huì)占用一部分存儲(chǔ)但相比誤刪后的災(zāi)難性損失這點(diǎn)成本很值得。7.5 運(yùn)維監(jiān)控的“保命”指標(biāo)HDFS 日常運(yùn)維下面幾個(gè)指標(biāo)我會(huì)每天盯NameNode 堆內(nèi)存使用率超過 80% 就要認(rèn)真排查了考慮擴(kuò)容內(nèi)存或合并小文件。DataNode 磁盤使用率超過 85% 的節(jié)點(diǎn)要盡快處理數(shù)據(jù)均衡任務(wù)及時(shí)執(zhí)行。Under-replicated blocks 數(shù)量如果長(zhǎng)期不為 0說明有節(jié)點(diǎn)故障沒恢復(fù)或被防火墻隔離了。DataNode 心跳延遲延遲持續(xù)升高通常是網(wǎng)絡(luò)問題或 NameNode 內(nèi)存 GC 停頓導(dǎo)致。RPC 隊(duì)列等待時(shí)間NameNode 界面能直接看到排隊(duì)時(shí)間變長(zhǎng)說明元數(shù)據(jù)操作量已經(jīng)逼近單機(jī)處理上限。除了 Hadoop 自帶的 NameNode Web 界面可以再配一套監(jiān)控采集把上述指標(biāo)納入告警策略比等用戶報(bào)故障再排查要省心太多。8. 寫在最后HDFS 仍然值得從底層去學(xué)最后說點(diǎn)個(gè)人體會(huì)。很多人覺得 HDFS 已經(jīng)是“老技術(shù)”現(xiàn)在大家都在玩對(duì)象存儲(chǔ)、云原生存儲(chǔ)、數(shù)據(jù)湖沒必要深究底層。但我在實(shí)際工作中發(fā)現(xiàn)真正把 HDFS 吃透的人再去理解對(duì)象存儲(chǔ)的分區(qū)策略、計(jì)算存儲(chǔ)分離架構(gòu)、數(shù)據(jù)本地性調(diào)度、副本一致性協(xié)議都會(huì)非常順暢。分布式存儲(chǔ)解決的核心命題無非就是“數(shù)據(jù)怎么可靠地放、高效地取、方便地管”HDFS 恰好是這幾件事最經(jīng)典的實(shí)現(xiàn)樣本。如果你正要開始學(xué)我給的建議很樸素不要只看理論文檔一定自己動(dòng)手起一個(gè)三節(jié)點(diǎn)集群把文件傳上去用hdfs fsck看塊分布kill 掉一個(gè) DataNode 看副本補(bǔ)全再手動(dòng)修改一個(gè)文件的副本因子做完這一輪你對(duì) HDFS 的理解會(huì)超過很多人。HDFS 很龐大但它的骨架并不復(fù)雜。理解 NameNode 管元數(shù)據(jù)、DataNode 管塊存儲(chǔ)、副本機(jī)制保證可靠性、流水線復(fù)制保證性能剩下的再慢慢細(xì)節(jié)化你會(huì)發(fā)現(xiàn)一條特別清晰的學(xué)習(xí)路線。希望這篇基于“Hadoop HDFS-分布式存儲(chǔ)系統(tǒng)入門、配置、使用及架構(gòu)原理分析”的完整拆解能讓你少走一些我走過的彎路。