简介这份资源是《大数据技术原理与应用》课程实验二的完整报告文档面向正在学习Hadoop与大数据基础的高校学生及自学者帮助解决HDFS Shell命令与Java API操作入门难、实验流程不清晰的问题。压缩包内仅含1个docx文件约3.4MB以实验报告形式呈现涵盖实验环境说明、Shell命令操作与Java编程实现两大模块。报告基于Ubuntu Kylin 16.04、Hadoop 3.1.3、JDK 1.8与Eclipse环境详细记录了文件上传、存在性判断、追加与覆盖等HDFS常用操作并给出完整的Java代码示例涉及Configuration、FileSystem、Path等核心类的使用。目前已有10214人学习下载适合作为HDFS入门练习的参考模板也可为后续MapReduce与HBase学习打下基础。1. 从一次“数据不见了”的排查说起HDFS 操作到底在练什么刚接触大数据平台的人第一次登录集群节点敲下hdfs dfs -ls /时多半会觉得这不过是个“远程文件管理器”。直到某天你发现刚上传的文件在NameNode里显示正常DataNode磁盘却对不上号或者put一个 2GB 文件卡在 99% 不动才会意识到 HDFS 操作背后是一整套分布式读写流程在支撑。所谓“熟悉常用的 HDFS 操作”练的不是背命令而是理解一次put、get、rm背后客户端、NameNode、DataNode 三方怎么协商、数据块怎么切、副本怎么落、元数据怎么改。这篇笔记面向正在做实验课、准备 HDFS 编程实践、或者要接手一套离线数仓存储层的工程师把命令、读写流程、参数边界和踩坑点一次讲透让你在单机和伪分布式环境里都能复现。2. HDFS 读写流程命令敲下去之后到底发生了什么2.1 写流程从put到三个副本落盘很多人背过“客户端先请求 NameNode再写 DataNode”但真到调优和排错时这个粒度远远不够。一次完整的写操作常见做法是拆成七步客户端调用DistributedFileSystem.create()NameNode 校验权限和路径后在元数据里新建文件条目但此时不分配任何块客户端拿到FSDataOutputStream开始按dfs.blocksize切分数据每写满一个块客户端向 NameNode 请求addBlockNameNode 返回一组 DataNode 位置默认 3 副本按机架感知策略排布客户端与第一个 DataNode 建立 Pipeline第一个再连第二个第二个连第三个数据以 Packet 为单位沿 Pipeline 流动每级写入本地后回传 ACK全部块写完客户端通知 NameNode 关闭文件元数据落盘。这里有两个容易被忽略的点。第一NameNode 不参与数据流它只发位置所以 NameNode 内存压力和数据传输带宽是两条独立的瓶颈线。第二Pipeline 是串行的任何一个 DataNode 慢整条链路都慢这就是为什么put大文件时经常卡在某个百分比不动——不是网络断了是某个副本节点在拖后腿。# 上传本地文件到 HDFS并观察块信息 hdfs dfs -put -f /home/data/sample_2g.log /user/test/input/ # 查看文件被切成了几个块以及每个块的副本分布 hdfs fsck /user/test/input/sample_2g.log -files -blocks -locations-put的-f表示覆盖已存在文件不加会直接报File already exists。fsck是排查块问题的第一工具-blocks列出块 ID 和大小-locations列出每个块所在的 DataNode。如果某个块只有 2 个副本fsck会标记Under-replicated这时候别急着重传先看那个掉线的 DataNode 是不是只是心跳超时。2.2 读流程为什么get有时比put还慢读流程比写流程少一次元数据修改但多了一层“就近读取”的判断。客户端调用open()NameNode 返回文件所有块的位置列表按距离客户端排序客户端选最近的 DataNode 发起readBlock如果该节点故障或超时自动切换到下一个副本读完一个块再读下一个直到文件结束。读慢的典型原因有三个一是客户端不在集群网络内所有“就近”都变成跨网段二是块大小设置过小导致 NameNode 返回的位置列表过长元数据交互次数暴增三是大量小文件每个文件都要单独走一次openNameNode 的 QPS 直接被打满。这也是为什么 HDFS 不适合存海量小文件不是存不下是元数据扛不住。# 读取 HDFS 文件到本地并统计耗时 time hdfs dfs -get /user/test/input/sample_2g.log /home/data/output/ # 查看文件块大小和副本系数 hdfs dfs -stat blockSize%o, replication%r, size%b /user/test/input/sample_2g.log-stat的格式串里%o是块大小字节%r是副本数%b是文件大小。如果发现blockSize是 64MB 而不是 128MB说明集群用的是旧版默认值大文件会被切得更碎读的时候元数据交互更多。2.3 常用命令的“最小可用集”与参数含义HDFS 命令有几十个但实验和日常运维真正高频的就那么十来个。下面这张表按“操作对象”分类把命令、典型参数和容易搞错的点列清楚。命令作用关键参数易错点hdfs dfs -ls列出目录-R递归-h人类可读不加-h看到的是字节数容易误判大小hdfs dfs -put上传-f覆盖-p保留权限时间本地路径在前HDFS 路径在后反了会报错hdfs dfs -get下载-f覆盖本地-p保留属性下载目录不存在时不会自动创建hdfs dfs -mkdir建目录-p递归创建不加-p父目录不存在会失败hdfs dfs -rm删文件-r递归删目录-skipTrash跳过回收站默认进回收站-skipTrash删了不可恢复hdfs dfs -mv移动/重命名无特殊参数跨目录移动是元数据操作很快hdfs dfs -cp复制-f覆盖大文件复制会真实走数据流很慢hdfs dfs -cat查看内容-配合管道大文件别直接 cat会刷屏hdfs dfs -tail看末尾-f持续跟踪适合看日志尾部hdfs dfs -du统计大小-h-s汇总-du算实际占用-ls看的是逻辑大小提示-rm和-rm -r的区别是血泪经验删目录不加-r会直接报错但加了-r又容易手滑删掉整个目录。生产环境建议先-ls确认路径再执行删除。3. 在伪分布式环境里把 HDFS 操作跑通从零到可复现3.1 环境准备与最小配置伪分布式是实验课最常用的形态一台机器同时跑 NameNode、DataNode、ResourceManager。核心配置文件就三个core-site.xml指定fs.defaultFShdfs-site.xml指定副本数和数据目录hadoop-env.sh指定 Java 路径。副本数在伪分布式里必须设成 1否则会一直报“副本不足”因为只有一个 DataNode。!-- core-site.xml指定默认文件系统为本地 HDFS -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configuration!-- hdfs-site.xml伪分布式副本数必须为 1 -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/datanode/value /property /configurationhadoop.tmp.dir是很多“启动后莫名失败”的根源默认值在/tmp下系统重启就被清空导致 NameNode 元数据丢失。改成持久化目录后格式化一次就能长期使用。dfs.replication设成 1 不是偷懒是伪分布式只有一个 DataNode设成 3 会永远处于副本不足状态。3.2 格式化与启动顺序错了就白干启动顺序必须是先格式化 NameNode再启动 HDFS最后验证。格式化只能做一次重复格式化会导致 DataNode 的 clusterID 和 NameNode 不一致直接报Incompatible clusterIDs。# 1. 格式化 NameNode只做一次 hdfs namenode -format # 2. 启动 HDFS 守护进程 start-dfs.sh # 3. 验证进程是否齐全 jps # 期望看到 NameNode、DataNode、SecondaryNameNode 三个进程 # 4. 创建实验目录 hdfs dfs -mkdir -p /user/test/input hdfs dfs -ls /jps是排查启动问题的第一命令。如果只有 NameNode 没有 DataNode去看 DataNode 日志常见原因是data.dir权限不对或者 clusterID 不匹配。如果三个进程都有但ls /报Connection refused检查fs.defaultFS的端口和core-site.xml是否被正确加载。3.3 一次完整的上传、查看、下载、删除闭环把命令串起来跑一遍比单独背命令有用得多。下面这个脚本模拟了实验里最常见的操作序列每一步都有明确的验证点。#!/bin/bash # HDFS 基础操作闭环演示 # 1. 准备本地测试文件 echo hello hdfs, this is a test file for experiment /home/data/test.txt # 2. 上传到 HDFS hdfs dfs -put -f /home/data/test.txt /user/test/input/ # 3. 验证上传结果查看文件列表和内容 hdfs dfs -ls /user/test/input/ hdfs dfs -cat /user/test/input/test.txt # 4. 查看文件的块信息和副本状态 hdfs fsck /user/test/input/test.txt -files -blocks # 5. 下载回本地另一个目录 mkdir -p /home/data/download hdfs dfs -get /user/test/input/test.txt /home/data/download/ # 6. 对比本地和 HDFS 内容是否一致 diff /home/data/test.txt /home/data/download/test.txt echo 内容一致 # 7. 删除 HDFS 文件跳过回收站实验环境常用 hdfs dfs -rm -skipTrash /user/test/input/test.txt # 8. 确认删除 hdfs dfs -ls /user/test/input/这个脚本里第 4 步的fsck是很多人会跳过的但它能告诉你文件被切成了几个块、每个块在哪个 DataNode 上。小文件通常只有 1 个块但如果你上传的是大文件这里就能看到块分布。第 6 步的diff是验证数据一致性的最直接手段比肉眼比对可靠。第 7 步的-skipTrash在实验环境里能省去清空回收站的步骤但生产环境慎用。3.4 用 Java API 做一次编程实践实验课通常还会要求用 Java API 操作 HDFS因为命令行只是封装真正做数据管道时还是要写代码。核心类就四个Configuration、FileSystem、Path、FSDataOutputStream。import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; import org.apache.hadoop.fs.FSDataOutputStream; import java.io.BufferedWriter; import java.io.OutputStreamWriter; public class HdfsWriteDemo { public static void main(String[] args) throws Exception { // 加载配置会自动读取 core-site.xml 和 hdfs-site.xml Configuration conf new Configuration(); // 显式指定避免本地环境读不到配置文件 conf.set(fs.defaultFS, hdfs://localhost:9000); // 获取 FileSystem 实例 FileSystem fs FileSystem.get(conf); // 目标路径 Path target new Path(/user/test/input/java_api_demo.txt); // 创建输出流并写入内容 try (FSDataOutputStream out fs.create(target, true); BufferedWriter writer new BufferedWriter(new OutputStreamWriter(out))) { writer.write(written by java api\n); writer.write(second line for hdfs experiment\n); } // 验证文件是否存在 System.out.println(exists: fs.exists(target)); System.out.println(block size: fs.getFileStatus(target).getBlockSize()); fs.close(); } }fs.create(target, true)的第二个参数是overwrite设为true才能覆盖已存在文件。getFileStatus返回的FileStatus对象里包含块大小、副本数、修改时间等元数据是编程时最常用的信息载体。这段代码跑通后把create换成open就是读操作换成delete就是删除操作API 设计非常对称。4. HDFS 操作避坑5 个真实翻车现场4.1 坑一重复格式化导致 DataNode 起不来现象执行start-dfs.sh后jps只有 NameNode没有 DataNode日志里报Incompatible clusterIDs。原因NameNode 格式化会生成新的 clusterID而 DataNode 的data.dir里还保留着旧的 clusterID两者不匹配DataNode 拒绝启动。解决删掉 DataNode 的数据目录dfs.datanode.data.dir指向的路径重新启动。如果数据不重要也可以直接重新格式化整个集群。预防办法是格式化前确认hadoop.tmp.dir和dfs.namenode.name.dir是持久化目录且只格式化一次。4.2 坑二put大文件卡在某个百分比不动现象上传 2GB 文件进度卡在 87% 或 99% 长时间不动最后报PipelineException。原因Pipeline 中某个 DataNode 磁盘满、网络抖动或进程假死导致 ACK 回传超时。HDFS 默认的超时时间是 60 秒超过后会重建 Pipeline但如果多个节点同时有问题就会反复重试。解决先用hdfs fsck /path -locations看块分布确认是哪个节点的问题再登录该节点看磁盘使用率和 DataNode 日志。临时办法是调大dfs.client.socket-timeout但根治还是要解决节点本身的资源问题。4.3 坑三-rm删了文件但空间没释放现象执行hdfs dfs -rm /path/file后du显示目录大小没变集群空间也没释放。原因HDFS 默认开启回收站删除的文件被移到/user/user/.Trash下保留一段时间后才真正删除。这是保护机制不是 bug。解决确认不需要恢复后执行hdfs dfs -expunge清空回收站或者删除时加-skipTrash。生产环境建议保留回收站但定期清理避免 Trash 目录无限膨胀。4.4 坑四小文件太多导致 NameNode 内存告警现象上传了几十万个小文件后NameNode 响应变慢jps看到 NameNode 进程内存持续上涨最终 OOM。原因每个文件、每个块、每个副本在 NameNode 内存里都占约 150 字节小文件不会减少元数据条目反而因为文件数多导致条目总数暴增。解决用hdfs dfs -count统计文件数用hadoop archive或CombineFileInputFormat做小文件合并。更根本的做法是在数据入口就做聚合别让原始小文件直接进 HDFS。4.5 坑五-get下载目录不存在导致失败现象hdfs dfs -get /user/test/file.txt /home/data/newdir/报No such file or directory。原因-get不会自动创建本地目录目标目录必须提前存在。解决先mkdir -p创建本地目录再执行-get。或者用-get到已存在的目录让 HDFS 自动用源文件名命名。这个坑在脚本里特别常见因为脚本执行时当前目录和交互式登录可能不一样。5. 进阶技巧用fsck和balancer把 HDFS 操作从“能用”推到“可控”命令敲熟之后真正的分水岭在于你能不能判断集群的健康状态。fsck和balancer是两个最容易被忽略但最有价值的工具。fsck不只是看块数量加上-move可以把损坏的块移到/lostfound加上-delete可以删除损坏块加上-openforwrite可以列出正在写入的文件。日常巡检我一般会跑这三条# 1. 全集群健康检查只看汇总 hdfs fsck / -summary # 2. 列出所有副本不足的块 hdfs fsck / -blocks | grep -i under-replicated # 3. 列出所有损坏的块 hdfs fsck / -list-corruptfileblocks-summary的输出里重点看Under-replicated blocks和Corrupt blocks两个数字。前者大于 0 说明有 DataNode 掉线或磁盘故障后者大于 0 说明数据已经损坏需要从副本恢复或从源头重传。balancer则是解决 DataNode 之间磁盘使用率不均的问题默认阈值是 10%也就是说如果两个节点磁盘使用率差超过 10%就会触发数据迁移。# 启动 balancer阈值设为 5%带宽限制 50MB/s hdfs balancer -threshold 5 -bandwidth 50-threshold越小均衡越彻底但迁移量越大-bandwidth控制迁移速度避免占满业务带宽。生产环境建议在业务低峰期跑阈值设 5% 到 10% 之间。跑完之后再用hdfs dfsadmin -report看各节点的磁盘使用率确认是否真的均衡了。还有一个容易被忽略的技巧是-D参数动态覆盖配置。比如临时把副本数从 3 改成 2不用改配置文件直接hdfs dfs -D dfs.replication2 -put /home/data/bigfile.log /user/test/input/这个文件就会以 2 副本写入后续其他文件不受影响。做实验时经常需要这种“一次性覆盖”比改配置文件再重启快得多。但要注意-D只对当前命令生效不会持久化所以别指望用它来改集群默认值。最后说一个我自己的习惯每次做完一组 HDFS 操作不管成功失败都跑一次hdfs fsck /user/test -summary。这个动作花不了几秒但能让你在问题扩大之前发现副本异常。HDFS 的很多故障不是突然发生的而是从“一个块副本不足”慢慢演变成“整个文件不可读”。早发现早处理比事后从备份恢复省事得多。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是《大数据技术原理与应用》课程实验二的完整报告文档面向正在学习Hadoop与大数据基础的高校学生及自学者帮助解决HDFS Shell命令与Java API操作入门难、实验流程不清晰的问题。压缩包内仅含1个docx文件约3.4MB以实验报告形式呈现涵盖实验环境说明、Shell命令操作与Java编程实现两大模块。报告基于Ubuntu Kylin 16.04、Hadoop 3.1.3、JDK 1.8与Eclipse环境详细记录了文件上传、存在性判断、追加与覆盖等HDFS常用操作并给出完整的Java代码示例涉及Configuration、FileSystem、Path等核心类的使用。目前已有10214人学习下载适合作为HDFS入门练习的参考模板也可为后续MapReduce与HBase学习打下基础。1. 从一次“数据不见了”的排查说起HDFS 操作到底在练什么刚接触大数据平台的人第一次登录集群节点敲下hdfs dfs -ls /时多半会觉得这不过是个“远程文件管理器”。直到某天你发现刚上传的文件在NameNode里显示正常DataNode磁盘却对不上号或者put一个 2GB 文件卡在 99% 不动才会意识到 HDFS 操作背后是一整套分布式读写流程在支撑。所谓“熟悉常用的 HDFS 操作”练的不是背命令而是理解一次put、get、rm背后客户端、NameNode、DataNode 三方怎么协商、数据块怎么切、副本怎么落、元数据怎么改。这篇笔记面向正在做实验课、准备 HDFS 编程实践、或者要接手一套离线数仓存储层的工程师把命令、读写流程、参数边界和踩坑点一次讲透让你在单机和伪分布式环境里都能复现。2. HDFS 读写流程命令敲下去之后到底发生了什么2.1 写流程从put到三个副本落盘很多人背过“客户端先请求 NameNode再写 DataNode”但真到调优和排错时这个粒度远远不够。一次完整的写操作常见做法是拆成七步客户端调用DistributedFileSystem.create()NameNode 校验权限和路径后在元数据里新建文件条目但此时不分配任何块客户端拿到FSDataOutputStream开始按dfs.blocksize切分数据每写满一个块客户端向 NameNode 请求addBlockNameNode 返回一组 DataNode 位置默认 3 副本按机架感知策略排布客户端与第一个 DataNode 建立 Pipeline第一个再连第二个第二个连第三个数据以 Packet 为单位沿 Pipeline 流动每级写入本地后回传 ACK全部块写完客户端通知 NameNode 关闭文件元数据落盘。这里有两个容易被忽略的点。第一NameNode 不参与数据流它只发位置所以 NameNode 内存压力和数据传输带宽是两条独立的瓶颈线。第二Pipeline 是串行的任何一个 DataNode 慢整条链路都慢这就是为什么put大文件时经常卡在某个百分比不动——不是网络断了是某个副本节点在拖后腿。# 上传本地文件到 HDFS并观察块信息 hdfs dfs -put -f /home/data/sample_2g.log /user/test/input/ # 查看文件被切成了几个块以及每个块的副本分布 hdfs fsck /user/test/input/sample_2g.log -files -blocks -locations-put的-f表示覆盖已存在文件不加会直接报File already exists。fsck是排查块问题的第一工具-blocks列出块 ID 和大小-locations列出每个块所在的 DataNode。如果某个块只有 2 个副本fsck会标记Under-replicated这时候别急着重传先看那个掉线的 DataNode 是不是只是心跳超时。2.2 读流程为什么get有时比put还慢读流程比写流程少一次元数据修改但多了一层“就近读取”的判断。客户端调用open()NameNode 返回文件所有块的位置列表按距离客户端排序客户端选最近的 DataNode 发起readBlock如果该节点故障或超时自动切换到下一个副本读完一个块再读下一个直到文件结束。读慢的典型原因有三个一是客户端不在集群网络内所有“就近”都变成跨网段二是块大小设置过小导致 NameNode 返回的位置列表过长元数据交互次数暴增三是大量小文件每个文件都要单独走一次openNameNode 的 QPS 直接被打满。这也是为什么 HDFS 不适合存海量小文件不是存不下是元数据扛不住。# 读取 HDFS 文件到本地并统计耗时 time hdfs dfs -get /user/test/input/sample_2g.log /home/data/output/ # 查看文件块大小和副本系数 hdfs dfs -stat blockSize%o, replication%r, size%b /user/test/input/sample_2g.log-stat的格式串里%o是块大小字节%r是副本数%b是文件大小。如果发现blockSize是 64MB 而不是 128MB说明集群用的是旧版默认值大文件会被切得更碎读的时候元数据交互更多。2.3 常用命令的“最小可用集”与参数含义HDFS 命令有几十个但实验和日常运维真正高频的就那么十来个。下面这张表按“操作对象”分类把命令、典型参数和容易搞错的点列清楚。命令作用关键参数易错点hdfs dfs -ls列出目录-R递归-h人类可读不加-h看到的是字节数容易误判大小hdfs dfs -put上传-f覆盖-p保留权限时间本地路径在前HDFS 路径在后反了会报错hdfs dfs -get下载-f覆盖本地-p保留属性下载目录不存在时不会自动创建hdfs dfs -mkdir建目录-p递归创建不加-p父目录不存在会失败hdfs dfs -rm删文件-r递归删目录-skipTrash跳过回收站默认进回收站-skipTrash删了不可恢复hdfs dfs -mv移动/重命名无特殊参数跨目录移动是元数据操作很快hdfs dfs -cp复制-f覆盖大文件复制会真实走数据流很慢hdfs dfs -cat查看内容-配合管道大文件别直接 cat会刷屏hdfs dfs -tail看末尾-f持续跟踪适合看日志尾部hdfs dfs -du统计大小-h-s汇总-du算实际占用-ls看的是逻辑大小提示-rm和-rm -r的区别是血泪经验删目录不加-r会直接报错但加了-r又容易手滑删掉整个目录。生产环境建议先-ls确认路径再执行删除。3. 在伪分布式环境里把 HDFS 操作跑通从零到可复现3.1 环境准备与最小配置伪分布式是实验课最常用的形态一台机器同时跑 NameNode、DataNode、ResourceManager。核心配置文件就三个core-site.xml指定fs.defaultFShdfs-site.xml指定副本数和数据目录hadoop-env.sh指定 Java 路径。副本数在伪分布式里必须设成 1否则会一直报“副本不足”因为只有一个 DataNode。!-- core-site.xml指定默认文件系统为本地 HDFS -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configuration!-- hdfs-site.xml伪分布式副本数必须为 1 -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/datanode/value /property /configurationhadoop.tmp.dir是很多“启动后莫名失败”的根源默认值在/tmp下系统重启就被清空导致 NameNode 元数据丢失。改成持久化目录后格式化一次就能长期使用。dfs.replication设成 1 不是偷懒是伪分布式只有一个 DataNode设成 3 会永远处于副本不足状态。3.2 格式化与启动顺序错了就白干启动顺序必须是先格式化 NameNode再启动 HDFS最后验证。格式化只能做一次重复格式化会导致 DataNode 的 clusterID 和 NameNode 不一致直接报Incompatible clusterIDs。# 1. 格式化 NameNode只做一次 hdfs namenode -format # 2. 启动 HDFS 守护进程 start-dfs.sh # 3. 验证进程是否齐全 jps # 期望看到 NameNode、DataNode、SecondaryNameNode 三个进程 # 4. 创建实验目录 hdfs dfs -mkdir -p /user/test/input hdfs dfs -ls /jps是排查启动问题的第一命令。如果只有 NameNode 没有 DataNode去看 DataNode 日志常见原因是data.dir权限不对或者 clusterID 不匹配。如果三个进程都有但ls /报Connection refused检查fs.defaultFS的端口和core-site.xml是否被正确加载。3.3 一次完整的上传、查看、下载、删除闭环把命令串起来跑一遍比单独背命令有用得多。下面这个脚本模拟了实验里最常见的操作序列每一步都有明确的验证点。#!/bin/bash # HDFS 基础操作闭环演示 # 1. 准备本地测试文件 echo hello hdfs, this is a test file for experiment /home/data/test.txt # 2. 上传到 HDFS hdfs dfs -put -f /home/data/test.txt /user/test/input/ # 3. 验证上传结果查看文件列表和内容 hdfs dfs -ls /user/test/input/ hdfs dfs -cat /user/test/input/test.txt # 4. 查看文件的块信息和副本状态 hdfs fsck /user/test/input/test.txt -files -blocks # 5. 下载回本地另一个目录 mkdir -p /home/data/download hdfs dfs -get /user/test/input/test.txt /home/data/download/ # 6. 对比本地和 HDFS 内容是否一致 diff /home/data/test.txt /home/data/download/test.txt echo 内容一致 # 7. 删除 HDFS 文件跳过回收站实验环境常用 hdfs dfs -rm -skipTrash /user/test/input/test.txt # 8. 确认删除 hdfs dfs -ls /user/test/input/这个脚本里第 4 步的fsck是很多人会跳过的但它能告诉你文件被切成了几个块、每个块在哪个 DataNode 上。小文件通常只有 1 个块但如果你上传的是大文件这里就能看到块分布。第 6 步的diff是验证数据一致性的最直接手段比肉眼比对可靠。第 7 步的-skipTrash在实验环境里能省去清空回收站的步骤但生产环境慎用。3.4 用 Java API 做一次编程实践实验课通常还会要求用 Java API 操作 HDFS因为命令行只是封装真正做数据管道时还是要写代码。核心类就四个Configuration、FileSystem、Path、FSDataOutputStream。import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; import org.apache.hadoop.fs.FSDataOutputStream; import java.io.BufferedWriter; import java.io.OutputStreamWriter; public class HdfsWriteDemo { public static void main(String[] args) throws Exception { // 加载配置会自动读取 core-site.xml 和 hdfs-site.xml Configuration conf new Configuration(); // 显式指定避免本地环境读不到配置文件 conf.set(fs.defaultFS, hdfs://localhost:9000); // 获取 FileSystem 实例 FileSystem fs FileSystem.get(conf); // 目标路径 Path target new Path(/user/test/input/java_api_demo.txt); // 创建输出流并写入内容 try (FSDataOutputStream out fs.create(target, true); BufferedWriter writer new BufferedWriter(new OutputStreamWriter(out))) { writer.write(written by java api\n); writer.write(second line for hdfs experiment\n); } // 验证文件是否存在 System.out.println(exists: fs.exists(target)); System.out.println(block size: fs.getFileStatus(target).getBlockSize()); fs.close(); } }fs.create(target, true)的第二个参数是overwrite设为true才能覆盖已存在文件。getFileStatus返回的FileStatus对象里包含块大小、副本数、修改时间等元数据是编程时最常用的信息载体。这段代码跑通后把create换成open就是读操作换成delete就是删除操作API 设计非常对称。4. HDFS 操作避坑5 个真实翻车现场4.1 坑一重复格式化导致 DataNode 起不来现象执行start-dfs.sh后jps只有 NameNode没有 DataNode日志里报Incompatible clusterIDs。原因NameNode 格式化会生成新的 clusterID而 DataNode 的data.dir里还保留着旧的 clusterID两者不匹配DataNode 拒绝启动。解决删掉 DataNode 的数据目录dfs.datanode.data.dir指向的路径重新启动。如果数据不重要也可以直接重新格式化整个集群。预防办法是格式化前确认hadoop.tmp.dir和dfs.namenode.name.dir是持久化目录且只格式化一次。4.2 坑二put大文件卡在某个百分比不动现象上传 2GB 文件进度卡在 87% 或 99% 长时间不动最后报PipelineException。原因Pipeline 中某个 DataNode 磁盘满、网络抖动或进程假死导致 ACK 回传超时。HDFS 默认的超时时间是 60 秒超过后会重建 Pipeline但如果多个节点同时有问题就会反复重试。解决先用hdfs fsck /path -locations看块分布确认是哪个节点的问题再登录该节点看磁盘使用率和 DataNode 日志。临时办法是调大dfs.client.socket-timeout但根治还是要解决节点本身的资源问题。4.3 坑三-rm删了文件但空间没释放现象执行hdfs dfs -rm /path/file后du显示目录大小没变集群空间也没释放。原因HDFS 默认开启回收站删除的文件被移到/user/user/.Trash下保留一段时间后才真正删除。这是保护机制不是 bug。解决确认不需要恢复后执行hdfs dfs -expunge清空回收站或者删除时加-skipTrash。生产环境建议保留回收站但定期清理避免 Trash 目录无限膨胀。4.4 坑四小文件太多导致 NameNode 内存告警现象上传了几十万个小文件后NameNode 响应变慢jps看到 NameNode 进程内存持续上涨最终 OOM。原因每个文件、每个块、每个副本在 NameNode 内存里都占约 150 字节小文件不会减少元数据条目反而因为文件数多导致条目总数暴增。解决用hdfs dfs -count统计文件数用hadoop archive或CombineFileInputFormat做小文件合并。更根本的做法是在数据入口就做聚合别让原始小文件直接进 HDFS。4.5 坑五-get下载目录不存在导致失败现象hdfs dfs -get /user/test/file.txt /home/data/newdir/报No such file or directory。原因-get不会自动创建本地目录目标目录必须提前存在。解决先mkdir -p创建本地目录再执行-get。或者用-get到已存在的目录让 HDFS 自动用源文件名命名。这个坑在脚本里特别常见因为脚本执行时当前目录和交互式登录可能不一样。5. 进阶技巧用fsck和balancer把 HDFS 操作从“能用”推到“可控”命令敲熟之后真正的分水岭在于你能不能判断集群的健康状态。fsck和balancer是两个最容易被忽略但最有价值的工具。fsck不只是看块数量加上-move可以把损坏的块移到/lostfound加上-delete可以删除损坏块加上-openforwrite可以列出正在写入的文件。日常巡检我一般会跑这三条# 1. 全集群健康检查只看汇总 hdfs fsck / -summary # 2. 列出所有副本不足的块 hdfs fsck / -blocks | grep -i under-replicated # 3. 列出所有损坏的块 hdfs fsck / -list-corruptfileblocks-summary的输出里重点看Under-replicated blocks和Corrupt blocks两个数字。前者大于 0 说明有 DataNode 掉线或磁盘故障后者大于 0 说明数据已经损坏需要从副本恢复或从源头重传。balancer则是解决 DataNode 之间磁盘使用率不均的问题默认阈值是 10%也就是说如果两个节点磁盘使用率差超过 10%就会触发数据迁移。# 启动 balancer阈值设为 5%带宽限制 50MB/s hdfs balancer -threshold 5 -bandwidth 50-threshold越小均衡越彻底但迁移量越大-bandwidth控制迁移速度避免占满业务带宽。生产环境建议在业务低峰期跑阈值设 5% 到 10% 之间。跑完之后再用hdfs dfsadmin -report看各节点的磁盘使用率确认是否真的均衡了。还有一个容易被忽略的技巧是-D参数动态覆盖配置。比如临时把副本数从 3 改成 2不用改配置文件直接hdfs dfs -D dfs.replication2 -put /home/data/bigfile.log /user/test/input/这个文件就会以 2 副本写入后续其他文件不受影响。做实验时经常需要这种“一次性覆盖”比改配置文件再重启快得多。但要注意-D只对当前命令生效不会持久化所以别指望用它来改集群默认值。最后说一个我自己的习惯每次做完一组 HDFS 操作不管成功失败都跑一次hdfs fsck /user/test -summary。这个动作花不了几秒但能让你在问题扩大之前发现副本异常。HDFS 的很多故障不是突然发生的而是从“一个块副本不足”慢慢演变成“整个文件不可读”。早发现早处理比事后从备份恢复省事得多。希望帮到你。本文还有配套的精品资源点击获取
