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