简介实验二“熟悉常用的HDFS操作”配套实验报告面向正在学习大数据原理与Hadoop生态的初学者聚焦HDFS在Hadoop体系中的核心角色以及Shell命令与Java API两种主流操作方式。资源包仅含1个docx文档大小3.4MB内容为一篇完整的课程实验报告包含实验环境说明、Shell命令操作步骤、Java代码实现及运行效果记录结构清晰可直接对照学习。该资源已有10209人浏览学习属于高热度的大数据入门资料。报告基于Ubuntu 16.04/Hadoop 2.7.1环境实际演示在Windows虚拟机运行ubuntukylin-16.04/Hadoop 3.1.3详细覆盖了hdfs dfs -put上传、-test -e检查存在性、-appendToFile追加、-copyFromLocal -f覆盖等常用命令Java部分则给出FileSystem、Path、FSDataOutputStream等类的具体用法实现了文件存在性判断、本地复制到HDFS及内容追加等功能。无论是完成课程实验还是理解HDFS编程模型这份报告都能提供完整参考并能为后续MapReduce编程和HBase学习奠定扎实基础。1. HDFS 操作实验先会走再谈跑命令背后的原理才是拿分点但凡打开过实验指导书面前多半是一排 hdfs dfs -mkdir、-put、-cat 的命令行。很多同学敲完一遍报告里抄上截图觉得“实验二”就过去了。可答辩或考核时老师一问“你这三个副本是放到哪三台机器上的”“写入过程里 DataNode 挂了怎么办”现场就卡壳。这个实验真正要练的不是记住命令而是通过命令把 NameNode、DataNode、副本放置、写流程这几件事像烙铁一样烙在脑子里。这篇笔记覆盖从环境准备、常用命令、写读流程原理到 fsck 验证的完整复现路径也把伪分布式和真实集群都会踩的坑列出来。适合正在做头歌平台“Hadoop 开发环境搭建及 HDFS 初体验”这类实训的学生也适合入职前临时抱佛脚复习 HDFS 的初学者。全程按可以直接照做的顺序写命令验证过参数给到具体值。2. 环境准备与集群启停格式化、安全模式、单机伪分布式搭建2.1 为什么实验环境推荐伪分布式而不是单机模式单机模式Local Mode下 HDFS 的三个核心进程都在同一个 JVM 里文件直接落本地磁盘没有网络传输也没有副本机制跑 put/get 和直接 cp 没有本质区别。实验要观察的副本放置、机架感知、块报告这些行为单机模式下全都看不见。伪分布式Pseudo-Distributed Mode用同一台机器的三个独立进程模拟集群NameNode、DataNode、SecondaryNameNode 各占一个 JVM端口也分开是体验完整 HDFS 行为的最小成本方案。HDFS 的默认副本数是 3伪分布式只有一台机器DataNode 只有一个所以这个场景下副本数实际达不到 3。这不是实验环境坏了是硬件的物理边界决定的。做副本相关实验时要么手动把副本系数改成 1要么用三台虚拟机构建最小集群。很多同学就是栽在这——看到 fsck 报告里 REPLICATION FACTOR 低于 3 就以为集群有问题到处重装。2.2 格式化与安全模式的完整启动流程首次启动集群前必须先格式化 NameNode。格式化的本质是生成空的镜像文件 fsimage 和集群唯一标识 clusterID。这里最容易出现的误区是以为格式化会“格式化 DataNode”实际上hdfs namenode -format只处理 NameNode 的命名空间不碰数据节点上的块数据。# 切换到 Hadoop 安装目录 cd /usr/local/hadoop # 首次使用必须格式化生成新的 clusterID bin/hdfs namenode -format # 启动 HDFS 守护进程NameNode、DataNode、SecondaryNameNode sbin/start-dfs.sh # 用 JVM 工具查看三个进程是否都活着 jps格式化过程中要留意输出里是否出现“successfully formatted”字样同时记下这一行打印的 clusterID。后面如果集群连不上第一步就是比对 NameNode 和 DataNode 的 VERSION 文件里的 clusterID 是否一致。start-dfs.sh 执行完jps 应该能看到至少三个进程NameNode、DataNode、SecondaryNameNode。如果少了 SecondaryNameNodeHDFS 还能用但检查点机制缺失NameNode 重启恢复时间会明显变长属于隐患不是事故。启动后立即执行hdfs dfsadmin -safemode get大概率会返回 ON。安全模式是 NameNode 启动后的强制状态用来等待 DataNode 上报块报告。只有达到配置的块阈值默认 99.9% 的块上报完成才会自动退出。伪分布式单节点集群通常几十秒内退出如果长时间卡在安全模式多半是 DataNode 没起来或块报告被防火墙挡了不是配置错误。2.3 停机顺序与重要配置项停机顺序和启动相反先停 HDFS 再停辅助服务避免 NameNode 还在处理写请求时 DataNode 全部消失。# 停止 HDFS与 start 对应 sbin/stop-dfs.sh # 确认所有 Java 进程已退出 jpsjps 输出为空才算真正停干净。很多实验报告翻车场景就是这样上一次实验没停干净这一次直接 start-dfs.sh端口被占用NameNode 进程起不来。报错信息里出现 “Address already in use”端口被占用时第一件事不是改端口而是jps看有没有残留进程然后kill -9清掉。需要关注的三个核心配置项如下实验环境可以直接抄这组值配置项配置位置实验推荐值作用fs.defaultFScore-site.xmlhdfs://localhost:9000默认文件系统地址指向 N门dfs.replicationhdfs-site.xml1伪分布式默认副本数影响写流程和 fsck 报告dfs.namenode.name.dirhdfs-site.xml/usr/local/hadoop/tmp/dfs/nameNameNode 元数据目录格式化产物落在这dfs.datanode.data.dirhdfs-site.xml/usr/local/hadoop/tmp/dfs/dataDataNode 块数据目录存实际内容配置 hdfs-site.xml 时最容易漏的是没有设置 name.dir 和 data.dir 而用系统默认路径导致格式化后的数据不知道落在哪后面想清理都找不到地方。实验环境我通常会把两个目录手动指定到 hadoop 安装目录下的 tmp 里以后删数据、看报告都方便。改完配置必须重启集群才生效很多人改了 core-site.xml 不重启然后怀疑自己配错了。3. 目录与文件操作从建目录到管道副本的完整命令族3.1 目录操作与路径语义HDFS 的目录操作命令和 Linux 命令长得非常像但有一个本质区别HDFS 的路径以hdfs://namenode-host:9000/为根命令行里可以省略这个前缀直接写/user/hadoop命令会从 core-site.xml 里读默认文件系统。实验报告里大量截图只显示路径不显示前缀就是这个原因。# 递归创建目录-p 参数避免父目录不存在时报错 hdfs dfs -mkdir -p /user/hadoop/input # 查看目录内容显示文件大小、副本数、修改时间 hdfs dfs -ls /user/hadoop/ # 递归查看整棵目录树包含所有子目录和文件 hdfs dfs -ls -R /user/hadoop/ # 查看目录占用空间按人类可读方式显示 hdfs dfs -du -h /user/hadoop-mkdir -p的-p和 Linux 下的mkdir -p含义一致一次性写入多层目录不用逐层创建。-ls输出里的第二列数字是副本数膜分布式下显示 1真实集群下显示 3这一列就是写流程里副本放置的最直观证据。-du -h统计的是逻辑占用即文件实际大小不是物理占用——物理占用要乘以副本数这是 HDFS 容量规划里的经典坑一个 10 GB 的文件三副本实际占 30 GB 物理空间。3.2 文件上传下载与查看文件操作是实验二里最核心的得分区。命令不难难在每个命令的参数和输出怎样解读。上传命令-put等价于-copyFromLocal下载命令-get等价于-copyToLocal只是名字不同行为完全一致。# 创建一个本地测试文件 echo hello hdfs experiment /tmp/test.txt # 上传到 HDFS目标是目录时自动保留原文件名 hdfs dfs -put /tmp/test.txt /user/hadoop/input/ # 查看文件块信息-blocks 显示块 ID 和位置 hdfs fsck /user/hadoop/input/test.txt -files -blocks -locations # 下载到本地指定目录目录不存在时会自动创建 hdfs dfs -get /user/hadoop/input/test.txt /tmp/download/ # 查看文件内容不落本地磁盘 hdfs dfs -cat /user/hadoop/input/test.txt-put的上传路径如果写的是目录文件会保留原名放进目录如果写的是完整文件路径则相当于重命名上传。fsck 命令里的-files -blocks -locations三个参数一起用能同时看到文件、块、块所在节点三层信息实验报告里截这张图原理部分基本就能站住脚了。-cat适合小文件几百 MB 以上的文件直接用-cat会把终端刷爆用hdfs dfs -text查看前几千字节或者直接-get下来分段看不要等到终端卡死才后悔。3.3 权限、副本调整与回收站权限模型与 POSIX 权限基本一致owner/group/other 三类身份rwx 三种权限。但 HDFS 没有“执行位”的传统语义——执行位 x 对文件没有实际作用目录的 x 位代表“可遍历”只要有读位就能列出文件名但要进入目录必须同时有 x 位。这个点常作为实验报告问答题的坑。# 修改文件权限755 属主 rwx属组 rx其他 rx hdfs dfs -chmod -R 755 /user/hadoop/input # 修改属主和属组超级用户才能执行 hdfs dfs -chown -R hadoop:hadoop /user/hadoop/input # 把副本数改成 2NameNode 会调度新副本创建 hdfs dfs -setrep -R 2 /user/hadoop/input # 查看回收站配置是否开启 hdfs getconf -confKey fs.trash.interval-setrep修改副本数是异步操作命令返回后数据迁移在后台进行。改完立刻看 fsck 可能还是旧副本数等几十秒再查。回收站机制默认关闭fs.trash.interval为 0 表示不启用此时-rm删除的文件直接物理释放没有后悔药可吃。实验时我一般先执行 getconf 确认回收站状态再决定删文件时要不要提前备份。生产集群通常把回收站间隔设成 1440 分钟一天实验环境默认关闭反而干净。4. 读写流程与副本机制实验报告里最难拿分的原理部分4.1 写入流程从客户端到三副本的管道建立HDFS 写流程是整个实验二里最值得展开讲的原理。客户端请求写一个文件时流程可以拆成六个步骤每一步都对应一个可以在日志里观察到的动作。写流程的本质是“客户端写入本地缓冲区 - 请求 NameNode 建文件 - 建立到 DataNode 的管道 - 数据包按序写入并逐级确认”。客户端先调用 DistributedFileSystem.create() 发起 RPC 请求到 NameNode请求内容包含路径、副本数、块大小。NameNode 在命名空间里创建文件条目检查目录存在、权限允许、副本系数合法任何一个条件不满足都会直接拒绝。文件条目创建后NameNode 返回一个 HdfsDataOutputStream 给客户端。此时文件还是“正在写入”状态对别的客户端不可见这层保护依赖租约机制lease防止两个客户端同时写同一路径。客户端开始写数据时先在本地缓冲区攒数据。默认块大小 128 MB数据按数据包packet为单位切分每个 packet 默认 64 KB。攒够一个块的数据后客户端向 NameNode 申请一批 DataNode 地址这批地址就是块副本的放置列表由机架感知策略决定。NameNode 按“本机优先、同机架其次、跨机架最后”的顺序挑选节点返回给客户端。客户端拿到列表后建立到第一个 DataNode 的 TCP 连接第一个 DataNode 再连第二个第二个连第三个形成一条以客户端为起点的数据管道。数据包沿管道逐级下传每个 DataNode 写完本地磁盘后向上一个节点发送确认ack确认逐级回到客户端客户端再发下一个 packet。这个逐级确认的机制叫流水线复制pipeline replication。最后一个 packet 写完并收到所有确认后客户端调用 close()NameNode 落实文件条目把文件状态从“正在写入”切换成“已关闭”。整个过程中有一个隐藏动作值得写进报告——每个 packet 都携带校验和数据校验方式是 CRC32校验粒度是 512 字节。DataNode 每收到一个 chunk 就计算校验和存到磁盘的 meta 文件里读的时候重新计算比对。这是 HDFS 不需要 RAID 也能保证数据完整性的底层逻辑。4.2 写入失败时的降级流程写流程中任何一个 DataNode 挂了pipeline 会立刻断掉。客户端感知到管道断裂后把已经发送但未确认的 packet 保存在缓冲区同时向 NameNode 申请一份新的 DataNode 列表列表会剔除故障节点客户端重新建立管道把缓冲中的数据重发一遍。整个降级过程中已经写入的数据块不会丢失NameNode 会记录下这个块缺少副本并安排后台线程把缺失副本补到新节点上。这里面有一个实际工作中高频出现的坑写一个大文件时如果网络稍有抖动DataNode 频繁掉线客户端会反复申请新列表和重建管道。每次重建都有超时开销表现为-put命令长时间“卡住”然后抛 SocketTimeoutException。伪分布式单节点实验没有这个问题真实的三节点集群很常见。遇到这种情况先检查机器负载不要上来就怀疑 Hadoop 本身。4.3 副本放置策略的三个候选节点与读取流程HDFS 默认副本因子 3放置策略可以用一句话概括第一个副本放客户端所在节点客户端不在集群时随机挑一个负载低的节点第二个副本放同一机架的不同节点第三个副本放另一个机架下的随机节点。两个副本为了容灾分散到两个机架两个副本为了性能留在一个机架内避免了跨机架流量打满。这个策略是hdfs-site.xml里的dfs.replication和机架感知脚本共同决定的没有配置机架拓扑时所有节点被当成同一个机架三副本会全部落在同一机架容灾能力归零。读取流程比写入简单得多没有管道概念。客户端请求 NameNode 拿文件块和副本位置列表NameNode 返回按网络距离排序的 DataNode 列表客户端和排在最前面的节点建立连接读数据。读的过程中逐块进行 CRC32 校验校验失败会尝试列表里的下一个副本。这解释了为什么 fsck 报告里文件显示“healthy”但仍然可能读到坏数据——实际上读不出来因为校验失败会触发重试到好副本用户无感。4.4 块大小与副本系数不是越大越好实验报告问答环节的高频问题“块大小设置成 256 MB 有什么影响”这需要分清两个层面。块越大NameNode 存储的块元数据越少同样大小文件块数少对大文件友好但块越大MapReduce 对单个块的并行度越低一个块只能被一个 Map 任务处理。块越小并行度高但元数据膨胀大量小文件会把 NameNode 的堆内存撑爆。默认 128 MB 是在元数据开销和计算并行度之间平衡的结果。副本系数同理3 副本已经是绝大多数场景的默认选择太大浪费空间太小丢数据后没地方恢复。5. 常见问题排查五个让集群“假死”的真实坑5.1 格式化后集群连不上clusterID 不一致现象第二次格式化之后DataNode 进程活着但 jps 里 NamendNode 起不来日志不断提示 DataNode 拒绝连接或 Web UI 上 DataNode 列表为 0。原因每次hdfs namenode -format会重新生成一个新的 clusterID写入到 NameNode 的 VERSION 文件里。而 DataNode 侧的 VERSION 文件还保留着第一次格式化时的 clusterID两边对不上DataNode 的上报被 NameNode 无视。解决停止整个集群分别找到 dfs.name.dir 和 dfs.data.dir 目录把两个目录下的 current 文件夹完整删除再重新执行hdfs namenode -format并start-dfs.sh。如果是三节点真实集群三台机器的 data 目录都要同步清理否则两边 clusterID 还是对不上。真实生产环境里严禁随意重新格式化格式化会清空整个文件系统元数据数据全丢。5.2 上传文件卡死然后报错写管道超时现象hdfs dfs -put执行后长时间不见进度终端像是挂住最后抛出 SocketTimeoutException 或 AlreadyBeingCreatedException。原因客户端向 NameNode 发送 create 请求成功后NameNode 会记录文件“正在创建”如果后续写管道迟迟建立不起来或写一半断掉客户端崩溃退出租约没有正常释放NameNode 里残留处于“正在写入”状态的文件条目。下次再用同一路径上传NameNode 判定文件仍被旧租约占用直接拒绝。解决先看文件系统里同名路径是否存在用hdfs dfs -ls -R核实然后用 fsck 查看这个路径的租约状态。确认是残留租约后执行hdfs debug recoverLease -path /user/hadoop/input/test.txt -retries 3强制恢复租约之后再重新 put。伪分布式单节点上常用更简单的办法——删除残留文件再重传但删不掉时NameNode 还在等租约释放就要走 debug 命令。5.3 集群卡在安全模式出不来块上报没达标现象启动后不管等多久hdfs dfsadmin -safemode get始终返回 ONWeb UI 提示 Safe mode is ON任何写操作都被拒绝。原因安全模式退出条件是已上报的块数量占总块数量百分比达到dfs.namenode.safemode.threshold-pct默认 99.9%。DataNode 进程没起来、防火墙挡了块报告端口、磁盘满了写不进临时文件都会导致上报不齐。解决先jps确认 DataNode 是否存在不存在则查 DataNode 日志$HADOOP_HOME/logs/hadoop--datanode-.log常见是端口占用或 Java 堆内存不足。都正常仍卡住时可以用hdfs dfsadmin -safemode leave手动强制退出但这属于治标下次重启大概率还会卡必须回到日志查根因。5.4 fsck 报告块健康但文件读不了校验和损坏现象文件所有块状态 HEALTHY但-cat或-get过程中报 ChecksumException读出来的内容损坏。原因fsck 检查的是块的元数据和副本数不校验文件内容。某个块的数据写入时和校验和不匹配比如磁盘静默损坏或进程 kill 在写一半时该块在 fsck 里仍显示健康因为 fsck 不读块内容。解决对损坏文件执行hdfs dfs -get时读到哪个块报错在报错信息里定位块 ID确认是哪个 DataNode 的哪个块如果还有其他副本把坏副本文件删掉让 NameNode 重新复制一份正常副本如果只有一份副本且已损坏这个文件无法恢复只能从源头重新上传。这体现了三副本在生产环境的意义也是实验报告里可以写的延伸思考。5.5 节点配置齐全却显示副本不足机架感知未配置现象真实三节点集群启动后上传的文件在 fsck 里显示 UNDER REPLICATED副本数一直补不到 3。原因没有配置机架感知时所有节点被看作同一个机架NameNode 挑选副本时全部落在一个机架内。三副本都放在同一机架确实能写满三个副本但如果其中一个节点挂了NameNode 找不到“足够远”的节点来补副本就一直停在 UNDER REPLICATED 状态。解决在topology.script.file.name配置项里指定一个机架映射脚本脚本对每个节点 IP 或主机名返回机架标识让 NameNode 感知到跨机架的节点。脚本本身用 shell 写几十行就能跑实验环境把三个节点分别映射到 /rack1、/rack2、/rack3重启集群后重新上传测试文件fsck 会显示副本数恢复为 3。6. 用 fsck 和文件指纹给实验结果做验收6.1 fsck 报告的三个必看指标实验做完不是命令跑完就结束必须用一个可量化的方式验证结果。hdfs fsck /user/hadoop -files -blocks -locations是 HDFS 自带的体检工具输出末尾是一行汇总信息重点关注三个数值。Health Status 显示 HEALTHY 表示所有块副本数满足要求没有缺失Under-replicated blocks 是 0 说明副本全数补齐Missing blocks 是 0 说明没有块损坏或丢失。实验环境如果 Health Status 是 CORRUPT损坏或 UNDER REPLICATED副本不足八成是副本数配置或节点故障问题按第 5 章的方法排查。三个指标全部达标后再把输出里任意一个文件的 block 列表截图或保存下来作为实验报告里“写流程验证”的佐证——它同时展示了文件被切成哪几个块、每一块的副本落在哪台机器对应 4.1 节的放置策略。6.2 用块文件和 md5 做双层验证fsck 只验证块的元数据状态不验证数据内容完整。要确实验证上传的数据和本地原数据一致需要在 HDFS 层面和本地层面各做一遍指纹比对。# HDFS 侧计算块文件的 CRC 校验信息 hdfs fsck /user/hadoop/input/test.txt -files -blocks -locations | grep test.txt # 本地源文件指纹 md5sum /tmp/test.txt # 从 HDFS 下载后再次计算指纹两次比对 hdfs dfs -get /user/hadoop/input/test.txt /tmp/check.txt md5sum /tmp/check.txt两个 md5 值完全一致说明数据经历了上传、管道复制、落盘、读取全链路没有发生损坏。这一步看起来多余但对于做实验的人来说它能排除“数字看起来对实际数据已坏”的假阳性。我在做三节点集群验证时还会多做一步删除其中一个 DataNode 上的某个块副本等几十秒后重跑 fsck观察 NameNode 如何自动补副本这个验证能让三副本机制的印象深刻得多。6.3 快照与配额两个容易写进报告的高级操作如果实验课时充足建议把快照Snapshot和目录配额Quota也做一遍这两个操作在真实工作里使用频率很高但教科书很少展开。快照是对目录做只读备份不占额外空间只有文件变更后才产生差异数据。目录配额用来限制目录存储的文件数量防止某个业务线无节制写入把集群磁盘撑爆。两个操作结合就构成了 HDFS 最轻量的“备份 限流”组合。# 允许对 /user/hadoop/data 目录创建快照 hdfs dfsadmin -allowSnapshot /user/hadoop/data # 创建名为 snap1 的快照 hdfs dfs -createSnapshot /user/hadoop/data snap1 # 对目录设置文件数上限为 100 hdfs dfsadmin -setQuota 100 /user/hadoop/data快照创建后任何误删操作都能通过hdfs dfs -ls /user/hadoop/data/.snapshot/snap1/找回原文件。从那以后我每次带新人做实验都会强制他们先建快照再做大量删除操作这已经是防止误删的习惯性动作。配额超出时写入会被拒绝报错提示配额超限而不是任何权限错误。做完这两个操作实验报告里可以写的内容就不只是基础命令了还能延伸到 HDFS 在生产环境的日常管理手段。希望这份实践笔记对你有帮助不管是在头歌平台上做实训还是在自己搭的伪分布式集群上折腾一定要亲手跑一遍 fsck 和 md5sum这比多敲十遍 put/get 都更有价值。本文还有配套的精品资源点击获取 HDFS操作实验：从命令到原理，副本与写流程全解析
简介实验二“熟悉常用的HDFS操作”配套实验报告面向正在学习大数据原理与Hadoop生态的初学者聚焦HDFS在Hadoop体系中的核心角色以及Shell命令与Java API两种主流操作方式。资源包仅含1个docx文档大小3.4MB内容为一篇完整的课程实验报告包含实验环境说明、Shell命令操作步骤、Java代码实现及运行效果记录结构清晰可直接对照学习。该资源已有10209人浏览学习属于高热度的大数据入门资料。报告基于Ubuntu 16.04/Hadoop 2.7.1环境实际演示在Windows虚拟机运行ubuntukylin-16.04/Hadoop 3.1.3详细覆盖了hdfs dfs -put上传、-test -e检查存在性、-appendToFile追加、-copyFromLocal -f覆盖等常用命令Java部分则给出FileSystem、Path、FSDataOutputStream等类的具体用法实现了文件存在性判断、本地复制到HDFS及内容追加等功能。无论是完成课程实验还是理解HDFS编程模型这份报告都能提供完整参考并能为后续MapReduce编程和HBase学习奠定扎实基础。1. HDFS 操作实验先会走再谈跑命令背后的原理才是拿分点但凡打开过实验指导书面前多半是一排 hdfs dfs -mkdir、-put、-cat 的命令行。很多同学敲完一遍报告里抄上截图觉得“实验二”就过去了。可答辩或考核时老师一问“你这三个副本是放到哪三台机器上的”“写入过程里 DataNode 挂了怎么办”现场就卡壳。这个实验真正要练的不是记住命令而是通过命令把 NameNode、DataNode、副本放置、写流程这几件事像烙铁一样烙在脑子里。这篇笔记覆盖从环境准备、常用命令、写读流程原理到 fsck 验证的完整复现路径也把伪分布式和真实集群都会踩的坑列出来。适合正在做头歌平台“Hadoop 开发环境搭建及 HDFS 初体验”这类实训的学生也适合入职前临时抱佛脚复习 HDFS 的初学者。全程按可以直接照做的顺序写命令验证过参数给到具体值。2. 环境准备与集群启停格式化、安全模式、单机伪分布式搭建2.1 为什么实验环境推荐伪分布式而不是单机模式单机模式Local Mode下 HDFS 的三个核心进程都在同一个 JVM 里文件直接落本地磁盘没有网络传输也没有副本机制跑 put/get 和直接 cp 没有本质区别。实验要观察的副本放置、机架感知、块报告这些行为单机模式下全都看不见。伪分布式Pseudo-Distributed Mode用同一台机器的三个独立进程模拟集群NameNode、DataNode、SecondaryNameNode 各占一个 JVM端口也分开是体验完整 HDFS 行为的最小成本方案。HDFS 的默认副本数是 3伪分布式只有一台机器DataNode 只有一个所以这个场景下副本数实际达不到 3。这不是实验环境坏了是硬件的物理边界决定的。做副本相关实验时要么手动把副本系数改成 1要么用三台虚拟机构建最小集群。很多同学就是栽在这——看到 fsck 报告里 REPLICATION FACTOR 低于 3 就以为集群有问题到处重装。2.2 格式化与安全模式的完整启动流程首次启动集群前必须先格式化 NameNode。格式化的本质是生成空的镜像文件 fsimage 和集群唯一标识 clusterID。这里最容易出现的误区是以为格式化会“格式化 DataNode”实际上hdfs namenode -format只处理 NameNode 的命名空间不碰数据节点上的块数据。# 切换到 Hadoop 安装目录 cd /usr/local/hadoop # 首次使用必须格式化生成新的 clusterID bin/hdfs namenode -format # 启动 HDFS 守护进程NameNode、DataNode、SecondaryNameNode sbin/start-dfs.sh # 用 JVM 工具查看三个进程是否都活着 jps格式化过程中要留意输出里是否出现“successfully formatted”字样同时记下这一行打印的 clusterID。后面如果集群连不上第一步就是比对 NameNode 和 DataNode 的 VERSION 文件里的 clusterID 是否一致。start-dfs.sh 执行完jps 应该能看到至少三个进程NameNode、DataNode、SecondaryNameNode。如果少了 SecondaryNameNodeHDFS 还能用但检查点机制缺失NameNode 重启恢复时间会明显变长属于隐患不是事故。启动后立即执行hdfs dfsadmin -safemode get大概率会返回 ON。安全模式是 NameNode 启动后的强制状态用来等待 DataNode 上报块报告。只有达到配置的块阈值默认 99.9% 的块上报完成才会自动退出。伪分布式单节点集群通常几十秒内退出如果长时间卡在安全模式多半是 DataNode 没起来或块报告被防火墙挡了不是配置错误。2.3 停机顺序与重要配置项停机顺序和启动相反先停 HDFS 再停辅助服务避免 NameNode 还在处理写请求时 DataNode 全部消失。# 停止 HDFS与 start 对应 sbin/stop-dfs.sh # 确认所有 Java 进程已退出 jpsjps 输出为空才算真正停干净。很多实验报告翻车场景就是这样上一次实验没停干净这一次直接 start-dfs.sh端口被占用NameNode 进程起不来。报错信息里出现 “Address already in use”端口被占用时第一件事不是改端口而是jps看有没有残留进程然后kill -9清掉。需要关注的三个核心配置项如下实验环境可以直接抄这组值配置项配置位置实验推荐值作用fs.defaultFScore-site.xmlhdfs://localhost:9000默认文件系统地址指向 N门dfs.replicationhdfs-site.xml1伪分布式默认副本数影响写流程和 fsck 报告dfs.namenode.name.dirhdfs-site.xml/usr/local/hadoop/tmp/dfs/nameNameNode 元数据目录格式化产物落在这dfs.datanode.data.dirhdfs-site.xml/usr/local/hadoop/tmp/dfs/dataDataNode 块数据目录存实际内容配置 hdfs-site.xml 时最容易漏的是没有设置 name.dir 和 data.dir 而用系统默认路径导致格式化后的数据不知道落在哪后面想清理都找不到地方。实验环境我通常会把两个目录手动指定到 hadoop 安装目录下的 tmp 里以后删数据、看报告都方便。改完配置必须重启集群才生效很多人改了 core-site.xml 不重启然后怀疑自己配错了。3. 目录与文件操作从建目录到管道副本的完整命令族3.1 目录操作与路径语义HDFS 的目录操作命令和 Linux 命令长得非常像但有一个本质区别HDFS 的路径以hdfs://namenode-host:9000/为根命令行里可以省略这个前缀直接写/user/hadoop命令会从 core-site.xml 里读默认文件系统。实验报告里大量截图只显示路径不显示前缀就是这个原因。# 递归创建目录-p 参数避免父目录不存在时报错 hdfs dfs -mkdir -p /user/hadoop/input # 查看目录内容显示文件大小、副本数、修改时间 hdfs dfs -ls /user/hadoop/ # 递归查看整棵目录树包含所有子目录和文件 hdfs dfs -ls -R /user/hadoop/ # 查看目录占用空间按人类可读方式显示 hdfs dfs -du -h /user/hadoop-mkdir -p的-p和 Linux 下的mkdir -p含义一致一次性写入多层目录不用逐层创建。-ls输出里的第二列数字是副本数膜分布式下显示 1真实集群下显示 3这一列就是写流程里副本放置的最直观证据。-du -h统计的是逻辑占用即文件实际大小不是物理占用——物理占用要乘以副本数这是 HDFS 容量规划里的经典坑一个 10 GB 的文件三副本实际占 30 GB 物理空间。3.2 文件上传下载与查看文件操作是实验二里最核心的得分区。命令不难难在每个命令的参数和输出怎样解读。上传命令-put等价于-copyFromLocal下载命令-get等价于-copyToLocal只是名字不同行为完全一致。# 创建一个本地测试文件 echo hello hdfs experiment /tmp/test.txt # 上传到 HDFS目标是目录时自动保留原文件名 hdfs dfs -put /tmp/test.txt /user/hadoop/input/ # 查看文件块信息-blocks 显示块 ID 和位置 hdfs fsck /user/hadoop/input/test.txt -files -blocks -locations # 下载到本地指定目录目录不存在时会自动创建 hdfs dfs -get /user/hadoop/input/test.txt /tmp/download/ # 查看文件内容不落本地磁盘 hdfs dfs -cat /user/hadoop/input/test.txt-put的上传路径如果写的是目录文件会保留原名放进目录如果写的是完整文件路径则相当于重命名上传。fsck 命令里的-files -blocks -locations三个参数一起用能同时看到文件、块、块所在节点三层信息实验报告里截这张图原理部分基本就能站住脚了。-cat适合小文件几百 MB 以上的文件直接用-cat会把终端刷爆用hdfs dfs -text查看前几千字节或者直接-get下来分段看不要等到终端卡死才后悔。3.3 权限、副本调整与回收站权限模型与 POSIX 权限基本一致owner/group/other 三类身份rwx 三种权限。但 HDFS 没有“执行位”的传统语义——执行位 x 对文件没有实际作用目录的 x 位代表“可遍历”只要有读位就能列出文件名但要进入目录必须同时有 x 位。这个点常作为实验报告问答题的坑。# 修改文件权限755 属主 rwx属组 rx其他 rx hdfs dfs -chmod -R 755 /user/hadoop/input # 修改属主和属组超级用户才能执行 hdfs dfs -chown -R hadoop:hadoop /user/hadoop/input # 把副本数改成 2NameNode 会调度新副本创建 hdfs dfs -setrep -R 2 /user/hadoop/input # 查看回收站配置是否开启 hdfs getconf -confKey fs.trash.interval-setrep修改副本数是异步操作命令返回后数据迁移在后台进行。改完立刻看 fsck 可能还是旧副本数等几十秒再查。回收站机制默认关闭fs.trash.interval为 0 表示不启用此时-rm删除的文件直接物理释放没有后悔药可吃。实验时我一般先执行 getconf 确认回收站状态再决定删文件时要不要提前备份。生产集群通常把回收站间隔设成 1440 分钟一天实验环境默认关闭反而干净。4. 读写流程与副本机制实验报告里最难拿分的原理部分4.1 写入流程从客户端到三副本的管道建立HDFS 写流程是整个实验二里最值得展开讲的原理。客户端请求写一个文件时流程可以拆成六个步骤每一步都对应一个可以在日志里观察到的动作。写流程的本质是“客户端写入本地缓冲区 - 请求 NameNode 建文件 - 建立到 DataNode 的管道 - 数据包按序写入并逐级确认”。客户端先调用 DistributedFileSystem.create() 发起 RPC 请求到 NameNode请求内容包含路径、副本数、块大小。NameNode 在命名空间里创建文件条目检查目录存在、权限允许、副本系数合法任何一个条件不满足都会直接拒绝。文件条目创建后NameNode 返回一个 HdfsDataOutputStream 给客户端。此时文件还是“正在写入”状态对别的客户端不可见这层保护依赖租约机制lease防止两个客户端同时写同一路径。客户端开始写数据时先在本地缓冲区攒数据。默认块大小 128 MB数据按数据包packet为单位切分每个 packet 默认 64 KB。攒够一个块的数据后客户端向 NameNode 申请一批 DataNode 地址这批地址就是块副本的放置列表由机架感知策略决定。NameNode 按“本机优先、同机架其次、跨机架最后”的顺序挑选节点返回给客户端。客户端拿到列表后建立到第一个 DataNode 的 TCP 连接第一个 DataNode 再连第二个第二个连第三个形成一条以客户端为起点的数据管道。数据包沿管道逐级下传每个 DataNode 写完本地磁盘后向上一个节点发送确认ack确认逐级回到客户端客户端再发下一个 packet。这个逐级确认的机制叫流水线复制pipeline replication。最后一个 packet 写完并收到所有确认后客户端调用 close()NameNode 落实文件条目把文件状态从“正在写入”切换成“已关闭”。整个过程中有一个隐藏动作值得写进报告——每个 packet 都携带校验和数据校验方式是 CRC32校验粒度是 512 字节。DataNode 每收到一个 chunk 就计算校验和存到磁盘的 meta 文件里读的时候重新计算比对。这是 HDFS 不需要 RAID 也能保证数据完整性的底层逻辑。4.2 写入失败时的降级流程写流程中任何一个 DataNode 挂了pipeline 会立刻断掉。客户端感知到管道断裂后把已经发送但未确认的 packet 保存在缓冲区同时向 NameNode 申请一份新的 DataNode 列表列表会剔除故障节点客户端重新建立管道把缓冲中的数据重发一遍。整个降级过程中已经写入的数据块不会丢失NameNode 会记录下这个块缺少副本并安排后台线程把缺失副本补到新节点上。这里面有一个实际工作中高频出现的坑写一个大文件时如果网络稍有抖动DataNode 频繁掉线客户端会反复申请新列表和重建管道。每次重建都有超时开销表现为-put命令长时间“卡住”然后抛 SocketTimeoutException。伪分布式单节点实验没有这个问题真实的三节点集群很常见。遇到这种情况先检查机器负载不要上来就怀疑 Hadoop 本身。4.3 副本放置策略的三个候选节点与读取流程HDFS 默认副本因子 3放置策略可以用一句话概括第一个副本放客户端所在节点客户端不在集群时随机挑一个负载低的节点第二个副本放同一机架的不同节点第三个副本放另一个机架下的随机节点。两个副本为了容灾分散到两个机架两个副本为了性能留在一个机架内避免了跨机架流量打满。这个策略是hdfs-site.xml里的dfs.replication和机架感知脚本共同决定的没有配置机架拓扑时所有节点被当成同一个机架三副本会全部落在同一机架容灾能力归零。读取流程比写入简单得多没有管道概念。客户端请求 NameNode 拿文件块和副本位置列表NameNode 返回按网络距离排序的 DataNode 列表客户端和排在最前面的节点建立连接读数据。读的过程中逐块进行 CRC32 校验校验失败会尝试列表里的下一个副本。这解释了为什么 fsck 报告里文件显示“healthy”但仍然可能读到坏数据——实际上读不出来因为校验失败会触发重试到好副本用户无感。4.4 块大小与副本系数不是越大越好实验报告问答环节的高频问题“块大小设置成 256 MB 有什么影响”这需要分清两个层面。块越大NameNode 存储的块元数据越少同样大小文件块数少对大文件友好但块越大MapReduce 对单个块的并行度越低一个块只能被一个 Map 任务处理。块越小并行度高但元数据膨胀大量小文件会把 NameNode 的堆内存撑爆。默认 128 MB 是在元数据开销和计算并行度之间平衡的结果。副本系数同理3 副本已经是绝大多数场景的默认选择太大浪费空间太小丢数据后没地方恢复。5. 常见问题排查五个让集群“假死”的真实坑5.1 格式化后集群连不上clusterID 不一致现象第二次格式化之后DataNode 进程活着但 jps 里 NamendNode 起不来日志不断提示 DataNode 拒绝连接或 Web UI 上 DataNode 列表为 0。原因每次hdfs namenode -format会重新生成一个新的 clusterID写入到 NameNode 的 VERSION 文件里。而 DataNode 侧的 VERSION 文件还保留着第一次格式化时的 clusterID两边对不上DataNode 的上报被 NameNode 无视。解决停止整个集群分别找到 dfs.name.dir 和 dfs.data.dir 目录把两个目录下的 current 文件夹完整删除再重新执行hdfs namenode -format并start-dfs.sh。如果是三节点真实集群三台机器的 data 目录都要同步清理否则两边 clusterID 还是对不上。真实生产环境里严禁随意重新格式化格式化会清空整个文件系统元数据数据全丢。5.2 上传文件卡死然后报错写管道超时现象hdfs dfs -put执行后长时间不见进度终端像是挂住最后抛出 SocketTimeoutException 或 AlreadyBeingCreatedException。原因客户端向 NameNode 发送 create 请求成功后NameNode 会记录文件“正在创建”如果后续写管道迟迟建立不起来或写一半断掉客户端崩溃退出租约没有正常释放NameNode 里残留处于“正在写入”状态的文件条目。下次再用同一路径上传NameNode 判定文件仍被旧租约占用直接拒绝。解决先看文件系统里同名路径是否存在用hdfs dfs -ls -R核实然后用 fsck 查看这个路径的租约状态。确认是残留租约后执行hdfs debug recoverLease -path /user/hadoop/input/test.txt -retries 3强制恢复租约之后再重新 put。伪分布式单节点上常用更简单的办法——删除残留文件再重传但删不掉时NameNode 还在等租约释放就要走 debug 命令。5.3 集群卡在安全模式出不来块上报没达标现象启动后不管等多久hdfs dfsadmin -safemode get始终返回 ONWeb UI 提示 Safe mode is ON任何写操作都被拒绝。原因安全模式退出条件是已上报的块数量占总块数量百分比达到dfs.namenode.safemode.threshold-pct默认 99.9%。DataNode 进程没起来、防火墙挡了块报告端口、磁盘满了写不进临时文件都会导致上报不齐。解决先jps确认 DataNode 是否存在不存在则查 DataNode 日志$HADOOP_HOME/logs/hadoop--datanode-.log常见是端口占用或 Java 堆内存不足。都正常仍卡住时可以用hdfs dfsadmin -safemode leave手动强制退出但这属于治标下次重启大概率还会卡必须回到日志查根因。5.4 fsck 报告块健康但文件读不了校验和损坏现象文件所有块状态 HEALTHY但-cat或-get过程中报 ChecksumException读出来的内容损坏。原因fsck 检查的是块的元数据和副本数不校验文件内容。某个块的数据写入时和校验和不匹配比如磁盘静默损坏或进程 kill 在写一半时该块在 fsck 里仍显示健康因为 fsck 不读块内容。解决对损坏文件执行hdfs dfs -get时读到哪个块报错在报错信息里定位块 ID确认是哪个 DataNode 的哪个块如果还有其他副本把坏副本文件删掉让 NameNode 重新复制一份正常副本如果只有一份副本且已损坏这个文件无法恢复只能从源头重新上传。这体现了三副本在生产环境的意义也是实验报告里可以写的延伸思考。5.5 节点配置齐全却显示副本不足机架感知未配置现象真实三节点集群启动后上传的文件在 fsck 里显示 UNDER REPLICATED副本数一直补不到 3。原因没有配置机架感知时所有节点被看作同一个机架NameNode 挑选副本时全部落在一个机架内。三副本都放在同一机架确实能写满三个副本但如果其中一个节点挂了NameNode 找不到“足够远”的节点来补副本就一直停在 UNDER REPLICATED 状态。解决在topology.script.file.name配置项里指定一个机架映射脚本脚本对每个节点 IP 或主机名返回机架标识让 NameNode 感知到跨机架的节点。脚本本身用 shell 写几十行就能跑实验环境把三个节点分别映射到 /rack1、/rack2、/rack3重启集群后重新上传测试文件fsck 会显示副本数恢复为 3。6. 用 fsck 和文件指纹给实验结果做验收6.1 fsck 报告的三个必看指标实验做完不是命令跑完就结束必须用一个可量化的方式验证结果。hdfs fsck /user/hadoop -files -blocks -locations是 HDFS 自带的体检工具输出末尾是一行汇总信息重点关注三个数值。Health Status 显示 HEALTHY 表示所有块副本数满足要求没有缺失Under-replicated blocks 是 0 说明副本全数补齐Missing blocks 是 0 说明没有块损坏或丢失。实验环境如果 Health Status 是 CORRUPT损坏或 UNDER REPLICATED副本不足八成是副本数配置或节点故障问题按第 5 章的方法排查。三个指标全部达标后再把输出里任意一个文件的 block 列表截图或保存下来作为实验报告里“写流程验证”的佐证——它同时展示了文件被切成哪几个块、每一块的副本落在哪台机器对应 4.1 节的放置策略。6.2 用块文件和 md5 做双层验证fsck 只验证块的元数据状态不验证数据内容完整。要确实验证上传的数据和本地原数据一致需要在 HDFS 层面和本地层面各做一遍指纹比对。# HDFS 侧计算块文件的 CRC 校验信息 hdfs fsck /user/hadoop/input/test.txt -files -blocks -locations | grep test.txt # 本地源文件指纹 md5sum /tmp/test.txt # 从 HDFS 下载后再次计算指纹两次比对 hdfs dfs -get /user/hadoop/input/test.txt /tmp/check.txt md5sum /tmp/check.txt两个 md5 值完全一致说明数据经历了上传、管道复制、落盘、读取全链路没有发生损坏。这一步看起来多余但对于做实验的人来说它能排除“数字看起来对实际数据已坏”的假阳性。我在做三节点集群验证时还会多做一步删除其中一个 DataNode 上的某个块副本等几十秒后重跑 fsck观察 NameNode 如何自动补副本这个验证能让三副本机制的印象深刻得多。6.3 快照与配额两个容易写进报告的高级操作如果实验课时充足建议把快照Snapshot和目录配额Quota也做一遍这两个操作在真实工作里使用频率很高但教科书很少展开。快照是对目录做只读备份不占额外空间只有文件变更后才产生差异数据。目录配额用来限制目录存储的文件数量防止某个业务线无节制写入把集群磁盘撑爆。两个操作结合就构成了 HDFS 最轻量的“备份 限流”组合。# 允许对 /user/hadoop/data 目录创建快照 hdfs dfsadmin -allowSnapshot /user/hadoop/data # 创建名为 snap1 的快照 hdfs dfs -createSnapshot /user/hadoop/data snap1 # 对目录设置文件数上限为 100 hdfs dfsadmin -setQuota 100 /user/hadoop/data快照创建后任何误删操作都能通过hdfs dfs -ls /user/hadoop/data/.snapshot/snap1/找回原文件。从那以后我每次带新人做实验都会强制他们先建快照再做大量删除操作这已经是防止误删的习惯性动作。配额超出时写入会被拒绝报错提示配额超限而不是任何权限错误。做完这两个操作实验报告里可以写的内容就不只是基础命令了还能延伸到 HDFS 在生产环境的日常管理手段。希望这份实践笔记对你有帮助不管是在头歌平台上做实训还是在自己搭的伪分布式集群上折腾一定要亲手跑一遍 fsck 和 md5sum这比多敲十遍 put/get 都更有价值。本文还有配套的精品资源点击获取