簡介一份面向計算機科學與技術(shù)、軟件工程等專業(yè)本科畢業(yè)生的Hadoop方向?qū)W士學位論文圍繞氣象數(shù)據(jù)的分布式存儲展開研究。論文從Hadoop架構(gòu)入手系統(tǒng)講解HDFS分布式文件系統(tǒng)與MapReduce計算模型并結(jié)合氣溫、濕度、風速等多源氣象數(shù)據(jù)的特點設(shè)計基于Hadoop的存儲系統(tǒng)完整覆蓋系統(tǒng)架構(gòu)、數(shù)據(jù)分布策略、功能實現(xiàn)與性能評估。全文按緒論、Hadoop技術(shù)概述、氣象數(shù)據(jù)存儲技術(shù)研究、基于Hadoop的存儲系統(tǒng)設(shè)計、功能實現(xiàn)與性能評估、總結(jié)與展望六章展開還包含國內(nèi)外研究現(xiàn)狀綜述以及數(shù)據(jù)安全、資源管理等實踐問題可作為畢業(yè)論文參考、畢業(yè)設(shè)計擴展或大數(shù)據(jù)入門學習資料。論文為原創(chuàng)撰寫未入常見論文庫可通過查重系統(tǒng)。資源包為1個docx文檔壓縮后約31KB已有288人學習下載。1. 用Hadoop扛氣象數(shù)據(jù)先想清楚這四件事氣象數(shù)據(jù)是最典型的“海量小文件少量大文件”混合體一個國家級氣象站每分鐘生成的觀測報文本只有幾KB一部天氣雷達一小時產(chǎn)生的基數(shù)據(jù)卻有幾百MB而數(shù)值模式跑一次輸出的格點場動輒幾十TB。傳統(tǒng)的NFS集中存儲擴不動、查不快于是很多人把目光轉(zhuǎn)向基于Hadoop的分布式存儲技術(shù)。但反直覺的是直接把幾百萬個小文件扔進HDFS撐死你的往往不是磁盤而是NameNode的內(nèi)存——一個文件元數(shù)據(jù)就要占150字節(jié)左右千萬個文件就是幾個GB的堆空間。這篇筆記就圍繞這個矛盾展開從氣象數(shù)據(jù)為什么要走Hadoop到偽分布式、HA集群的搭建路線再到小文件合并、跨集群遷移和各類翻車現(xiàn)場的排查方法最后給你一份驗證思路和成本測算。適合氣象業(yè)務(wù)運維、數(shù)據(jù)工程崗和做hadoop課程設(shè)計或研究課題的人新手能跟著敲命令熟手直接看邊界參數(shù)。2. 為什么氣象數(shù)據(jù)必須走分布式存儲從文件體積到計算模式的硬約束2.1 氣象數(shù)據(jù)的三種典型規(guī)模和訪問特征氣象數(shù)據(jù)不是一個均勻的隊列至少可以分成三類。第一類是地面自動站觀測數(shù)據(jù)全國幾萬個站點逐分鐘上報單個文件只有幾KB到幾十KB。這類數(shù)據(jù)的特征是“海量、極小、持續(xù)追加”一天下來可能積累上千萬個文件。它最棘手的問題不是容量而是元數(shù)據(jù)數(shù)量——HDFS里每個文件都對應(yīng)一串NameNode內(nèi)存中的樹節(jié)點當文件數(shù)突破百萬一次啟動fsimage加載就會明顯變慢更不用說日常的目錄操作。第二種是氣象雷達基數(shù)據(jù)一個體掃文件大約幾十MB到幾百MB一天一部雷達能產(chǎn)生幾個GB全國組網(wǎng)就是TB級。它的訪問特征是按站點和時刻隨機讀取適合按站點分目錄存儲單個文件又達不到HDFS塊大小需要適度合并。第三種是數(shù)值模式輸出的格點場全球模式或區(qū)域模式一次run的產(chǎn)物從幾十GB到幾十TB文件通常是大文件且后續(xù)要做多維切片和統(tǒng)計分析。它們的共同點是“寫一次、讀多次、極少原地修改”這恰好是HDFS的舒適區(qū)。但不同規(guī)模對塊大小、壓縮格式和副本策略的要求完全不同所以存儲方案必須分層設(shè)計。我一般先把數(shù)據(jù)按來源與訪問模式分類再決定是直接落HDFS、走SequenceFile合并還是轉(zhuǎn)成ORC列式存儲。2.2 HDFS為什么比傳統(tǒng)NAS和對象存儲更適合氣象數(shù)據(jù)不少人問NAS也能擴對象存儲也能存為什么非得用Hadoop這里要從訪問模式說起。傳統(tǒng)NAS通過NFS/CIFS掛載適合小規(guī)模共享但元數(shù)據(jù)服務(wù)是中心化的單點文件數(shù)超過百萬后ls都會卡頓橫向擴展要么換代要么加昂貴的專用網(wǎng)關(guān)。對象存儲比如MinIO、CEPH RGW在容量和帶寬上很強但List操作延遲高、對大數(shù)據(jù)計算框架的本地方支持弱Spark/Hive讀對象存儲往往要走S3A協(xié)議每次讀都要做HTTP握手。放在氣象業(yè)務(wù)的真實場景里我們經(jīng)常要用MapReduce或Spark直接掃描一個時段的全部觀測文件做質(zhì)控這時候數(shù)據(jù)本地性Data Locality很關(guān)鍵。HDFS把數(shù)據(jù)切塊分散在各節(jié)點計算任務(wù)能優(yōu)先調(diào)度到持有數(shù)據(jù)塊的節(jié)點減少網(wǎng)絡(luò)傳輸。這種“存儲與計算同池”的架構(gòu)讓歷史氣象數(shù)據(jù)回算、批量重處理這類任務(wù)的效率比其他方案高一個量級。另一層是可靠性三副本機制或者機架感知下的雙副本跨機架副本能夠容忍節(jié)點故障對長年累積的氣象歷史數(shù)據(jù)來說硬件損壞是必然的數(shù)據(jù)恢復(fù)能力比鏡像備份更省心。當然HDFS不支持原地修改文件如果你要頻繁更新某個時次的觀測值就得走Overwrite重寫整個文件這是選型時就要接受的限制。為了幫你決策這張表是我常用的對比維度維度傳統(tǒng)NAS對象存儲HDFS文件數(shù)上限百萬級后明顯卡頓支持多但List延遲高千萬級需優(yōu)化元數(shù)據(jù)內(nèi)存追加寫支持支持只支持塊內(nèi)追加整體重寫數(shù)據(jù)本地性無弱強隨機讀小文件快一般慢需合并與Spark/Hive集成需掛載通過S3A有開銷原生結(jié)論是如果你的氣象數(shù)據(jù)處理鏈路里只有“存起來、偶爾下載”對象存儲夠用一旦要做批量計算和在線分析基于Hadoop的方案更劃算。這個判斷也符合當前大數(shù)據(jù)平臺的主流選擇。2.3 存儲格式取舍HDFS塊大小、壓縮、列式存儲確定了用HDFS下一步是定塊大小和文件格式。HDFS默認塊大小在舊版本是64MB新版本一般默認128MB但氣象數(shù)據(jù)要具體調(diào)。雷達基數(shù)據(jù)單文件幾百MB塊設(shè)成64MB會讓一個文件拆成多個塊讀取時要跨多個DataNode如果設(shè)成256MB單體掃描更連續(xù)但也會減少集群內(nèi)并行度。我一般遵循一個原則塊大小取“文件平均大小的1~2倍”并且不少于128MB。地面站小文件不能靠調(diào)塊解決必須走合并后面第4章會展開。格式上原始觀測報文直接用Text文件存方便氣象業(yè)務(wù)軟件對接但分析場景要轉(zhuǎn)成列式格式。ORC或Parquet對浮點格點場的壓縮比很驚人一個10GB的模式輸出按4字節(jié)浮點存成二進制可能是2.5GB用ORC加zlib壓縮后還能再壓到1GB以下。壓縮格式選擇上生產(chǎn)環(huán)境我推薦LZ4或Snappy壓縮速率高解壓帶寬大zstd壓縮比更高但CPU開銷也更大。簡單說數(shù)據(jù)沉淀后需要反復(fù)查詢的轉(zhuǎn)ORC/Gzip只是中間結(jié)果或臨時數(shù)據(jù)保留Snappy甚至不壓縮。氣象數(shù)據(jù)還有一個特點時間維度天然有序按小時或日期分區(qū)能帶來顯著的裁剪效果。比如查詢“2024年5月1日強對流個例的雷達數(shù)據(jù)”分區(qū)裁剪能把掃描范圍從全庫縮到一個目錄。所以存儲格式設(shè)計不是孤立的文件格式問題而是“目錄規(guī)劃文件合并列式轉(zhuǎn)換”的組合決策。3. 基于Hadoop的氣象數(shù)據(jù)存儲架構(gòu)從偽分布到HA集群的落地路徑3.1 偽分布式搭建用docker鏡像快速驗證存儲方案在正式買服務(wù)器之前先用一臺機器或一臺筆記本上的Docker容器跑通偽分布式是最快的驗證方式。網(wǎng)上常見的是hadoop偽分布式搭建教程通常步驟是裝JDK、關(guān)免密登錄、改四個xml但手動配環(huán)境容易翻車。我習慣直接拉一個現(xiàn)成的hadoop docker鏡像比如帶Hadoop 3.x的鏡像用容器起NameNode和DataNode。下面是一組最小命令我用CentOS系統(tǒng)演示但macOS也一樣# 拉取包含 Hadoop 3.3.4 的 Docker 鏡像這里以 bde2020 的鏡像為例 docker pull bde2020/hadoop-base:latest # 用 docker-compose 啟動一個簡單的集群包含 namenode 和 datanode cat docker-compose.yml EOF version: 3 services: namenode: image: bde2020/hadoop-base:latest container_name: namenode environment: - CORE_CONF_fs_defaultFShdfs://namenode:9000 - HDFS_CONF_dfs_namenode_name_dirfile:///hadoop/dfs/name ports: - 9870:9870 volumes: - ./data:/data command: [hdfs, namenode] datanode: image: bde2020/hadoop-base:latest container_name: datanode environment: - CORE_CONF_fs_defaultFShdfs://namenode:9000 depends_on: - namenode volumes: - ./data/datanode:/hadoop/dfs/data command: [hdfs, datanode] EOF docker-compose up -d這段命令里CORE_CONF_fs_defaultFS 指定了默認文件系統(tǒng)的地址偽分布式下所有進程都連這一個NameNode。掛載./data到容器是讓容器退出后數(shù)據(jù)不丟這一步很關(guān)鍵很多新手臨時起容器關(guān)掉就一切歸零。啟動成功后打開 http://localhost:9870 就能看到NameNode的Web界面Datanode列表里會出現(xiàn)一個節(jié)點。然后隨便傳一個文件測試# 進入容器執(zhí)行 hdfs 命令 docker exec -it namenode bash hdfs dfs -mkdir -p /weather/obs/2024/05 hdfs dfs -put /data/sample_obs.txt /weather/obs/2024/05/ hdfs dfs -ls /weather/obs/2024/05這種方式的優(yōu)點是不污染宿主機JDK、Hadoop環(huán)境全在鏡像里。缺點是偽分布式只有單機測不了機架感知、故障恢復(fù)這些集群行為。如果你做的是hadoop安裝與配置相關(guān)的課程設(shè)計或技術(shù)驗證偽分布式足夠看到HDFS的完整讀寫流程如果要測HA或擴容就得跳到3.2節(jié)的多節(jié)點搭建。另外提醒一句docker鏡像版本魚龍混雜bde2020這個系列我看到還在維護但建議你拉鏡像后先docker inspect看HADOOP_VERSION環(huán)境變量確認是3.x再往下走。3.2 多節(jié)點集群搭建NameNode/DataNode/JournalNode部署要點真實氣象業(yè)務(wù)至少需要三臺以上物理機或云主機。常見做法是部署一個雙NameNode的HA集群配合3個JournalNode、3個ZooKeeper節(jié)點和一組DataNode。下面是我的推薦角色分配以5臺機器為例節(jié)點角色node1NameNode(Active)、ZKFC、JournalNodenode2NameNode(Standby)、ZKFC、JournalNodenode3JournalNode、ResourceManager、DataNodenode4DataNode、NodeManagernode5DataNode、NodeManager搭建前要做的準備所有節(jié)點互信ssh-copy-id、安裝JDK8或JDK11、把Hadoop安裝包解壓到一致路徑。接下來最核心的是四個配置文件的修改。先說core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configuration這邊f(xié)s.defaultFS不再寫成具體namenode地址而是寫成邏輯名mycluster由HA服務(wù)去解析當前Active節(jié)點。ha.zookeeper.quorum是ZooKeeper連接串用于選舉。然后hdfs-site.xml里要寫nameservice、NameNode的RPC地址、故障切換方式configuration property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property /configuration這里最關(guān)鍵的是dfs.namenode.shared.edits.dir它要求所有NameNode把編輯日志寫到同一組JournalNode上兩個NameNode通過讀取共享日志保持元數(shù)據(jù)同步。自動故障轉(zhuǎn)移要靠ZooKeeper所以必須配合3.3節(jié)的ZooKeeper配置。改完配置后不要急著啟動所有節(jié)點要按順序先啟動ZooKeeper集群再在node1上執(zhí)行hdfs namenode -format然后在node2上執(zhí)行hdfs namenode -bootstrapStandby把元數(shù)據(jù)同步過來最后用hdfs haadmin -transitionToActive強制切換一次。這一步容易踩坑后面第5章會展開。3.3 Hadoop與Zookeeper整合實戰(zhàn)HA高可用的選主與腦裂規(guī)避Hadoop HA能實現(xiàn)NameNode自動切換底層實際上是ZooKeeper在扛選主。每個NameNode旁邊跑一個ZK Failover ControllerZKFC守護進程它負責向ZooKeeper登記自己為候選節(jié)點并監(jiān)控NameNode的健康狀態(tài)。當Active的ZKFC發(fā)現(xiàn)心跳中斷就自動把Active狀態(tài)讓給Standby。這個過程就是hadoop和zookeeper整合實戰(zhàn)中最核心的機制。ZooKeeper的安裝不需要多講只要保證3個節(jié)點版本一致。需要注意的是ZooKeeper的myid文件必須唯一conf/zoo.cfg里dataDir要指向有空間的目錄并加上server.1node1:2888:3888這樣的配置。Hadoop這邊需要把ZooKeeper客戶端相關(guān)JAR放到Hadoop的lib下多數(shù)發(fā)行版已自帶。然后啟動順序有講究# 在三臺ZK節(jié)點上分別啟動 ZooKeeper zkServer.sh start # 在所有Hadoop節(jié)點啟動HDFS start-dfs.sh # 在node1上檢查HA狀態(tài) hdfs haadmin -getAllServiceState # 期望輸出 # node1:8020 active # node2:8020 standby我在實際部署中遇到最多的問題是ZooKeeper起來了但HDFS的HA沒有生效NameNode兩側(cè)都顯示standby。原因通常是ZooKeeper會話超時配置太長或者防火墻沒放開2181、2888端口。建議把dfs.ha.zookeeper.quorum里的地址換成完整主機名并檢查hosts文件避免不同節(jié)點解析不一致。另一個坑是腦裂在網(wǎng)絡(luò)分區(qū)時兩個NameNode可能同時認為自己是Active。HDFS的解決方案是fencing隔離常見配置是shell指令把對方殺死或執(zhí)行ssh命令。在hdfs-site.xml里添加property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /propertysshfence會在切換前通過SSH連到舊Active節(jié)點上執(zhí)行fuser -k強制殺掉NameNode進程。如果SSH互信沒配置好fencing會失敗導(dǎo)致切換不成功這是我在面試時經(jīng)常用來梳理的細節(jié)也提醒你把互信配置到root和hadoop用戶兩層。4. 氣象數(shù)據(jù)入庫與訪問目錄設(shè)計、分區(qū)和文件生命周期4.1 目錄與文件命名規(guī)范按觀測時間和類型組織氣象數(shù)據(jù)一旦進入HDFS目錄結(jié)構(gòu)就是它的索引。我在設(shè)計目錄時堅持三條原則時間維度獨立層、數(shù)據(jù)類型獨立層、原始與派生分離。一個推薦的地面觀測目錄結(jié)構(gòu)如下/weather/obs/2024/05/01/station_54511_202405010000.txt /weather/radar/2024/05/01/station_Z9000_202405010000.mz /weather/model/global_2024050100/0000/height.grb /weather/derived/2024/05/01/vis_analysis.orc為什么不把時間放在數(shù)據(jù)站下面比如/weather/station_54511/2024/05/01因為絕大多數(shù)氣象查詢是“某個時間段、覆蓋很多站”“按時間分區(qū)”能讓Spark讀取目錄列表時直接剪掉無關(guān)時間片。文件命名要帶上站號和觀測時刻如station_54511_202405010000.txt這樣即使目錄結(jié)構(gòu)丟了文件名本身還能恢復(fù)元數(shù)據(jù)。原始目錄raw和派生目錄derived分開因為原始數(shù)據(jù)有氣象業(yè)務(wù)合同要求保留派生數(shù)據(jù)可以隨時重新生成兩者的生命周期和副本策略可以不同。分區(qū)粒度建議按天。粒度過細會導(dǎo)致目錄數(shù)量爆炸舉例全國5萬站一天一個文件按小時分區(qū)就比按天多24倍目錄NameNode的目錄樹負擔很大。只有雷達數(shù)據(jù)這種單文件大、時次少的可以按小時或按時次分目錄。一旦定了規(guī)范就需要用腳本強制約束我習慣在采集端就生成符合規(guī)范的路徑入庫代碼里不再做二次解析減少出錯。4.2 小文件合并與SequenceFile/ORC轉(zhuǎn)換大多數(shù)氣象觀測文件都是小文件如果把原始TXT直接put到HDFS對NameNode的壓力非常大。解決思路有幾個一是用Hadoop的CombineFileInputFormat讓計算框架在讀取時合并但這對存儲本身沒有幫助二是在入庫前把多個小文件合并成一個SequenceFile三是直接轉(zhuǎn)成ORC表。我這里提供一個用Spark批量轉(zhuǎn)換的思路適合把某一天成千上萬個站的地面觀測TXT合并成一個按天分區(qū)的ORC表// 用 Spark 讀取 /weather/obs/2024/05/01 下的所有 txt val inputPath /weather/obs/2024/05/01 val df spark.read .option(delimiter, ,) .option(header, false) .schema(new StructType() .add(station, StringType) .add(time, StringType) .add(temp, DoubleType) .add(pressure, DoubleType)) .csv(inputPath) // 寫入 ORC按站號分區(qū)snappy壓縮 df.write .mode(overwrite) .partitionBy(station) .option(compression, snappy) .orc(/weather/derived/2024/05/01)這段代碼里partitionBy(station) 會在ORC目錄下再建一層站號子目錄查詢單站數(shù)據(jù)時能快速定位。選擇ORC而不是Parquet是因為在Hive/Spark生態(tài)里ORC的ACID能力和浮點壓縮表現(xiàn)更穩(wěn)定。合并操作完成后原始txt文件是否刪除要視業(yè)務(wù)需要氣象歷史參考文件一般至少保留一年但可以移到成本更低的目錄比如通過設(shè)置副本數(shù)為2。如果你不想引入Spark也可以用Hadoop自帶的SequenceFile寫入器但維護一堆byte數(shù)組畢竟麻煩生產(chǎn)上我更愿意定義好Schema后直接上ORC。小文件合并這個動作不只是一次性的我通常會每天在數(shù)據(jù)接入后觸發(fā)一個定時合并任務(wù)比如用Oozie或Airflow調(diào)度避免數(shù)據(jù)文件持續(xù)積壓。4.3 distcp參數(shù)說明跨集群遷移與備份氣象數(shù)據(jù)存儲研究里跨集群復(fù)制是常見需求把生產(chǎn)集群的歷史數(shù)據(jù)同步到分析集群做實驗或者做異地災(zāi)備。Hadoop自帶的distcp是首選工具它本質(zhì)上是MapReduce作業(yè)在Map任務(wù)里并行拷貝文件。我最常用的命令是這樣# 把生產(chǎn)集群 /weather 目錄下 2024 年 5 月的數(shù)據(jù)同步到分析集群相同路徑 hadoop distcp -m 20 -b 2048 -p hdfs://prod:8020/weather/obs/2024/05 hdfs://analysis:8020/weather/obs/2024/05參數(shù)說明-m 20 表示最多開20個Map任務(wù)并行度過高會讓源集群NN壓力大建議根據(jù)源端DataNode數(shù)量設(shè)為節(jié)點數(shù)的1~2倍。-b 2048是帶寬限制單位MB適合在業(yè)務(wù)高峰期做限速避免網(wǎng)卡被打滿。-p保留屬性包括權(quán)限、塊大小、復(fù)制數(shù)等遷移氣象數(shù)據(jù)時建議保留否則目標端副本數(shù)會使用集群默認值。-diff參數(shù)可以增量同步我通常在第二次運行時加上--diff只復(fù)制源與目標不同的文件。distcp遇到小文件時Map任務(wù)還是會按文件粒度處理所以前面說的合并步驟對distcp同樣能減少任務(wù)數(shù)。還有一個坑distcp默認不會覆蓋目標端同名文件如果業(yè)務(wù)上需要覆蓋請加-overwrite參數(shù)。5. 常見問題與避坑排查氣象數(shù)據(jù)存儲翻車現(xiàn)場5.1 小文件導(dǎo)致NameNode內(nèi)存爆掉現(xiàn)象集群運行幾個月后NameNode的JVM堆內(nèi)存持續(xù)走高頻繁Full GC界面卡死甚至進入SafeMode。原因每個文件元數(shù)據(jù)在NameNode內(nèi)存里大約占150~220字節(jié)含目錄項、權(quán)限、塊信息一堆幾KB的觀測文件積累到千萬級別堆內(nèi)存幾個GB就被吃光了。這是“海量小文件分布式存儲”的經(jīng)典組合拳。解決先救命再治本。臨時調(diào)大NameNode堆內(nèi)存在hadoop-env.sh里設(shè)置HADOOP_NAMENODE_OPTS-Xmx8g并重啟。長期做法是執(zhí)行4.2的小文件合并把原始TXT按天轉(zhuǎn)成ORC同時清理無用的臨時文件hdfs fsck可用于統(tǒng)計小文件占比。日常監(jiān)控建議每半小時記錄一次NN堆內(nèi)存和活躍文件數(shù)閾值設(shè)置到80%時告警。5.2 塊大小設(shè)成64MB造成大量小塊現(xiàn)象一個雷達基數(shù)據(jù)文件300MB讀取時跨3個塊花的時間反而比單塊讀更長NameNode塊對象數(shù)量多fsck掃描慢。原因很多教程還是老版本的64MB默認值氣象大文件被無謂切碎。解決在hdfs-site.xml里設(shè)dfs.blocksize為268435456256MB或至少134217728128MB。修改后新寫入的文件會使用新塊大小歷史文件不會自動重切如果需要統(tǒng)一可以用distcp加-updated重寫一遍。我一般按數(shù)據(jù)類型分別配置比如雷達目錄用256MB觀測小文件合并后的ORC塊默認128MB即可。5.3 數(shù)據(jù)傾斜與機架感知配置現(xiàn)象某個新增DataNode磁盤利用率很快爆滿而其他節(jié)點空閑或者計算任務(wù)總是往少數(shù)節(jié)點上跑。原因HDFS數(shù)據(jù)均衡策略是隨機輪詢副本放置也沒有機架感知集群拓撲被當作單機架處理。解決配置機架感知腳本讓Hadoop知道網(wǎng)絡(luò)拓撲。在core-site.xml里設(shè)置property namenet.topology.script.file.name/name value/opt/hadoop/etc/hadoop/rack-aware.sh/value /property腳本內(nèi)容按IP映射到機架名例如#!/bin/bash # 簡單的機架感知腳本前兩個字節(jié)相同視為同一機架 case $1 in 192.168.1.*) echo /rack-1 ;; 192.168.2.*) echo /rack-2 ;; *) echo /rack-default ;; esac注意腳本要有可執(zhí)行權(quán)限。有了機架感知HDFS在第二個副本時會優(yōu)先放到不同機架第三個副本再回到第一個副本所在機架的不同節(jié)點這樣既容災(zāi)又均衡。如果已經(jīng)存在傾斜執(zhí)行hdfs balancer -threshold 10讓它均衡但要在業(yè)務(wù)低峰跑因為它會占用IO。5.4 副本策略在氣象場景下的調(diào)整現(xiàn)象默認3副本磁盤成本翻三倍氣象原始數(shù)據(jù)有壓縮歸檔卻沒地方放。原因很多人照搬默認配置沒想過氣象數(shù)據(jù)的副本需求其實可以從3降到2甚至1。解決氣象數(shù)據(jù)有重建途徑如雷達基數(shù)據(jù)可以從雷達站重新導(dǎo)模式數(shù)據(jù)可以重新run對原始觀測文件2副本已經(jīng)能容忍單節(jié)點故障如果有Hadoop Archive冷備份副本可降到1。設(shè)置方式在hdfs-site.xml里全局改dfs.replication2也可以對特定目錄設(shè)置hdfs dfs -setrep -R 2 /weather/raw這個命令會把指定目錄及已有文件的副本數(shù)改成2適合對不同數(shù)據(jù)類型做差異化成本控制。不過要提醒副本數(shù)設(shè)得太低在DataNode單點故障時會導(dǎo)致塊丟失需要用hdfs fsck -list-corruptfileblocks定期檢查。降副本前務(wù)必確認數(shù)據(jù)源還有原始文件否則一旦磁盤壞就是真翻車。5.5 磁盤故障與節(jié)點掉線后的恢復(fù)時序現(xiàn)象DataNode進程在但Web UI顯示某個塊副本缺失或者某塊磁盤IO錯誤節(jié)點被標記為壞盤最終Node進入Decommission狀態(tài)。原因DataNode多目錄中一個壞盤會導(dǎo)致整個節(jié)點被判斷為異常NameNode檢測到超時后啟動塊復(fù)制但因為副本少或網(wǎng)絡(luò)帶寬不夠恢復(fù)很慢。解決該節(jié)點的hdfs-site.xml里設(shè)置dfs.datanode.data.dir為多個獨立盤目錄例如/srv/hdfs/data1,/srv/hdfs/data2這樣單盤損壞只影響那部分塊不會整個節(jié)點宕掉。壞盤處理流程是發(fā)現(xiàn)壞盤 → 從配置中移除該目錄 → 修改fsimage并重啟DataNode → 等待塊的re-replicate。恢復(fù)期間可以用hdfs dfsadmin -report查看各節(jié)點磁盤狀態(tài)用hdfs fsck /weather -files -blocks檢查損壞文件列表。再一個常見坑很多人在DataNode內(nèi)存溢出或磁盤滿后不檢查就重啟導(dǎo)致節(jié)點反復(fù)異常。應(yīng)該先看日志/opt/hadoop/logs/hadoop-hdfs-datanode-*.log里的異常再動手。6. 這個方案值不值得投入驗證方法、成本估算與一個進階技巧6.1 用hadoop面試題清單給存儲方案做驗證做完這套架構(gòu)你可以用幾個hadoop面試題來驗收自己是否真正吃透請描述NameNode的啟動流程以及SecondaryNameNode與HA中的Standby節(jié)點有什么區(qū)別。副本放置策略的默認規(guī)則是什么機架感知改了之后會影響哪些行為小文件為什么影響HDFS除了合并還有哪些治理手段distcp在增量同步時如何保證數(shù)據(jù)一致性這些問題覆蓋了從原理到運維的邊界。如果你能不看文檔答上來說明你的氣象數(shù)據(jù)存儲方案不是搭個環(huán)境了事。我自己的習慣是每完成一個集群節(jié)點配置就在心里過一遍這些題用來發(fā)現(xiàn)盲區(qū)比如最初我以為Standby節(jié)點就是用來讀的實際上它的主要職責是熱備和及時切換。6.2 存儲成本與壓縮比實測方法在投入生產(chǎn)前建議先搞一個真實月份的樣本測試。選擇最近一個完整月的數(shù)據(jù)統(tǒng)計原始大小、文件個數(shù)。然后用下面的命令測量HDFS實際占用# 查看某個目錄的實際容量-h 顯示人類可讀 hdfs dfs -du -h /weather/raw/2024/05假設(shè)原始數(shù)據(jù)是2TBHDFS占用為2TB × 副本數(shù)2 4TB如果轉(zhuǎn)成ORC壓縮后體積變?yōu)?00GB那么有效存儲成本就變成4TB里實際只用了600GB的物理空間緊縮比約70%。再結(jié)合硬盤價格和服務(wù)器折舊就能算出每TB氣象數(shù)據(jù)成本。這里要注意du顯示的是邏輯塊大小不是物理磁盤寫入量因為塊校驗checksum也會占用一點點空間但通常忽略。還要算上NameNode內(nèi)存成本每100萬文件大約需要200MB堆內(nèi)存按云主機單價折算也是一筆賬。把這些算完你就可以給決策層交一份有數(shù)字的存儲預(yù)算方案。6.3 一個進階技巧基于文件大小的自動歸檔策略最后給你一個實用的冷熱分層技巧。氣象歷史數(shù)據(jù)訪問頻率越來越低但磁盤還在持續(xù)寫入?？梢杂肏adoop ArchiveHAR歸檔老數(shù)據(jù)將多個小文件打包成har文件減少NameNode元數(shù)據(jù)壓力同時不丟數(shù)據(jù)。建一個定時歸檔任務(wù)# 把 2023 年及以前的觀測原始文件歸檔成 har 包 hadoop archive -archiveName obs-2023.har -p /weather/obs/2023 /weather/archive/2023執(zhí)行后/weather/archive/2023下會出現(xiàn)一個obs-2023.har里面包含所有小文件。訪問歸檔文件時不用解壓可以直接hdfs dfs -ls har:///weather/archive/2023/obs-2023.har讀取。歸檔后原始目錄可以設(shè)置成只讀或清理你仍然能通過Spark讀har里的數(shù)據(jù)只是性能略低于未歸檔。這個技巧特別適合存量氣候數(shù)據(jù)能在一周內(nèi)存活集群的元數(shù)據(jù)壓力降一個量級。我的教訓(xùn)是歸檔腳本要放在業(yè)務(wù)低峰執(zhí)行并且先跑一次小范圍樣例驗證查詢端能正常讀har再全量歸檔因為HAR壓縮過程如果中途失敗部分小文件可能不可見需要原始目錄的副本兜底。這套基于Hadoop的氣象數(shù)據(jù)分布式存儲方案從架構(gòu)選型到集群搭建、數(shù)據(jù)入庫、成本測算我已經(jīng)講完了。如果你正在做氣象數(shù)據(jù)平臺建議先從偽分布式驗證目錄設(shè)計和合并流程再逐步擴展到HA集群。每個環(huán)節(jié)的數(shù)據(jù)格式、塊大小、副本策略都要結(jié)合你自己的數(shù)據(jù)規(guī)模去試不要照抄默認值。單機實驗和集群生產(chǎn)之間最大的差別往往就在那些看起來不起眼的參數(shù)上等你因為一個配置失誤半夜爬起來重啟節(jié)點時就會懂我今天為什么把這些坑單列一章。希望幫到你。本文還有配套的精品資源點擊獲取