简介一份面向计算机科学与技术、软件工程等专业本科毕业生的Hadoop方向学士学位论文围绕气象数据的分布式存储展开研究。论文从Hadoop架构入手系统讲解HDFS分布式文件系统与MapReduce计算模型并结合气温、湿度、风速等多源气象数据的特点设计基于Hadoop的存储系统完整覆盖系统架构、数据分布策略、功能实现与性能评估。全文按绪论、Hadoop技术概述、气象数据存储技术研究、基于Hadoop的存储系统设计、功能实现与性能评估、总结与展望六章展开还包含国内外研究现状综述以及数据安全、资源管理等实践问题可作为毕业论文参考、毕业设计扩展或大数据入门学习资料。论文为原创撰写未入常见论文库可通过查重系统。资源包为1个docx文档压缩后约31KB已有288人学习下载。1. 用Hadoop扛气象数据先想清楚这四件事气象数据是最典型的“海量小文件少量大文件”混合体一个国家级气象站每分钟生成的观测报文本只有几KB一部天气雷达一小时产生的基数据却有几百MB而数值模式跑一次输出的格点场动辄几十TB。传统的NFS集中存储扩不动、查不快于是很多人把目光转向基于Hadoop的分布式存储技术。但反直觉的是直接把几百万个小文件扔进HDFS撑死你的往往不是磁盘而是NameNode的内存——一个文件元数据就要占150字节左右千万个文件就是几个GB的堆空间。这篇笔记就围绕这个矛盾展开从气象数据为什么要走Hadoop到伪分布式、HA集群的搭建路线再到小文件合并、跨集群迁移和各类翻车现场的排查方法最后给你一份验证思路和成本测算。适合气象业务运维、数据工程岗和做hadoop课程设计或研究课题的人新手能跟着敲命令熟手直接看边界参数。2. 为什么气象数据必须走分布式存储从文件体积到计算模式的硬约束2.1 气象数据的三种典型规模和访问特征气象数据不是一个均匀的队列至少可以分成三类。第一类是地面自动站观测数据全国几万个站点逐分钟上报单个文件只有几KB到几十KB。这类数据的特征是“海量、极小、持续追加”一天下来可能积累上千万个文件。它最棘手的问题不是容量而是元数据数量——HDFS里每个文件都对应一串NameNode内存中的树节点当文件数突破百万一次启动fsimage加载就会明显变慢更不用说日常的目录操作。第二种是气象雷达基数据一个体扫文件大约几十MB到几百MB一天一部雷达能产生几个GB全国组网就是TB级。它的访问特征是按站点和时刻随机读取适合按站点分目录存储单个文件又达不到HDFS块大小需要适度合并。第三种是数值模式输出的格点场全球模式或区域模式一次run的产物从几十GB到几十TB文件通常是大文件且后续要做多维切片和统计分析。它们的共同点是“写一次、读多次、极少原地修改”这恰好是HDFS的舒适区。但不同规模对块大小、压缩格式和副本策略的要求完全不同所以存储方案必须分层设计。我一般先把数据按来源与访问模式分类再决定是直接落HDFS、走SequenceFile合并还是转成ORC列式存储。2.2 HDFS为什么比传统NAS和对象存储更适合气象数据不少人问NAS也能扩对象存储也能存为什么非得用Hadoop这里要从访问模式说起。传统NAS通过NFS/CIFS挂载适合小规模共享但元数据服务是中心化的单点文件数超过百万后ls都会卡顿横向扩展要么换代要么加昂贵的专用网关。对象存储比如MinIO、CEPH RGW在容量和带宽上很强但List操作延迟高、对大数据计算框架的本地方支持弱Spark/Hive读对象存储往往要走S3A协议每次读都要做HTTP握手。放在气象业务的真实场景里我们经常要用MapReduce或Spark直接扫描一个时段的全部观测文件做质控这时候数据本地性Data Locality很关键。HDFS把数据切块分散在各节点计算任务能优先调度到持有数据块的节点减少网络传输。这种“存储与计算同池”的架构让历史气象数据回算、批量重处理这类任务的效率比其他方案高一个量级。另一层是可靠性三副本机制或者机架感知下的双副本跨机架副本能够容忍节点故障对长年累积的气象历史数据来说硬件损坏是必然的数据恢复能力比镜像备份更省心。当然HDFS不支持原地修改文件如果你要频繁更新某个时次的观测值就得走Overwrite重写整个文件这是选型时就要接受的限制。为了帮你决策这张表是我常用的对比维度维度传统NAS对象存储HDFS文件数上限百万级后明显卡顿支持多但List延迟高千万级需优化元数据内存追加写支持支持只支持块内追加整体重写数据本地性无弱强随机读小文件快一般慢需合并与Spark/Hive集成需挂载通过S3A有开销原生结论是如果你的气象数据处理链路里只有“存起来、偶尔下载”对象存储够用一旦要做批量计算和在线分析基于Hadoop的方案更划算。这个判断也符合当前大数据平台的主流选择。2.3 存储格式取舍HDFS块大小、压缩、列式存储确定了用HDFS下一步是定块大小和文件格式。HDFS默认块大小在旧版本是64MB新版本一般默认128MB但气象数据要具体调。雷达基数据单文件几百MB块设成64MB会让一个文件拆成多个块读取时要跨多个DataNode如果设成256MB单体扫描更连续但也会减少集群内并行度。我一般遵循一个原则块大小取“文件平均大小的1~2倍”并且不少于128MB。地面站小文件不能靠调块解决必须走合并后面第4章会展开。格式上原始观测报文直接用Text文件存方便气象业务软件对接但分析场景要转成列式格式。ORC或Parquet对浮点格点场的压缩比很惊人一个10GB的模式输出按4字节浮点存成二进制可能是2.5GB用ORC加zlib压缩后还能再压到1GB以下。压缩格式选择上生产环境我推荐LZ4或Snappy压缩速率高解压带宽大zstd压缩比更高但CPU开销也更大。简单说数据沉淀后需要反复查询的转ORC/Gzip只是中间结果或临时数据保留Snappy甚至不压缩。气象数据还有一个特点时间维度天然有序按小时或日期分区能带来显著的裁剪效果。比如查询“2024年5月1日强对流个例的雷达数据”分区裁剪能把扫描范围从全库缩到一个目录。所以存储格式设计不是孤立的文件格式问题而是“目录规划文件合并列式转换”的组合决策。3. 基于Hadoop的气象数据存储架构从伪分布到HA集群的落地路径3.1 伪分布式搭建用docker镜像快速验证存储方案在正式买服务器之前先用一台机器或一台笔记本上的Docker容器跑通伪分布式是最快的验证方式。网上常见的是hadoop伪分布式搭建教程通常步骤是装JDK、关免密登录、改四个xml但手动配环境容易翻车。我习惯直接拉一个现成的hadoop docker镜像比如带Hadoop 3.x的镜像用容器起NameNode和DataNode。下面是一组最小命令我用CentOS系统演示但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 指定了默认文件系统的地址伪分布式下所有进程都连这一个NameNode。挂载./data到容器是让容器退出后数据不丢这一步很关键很多新手临时起容器关掉就一切归零。启动成功后打开 http://localhost:9870 就能看到NameNode的Web界面Datanode列表里会出现一个节点。然后随便传一个文件测试# 进入容器执行 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这种方式的优点是不污染宿主机JDK、Hadoop环境全在镜像里。缺点是伪分布式只有单机测不了机架感知、故障恢复这些集群行为。如果你做的是hadoop安装与配置相关的课程设计或技术验证伪分布式足够看到HDFS的完整读写流程如果要测HA或扩容就得跳到3.2节的多节点搭建。另外提醒一句docker镜像版本鱼龙混杂bde2020这个系列我看到还在维护但建议你拉镜像后先docker inspect看HADOOP_VERSION环境变量确认是3.x再往下走。3.2 多节点集群搭建NameNode/DataNode/JournalNode部署要点真实气象业务至少需要三台以上物理机或云主机。常见做法是部署一个双NameNode的HA集群配合3个JournalNode、3个ZooKeeper节点和一组DataNode。下面是我的推荐角色分配以5台机器为例节点角色node1NameNode(Active)、ZKFC、JournalNodenode2NameNode(Standby)、ZKFC、JournalNodenode3JournalNode、ResourceManager、DataNodenode4DataNode、NodeManagernode5DataNode、NodeManager搭建前要做的准备所有节点互信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这边fs.defaultFS不再写成具体namenode地址而是写成逻辑名mycluster由HA服务去解析当前Active节点。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这里最关键的是dfs.namenode.shared.edits.dir它要求所有NameNode把编辑日志写到同一组JournalNode上两个NameNode通过读取共享日志保持元数据同步。自动故障转移要靠ZooKeeper所以必须配合3.3节的ZooKeeper配置。改完配置后不要急着启动所有节点要按顺序先启动ZooKeeper集群再在node1上执行hdfs namenode -format然后在node2上执行hdfs namenode -bootstrapStandby把元数据同步过来最后用hdfs haadmin -transitionToActive强制切换一次。这一步容易踩坑后面第5章会展开。3.3 Hadoop与Zookeeper整合实战HA高可用的选主与脑裂规避Hadoop HA能实现NameNode自动切换底层实际上是ZooKeeper在扛选主。每个NameNode旁边跑一个ZK Failover ControllerZKFC守护进程它负责向ZooKeeper登记自己为候选节点并监控NameNode的健康状态。当Active的ZKFC发现心跳中断就自动把Active状态让给Standby。这个过程就是hadoop和zookeeper整合实战中最核心的机制。ZooKeeper的安装不需要多讲只要保证3个节点版本一致。需要注意的是ZooKeeper的myid文件必须唯一conf/zoo.cfg里dataDir要指向有空间的目录并加上server.1node1:2888:3888这样的配置。Hadoop这边需要把ZooKeeper客户端相关JAR放到Hadoop的lib下多数发行版已自带。然后启动顺序有讲究# 在三台ZK节点上分别启动 ZooKeeper zkServer.sh start # 在所有Hadoop节点启动HDFS start-dfs.sh # 在node1上检查HA状态 hdfs haadmin -getAllServiceState # 期望输出 # node1:8020 active # node2:8020 standby我在实际部署中遇到最多的问题是ZooKeeper起来了但HDFS的HA没有生效NameNode两侧都显示standby。原因通常是ZooKeeper会话超时配置太长或者防火墙没放开2181、2888端口。建议把dfs.ha.zookeeper.quorum里的地址换成完整主机名并检查hosts文件避免不同节点解析不一致。另一个坑是脑裂在网络分区时两个NameNode可能同时认为自己是Active。HDFS的解决方案是fencing隔离常见配置是shell指令把对方杀死或执行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节点上执行fuser -k强制杀掉NameNode进程。如果SSH互信没配置好fencing会失败导致切换不成功这是我在面试时经常用来梳理的细节也提醒你把互信配置到root和hadoop用户两层。4. 气象数据入库与访问目录设计、分区和文件生命周期4.1 目录与文件命名规范按观测时间和类型组织气象数据一旦进入HDFS目录结构就是它的索引。我在设计目录时坚持三条原则时间维度独立层、数据类型独立层、原始与派生分离。一个推荐的地面观测目录结构如下/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为什么不把时间放在数据站下面比如/weather/station_54511/2024/05/01因为绝大多数气象查询是“某个时间段、覆盖很多站”“按时间分区”能让Spark读取目录列表时直接剪掉无关时间片。文件命名要带上站号和观测时刻如station_54511_202405010000.txt这样即使目录结构丢了文件名本身还能恢复元数据。原始目录raw和派生目录derived分开因为原始数据有气象业务合同要求保留派生数据可以随时重新生成两者的生命周期和副本策略可以不同。分区粒度建议按天。粒度过细会导致目录数量爆炸举例全国5万站一天一个文件按小时分区就比按天多24倍目录NameNode的目录树负担很大。只有雷达数据这种单文件大、时次少的可以按小时或按时次分目录。一旦定了规范就需要用脚本强制约束我习惯在采集端就生成符合规范的路径入库代码里不再做二次解析减少出错。4.2 小文件合并与SequenceFile/ORC转换大多数气象观测文件都是小文件如果把原始TXT直接put到HDFS对NameNode的压力非常大。解决思路有几个一是用Hadoop的CombineFileInputFormat让计算框架在读取时合并但这对存储本身没有帮助二是在入库前把多个小文件合并成一个SequenceFile三是直接转成ORC表。我这里提供一个用Spark批量转换的思路适合把某一天成千上万个站的地面观测TXT合并成一个按天分区的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按站号分区snappy压缩 df.write .mode(overwrite) .partitionBy(station) .option(compression, snappy) .orc(/weather/derived/2024/05/01)这段代码里partitionBy(station) 会在ORC目录下再建一层站号子目录查询单站数据时能快速定位。选择ORC而不是Parquet是因为在Hive/Spark生态里ORC的ACID能力和浮点压缩表现更稳定。合并操作完成后原始txt文件是否删除要视业务需要气象历史参考文件一般至少保留一年但可以移到成本更低的目录比如通过设置副本数为2。如果你不想引入Spark也可以用Hadoop自带的SequenceFile写入器但维护一堆byte数组毕竟麻烦生产上我更愿意定义好Schema后直接上ORC。小文件合并这个动作不只是一次性的我通常会每天在数据接入后触发一个定时合并任务比如用Oozie或Airflow调度避免数据文件持续积压。4.3 distcp参数说明跨集群迁移与备份气象数据存储研究里跨集群复制是常见需求把生产集群的历史数据同步到分析集群做实验或者做异地灾备。Hadoop自带的distcp是首选工具它本质上是MapReduce作业在Map任务里并行拷贝文件。我最常用的命令是这样# 把生产集群 /weather 目录下 2024 年 5 月的数据同步到分析集群相同路径 hadoop distcp -m 20 -b 2048 -p hdfs://prod:8020/weather/obs/2024/05 hdfs://analysis:8020/weather/obs/2024/05参数说明-m 20 表示最多开20个Map任务并行度过高会让源集群NN压力大建议根据源端DataNode数量设为节点数的1~2倍。-b 2048是带宽限制单位MB适合在业务高峰期做限速避免网卡被打满。-p保留属性包括权限、块大小、复制数等迁移气象数据时建议保留否则目标端副本数会使用集群默认值。-diff参数可以增量同步我通常在第二次运行时加上--diff只复制源与目标不同的文件。distcp遇到小文件时Map任务还是会按文件粒度处理所以前面说的合并步骤对distcp同样能减少任务数。还有一个坑distcp默认不会覆盖目标端同名文件如果业务上需要覆盖请加-overwrite参数。5. 常见问题与避坑排查气象数据存储翻车现场5.1 小文件导致NameNode内存爆掉现象集群运行几个月后NameNode的JVM堆内存持续走高频繁Full GC界面卡死甚至进入SafeMode。原因每个文件元数据在NameNode内存里大约占150~220字节含目录项、权限、块信息一堆几KB的观测文件积累到千万级别堆内存几个GB就被吃光了。这是“海量小文件分布式存储”的经典组合拳。解决先救命再治本。临时调大NameNode堆内存在hadoop-env.sh里设置HADOOP_NAMENODE_OPTS-Xmx8g并重启。长期做法是执行4.2的小文件合并把原始TXT按天转成ORC同时清理无用的临时文件hdfs fsck可用于统计小文件占比。日常监控建议每半小时记录一次NN堆内存和活跃文件数阈值设置到80%时告警。5.2 块大小设成64MB造成大量小块现象一个雷达基数据文件300MB读取时跨3个块花的时间反而比单块读更长NameNode块对象数量多fsck扫描慢。原因很多教程还是老版本的64MB默认值气象大文件被无谓切碎。解决在hdfs-site.xml里设dfs.blocksize为268435456256MB或至少134217728128MB。修改后新写入的文件会使用新块大小历史文件不会自动重切如果需要统一可以用distcp加-updated重写一遍。我一般按数据类型分别配置比如雷达目录用256MB观测小文件合并后的ORC块默认128MB即可。5.3 数据倾斜与机架感知配置现象某个新增DataNode磁盘利用率很快爆满而其他节点空闲或者计算任务总是往少数节点上跑。原因HDFS数据均衡策略是随机轮询副本放置也没有机架感知集群拓扑被当作单机架处理。解决配置机架感知脚本让Hadoop知道网络拓扑。在core-site.xml里设置property namenet.topology.script.file.name/name value/opt/hadoop/etc/hadoop/rack-aware.sh/value /property脚本内容按IP映射到机架名例如#!/bin/bash # 简单的机架感知脚本前两个字节相同视为同一机架 case $1 in 192.168.1.*) echo /rack-1 ;; 192.168.2.*) echo /rack-2 ;; *) echo /rack-default ;; esac注意脚本要有可执行权限。有了机架感知HDFS在第二个副本时会优先放到不同机架第三个副本再回到第一个副本所在机架的不同节点这样既容灾又均衡。如果已经存在倾斜执行hdfs balancer -threshold 10让它均衡但要在业务低峰跑因为它会占用IO。5.4 副本策略在气象场景下的调整现象默认3副本磁盘成本翻三倍气象原始数据有压缩归档却没地方放。原因很多人照搬默认配置没想过气象数据的副本需求其实可以从3降到2甚至1。解决气象数据有重建途径如雷达基数据可以从雷达站重新导模式数据可以重新run对原始观测文件2副本已经能容忍单节点故障如果有Hadoop Archive冷备份副本可降到1。设置方式在hdfs-site.xml里全局改dfs.replication2也可以对特定目录设置hdfs dfs -setrep -R 2 /weather/raw这个命令会把指定目录及已有文件的副本数改成2适合对不同数据类型做差异化成本控制。不过要提醒副本数设得太低在DataNode单点故障时会导致块丢失需要用hdfs fsck -list-corruptfileblocks定期检查。降副本前务必确认数据源还有原始文件否则一旦磁盘坏就是真翻车。5.5 磁盘故障与节点掉线后的恢复时序现象DataNode进程在但Web UI显示某个块副本缺失或者某块磁盘IO错误节点被标记为坏盘最终Node进入Decommission状态。原因DataNode多目录中一个坏盘会导致整个节点被判断为异常NameNode检测到超时后启动块复制但因为副本少或网络带宽不够恢复很慢。解决该节点的hdfs-site.xml里设置dfs.datanode.data.dir为多个独立盘目录例如/srv/hdfs/data1,/srv/hdfs/data2这样单盘损坏只影响那部分块不会整个节点宕掉。坏盘处理流程是发现坏盘 → 从配置中移除该目录 → 修改fsimage并重启DataNode → 等待块的re-replicate。恢复期间可以用hdfs dfsadmin -report查看各节点磁盘状态用hdfs fsck /weather -files -blocks检查损坏文件列表。再一个常见坑很多人在DataNode内存溢出或磁盘满后不检查就重启导致节点反复异常。应该先看日志/opt/hadoop/logs/hadoop-hdfs-datanode-*.log里的异常再动手。6. 这个方案值不值得投入验证方法、成本估算与一个进阶技巧6.1 用hadoop面试题清单给存储方案做验证做完这套架构你可以用几个hadoop面试题来验收自己是否真正吃透请描述NameNode的启动流程以及SecondaryNameNode与HA中的Standby节点有什么区别。副本放置策略的默认规则是什么机架感知改了之后会影响哪些行为小文件为什么影响HDFS除了合并还有哪些治理手段distcp在增量同步时如何保证数据一致性这些问题覆盖了从原理到运维的边界。如果你能不看文档答上来说明你的气象数据存储方案不是搭个环境了事。我自己的习惯是每完成一个集群节点配置就在心里过一遍这些题用来发现盲区比如最初我以为Standby节点就是用来读的实际上它的主要职责是热备和及时切换。6.2 存储成本与压缩比实测方法在投入生产前建议先搞一个真实月份的样本测试。选择最近一个完整月的数据统计原始大小、文件个数。然后用下面的命令测量HDFS实际占用# 查看某个目录的实际容量-h 显示人类可读 hdfs dfs -du -h /weather/raw/2024/05假设原始数据是2TBHDFS占用为2TB × 副本数2 4TB如果转成ORC压缩后体积变为600GB那么有效存储成本就变成4TB里实际只用了600GB的物理空间紧缩比约70%。再结合硬盘价格和服务器折旧就能算出每TB气象数据成本。这里要注意du显示的是逻辑块大小不是物理磁盘写入量因为块校验checksum也会占用一点点空间但通常忽略。还要算上NameNode内存成本每100万文件大约需要200MB堆内存按云主机单价折算也是一笔账。把这些算完你就可以给决策层交一份有数字的存储预算方案。6.3 一个进阶技巧基于文件大小的自动归档策略最后给你一个实用的冷热分层技巧。气象历史数据访问频率越来越低但磁盘还在持续写入。可以用Hadoop ArchiveHAR归档老数据将多个小文件打包成har文件减少NameNode元数据压力同时不丢数据。建一个定时归档任务# 把 2023 年及以前的观测原始文件归档成 har 包 hadoop archive -archiveName obs-2023.har -p /weather/obs/2023 /weather/archive/2023执行后/weather/archive/2023下会出现一个obs-2023.har里面包含所有小文件。访问归档文件时不用解压可以直接hdfs dfs -ls har:///weather/archive/2023/obs-2023.har读取。归档后原始目录可以设置成只读或清理你仍然能通过Spark读har里的数据只是性能略低于未归档。这个技巧特别适合存量气候数据能在一周内存活集群的元数据压力降一个量级。我的教训是归档脚本要放在业务低峰执行并且先跑一次小范围样例验证查询端能正常读har再全量归档因为HAR压缩过程如果中途失败部分小文件可能不可见需要原始目录的副本兜底。这套基于Hadoop的气象数据分布式存储方案从架构选型到集群搭建、数据入库、成本测算我已经讲完了。如果你正在做气象数据平台建议先从伪分布式验证目录设计和合并流程再逐步扩展到HA集群。每个环节的数据格式、块大小、副本策略都要结合你自己的数据规模去试不要照抄默认值。单机实验和集群生产之间最大的差别往往就在那些看起来不起眼的参数上等你因为一个配置失误半夜爬起来重启节点时就会懂我今天为什么把这些坑单列一章。希望帮到你。本文还有配套的精品资源点击获取