企业官网建设流程全解析

简介：完整记录了HDFS编程实践全过程的一份实验报告，面向正在学习Hadoop大数据技术、需要掌握HDFS文件操作的学生或开发者。内容围绕HDFS在Hadoop体系中的角色展开，涵盖常用Shell命令（如put、get、ls、rm、copyFromLocal等）以及基于Hadoop Java API的文件创建、写入、读取与删除操作，并配有实验环境配置、过程截图和详细说明，便于读者对照实操和排查问题。资源为单个docx文档，压缩包大小323KB，文档结构清晰，包含实验内容、目的、过程截图、总结及心得体会，可直接作为课程实验参考或复习资料。目前已有2910人学习下载，适合需要快速上手HDFS操作实践的人群。

1. 实验课的常见翻车点，都藏在HDFS编程实践这几个字里

Hadoop课程里最容易被低估的就是“实验二-HDFS编程实践”，不少人的心理预期是跑通几个命令就交差，真正拉开差距的其实是Java API操作分布式文件系统的能力边界。文件上传报错、Permission denied、块信息对不上，这些在平时的hdfs常用命令里根本露不出来，只有写到代码里才一个个冒出来。这篇笔记面向正在做HDFS编程实践、需要交实验报告或项目演示的读者，用一条自认为顺的路径把读写流程、API调用、fsck校验和参数避坑讲清楚——照着敲能跑，跑完敢在报告里写结论。

2. 跑通实验二的前置条件：环境、接入方式与用户身份

HDFS编程实践的第一步不是写代码，是把环境立住。很多翻车不是代码问题，是集群根本没起来、端口记错、用户身份不对，后面的所有操作全部白费。这一章先把最小环境、三种接入方式、用户身份这三件地基讲透。

2.1 伪分布式最小环境：配置文件与启动顺序

如果是在自己电脑上做实验，最常见的做法是搭一套伪分布式集群。这个模式是单机模拟完整集群，NameNode、DataNode、SecondaryNameNode都跑在同一个进程组里，够用且配置最少。核心是三个文件：core-site.xml指定文件系统入口，hdfs-site.xml控制副本数和NameNode地址，hadoop-env.sh里确认Java路径。

# 1. 配置 core-site.xml，指定默认文件系统为 hdfs:// <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration> # 2. 配置 hdfs-site.xml，副本数设1即可，伪分布式不设1会一直等待副本同步 <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///home/hadoop/data/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///home/hadoop/data/data</value> </property> </configuration>

配置完成后先格式化NameNode，再启动进程。格式化只做一次，重复格式化会清空元数据，这是hdfs编程实践里最常见的“后悔药”坑。

hdfs namenode -format start-dfs.sh jps

jps是Java进程查看命令，伪分布式下正常能看到NameNode、DataNode、SecondaryNameNode三个进程，缺哪个就单独排查哪个。这里有个经验：如果jps里只有NameNode没有DataNode，多半是dfs.datanode.data.dir目录权限不对或者目录没建出来，logs目录下的hadoop-hadoop-datanode-主机名.log会给出具体原因，别急着重启集群，先看日志。

2.2 三种接入方式怎么选：Shell、Java API、Web UI

实验二要求的“编程实践”，核心是Java API，但Shell命令是辅助验证工具，Web UI是可视化黑匣子，三种方式各有用途。Shell命令用来快速确认文件系统状态，比如上传、下载、删除；Java API用于在代码里完成同样的操作并捕获详细异常；Web UI用来人工核对块分布和副本健康度。

实际实验里我一般先用Shell把目录和文件准备好，再写Java代码去读写。不要一上来就写代码，那样出了问题你分不清是代码错了还是集群没起来。Shell里hdfs dfs -ls /能正常列目录，再进入编码环节，能省掉一半的排错时间。

2.3 用户身份与权限：先解决Permission denied

HDFS的权限模型和Linux很像，但有个关键差异：Java API连接时默认使用当前系统用户的身份。如果代码里用FileSystem.get(conf)获取文件系统实例，而当前Linux用户是root，访问默认的hdfs://时会以root身份去请求NameNode——伪分布式下如果HDFS超级用户不是这个身份，就会报权限错误。

// 方式一：代码里显式指定用户身份，适合交作业和demo场景 Configuration conf = new Configuration(); conf.set("fs.defaultFS", "hdfs://localhost:9000"); conf.set("dfs.client.use.datanode.hostname", "true"); FileSystem fs = FileSystem.get(new URI("hdfs://localhost:9000"), conf, "hadoop");

这段代码的要点是FileSystem.get的第三个参数“hadoop”，它指定了以哪个Linux系统用户身份访问HDFS。如果集群是hadoop用户启动的，这里就必须传hadoop，否则即使集群运行正常，代码也会报Permission denied。

提示：在实验环境里，如果所有进程都是用hadoop用户启动的，请统一用该用户执行Java程序，或在代码里指定该用户，不要用root硬闯。

3. HDFS读写流程拆解：从put命令到Java API的数据管道

这一章讲的是“数据到底走了哪条路”，因为不搞懂读写流程，写API代码就是在盲写。很多同学在hdfs和mapreduce综合实训里栽跟头，根子就是读流程和写流程的时序没卡对。

3.1 读流程：客户端、NameNode、DataNode三方协作

读文件时，客户端先向NameNode请求元数据，NameNode返回文件对应的块列表及每个块所在的DataNode地址，然后客户端从这些DataNode直接拉数据。这个过程涉及三个网络请求：第一次是客户端与NameNode之间的元数据查询，第二次到第N次是客户端与DataNode之间的块数据传输。

// 读文件最小示例 Configuration conf = new Configuration(); conf.set("fs.defaultFS", "hdfs://localhost:9000"); FileSystem fs = FileSystem.get(conf); Path path = new Path("/input/wordcount.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(); in.close();

这段代码逻辑很简单：fs.open拿到输入流，按行读，最后关闭。注意FSDataInputStream支持随机读，这意味着你可以用seek跳到指定偏移量读取某个块的数据，这是后面做块级别校验的基础。实验二阶段不要求随机读，但知道这个特性会让你理解为什么open之后不立即发生网络数据传输——真正请求DataNode是在第一次read时触发的。

3.2 写流程：Pipeline与副本放置策略

写入流程是另一个故事。客户端向NameNode发起写请求，NameNode确定文件写入路径和块分配方案后，客户端开始把数据分成64MB或128MB的块，依次写入第一个DataNode。第一个DataNode把数据转给第二个，第二个转给第三个，形成一条pipeline。每个数据块在pipeline上逐级确认，最后客户端收到确认信号才继续写下一块。

// 创建文件并写入，注意第三个参数是副本数 Path dstPath = new Path("/output/api_test.txt"); FSDataOutputStream out = fs.create(dstPath, true); out.writeBytes("hello hdfs programming practice\n"); out.hflush(); out.close();

fs.create的第二个参数true表示“覆盖已存在文件”，这在第二次运行时不报错。hflush的作用是强制把客户端缓冲区的数据刷到DataNode的pipeline上，不调用hflush直接close通常也安全，但如果在写入过程中需要立刻查看数据是否可见，hflush是必要动作。副本放置策略由dfs.replication决定，伪分布式里一般设1，所以只会看到一份block数据。

3.3 用Java API实现完整上传：可复现的最小代码

实验二最常见的任务是把本地文件上传到HDFS指定目录。本地文件在Linux的/tmp下，HDFS目标是/input目录。完整过程包含三件事：检查HDFS目标目录是否存在、获取本地文件流、写入HDFS。

import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.*; import org.apache.hadoop.fs.FileSystem; import java.io.BufferedInputStream; import java.io.FileInputStream; import java.io.InputStream; import java.net.URI; public class HdfsUpload { public static void main(String[] args) throws Exception { // 指定访问HDFS的用户身份，避免root权限问题 Configuration conf = new Configuration(); conf.set("fs.defaultFS", "hdfs://localhost:9000"); FileSystem fs = FileSystem.get(new URI("hdfs://localhost:9000"), conf, "hadoop"); // 目标目录不存在则创建，幂等操作 Path dir = new Path("/input"); if (!fs.exists(dir)) { fs.mkdirs(dir); } // 本地文件 -> HDFS Path localFile = new Path("/tmp/test.txt"); Path hdfsFile = new Path("/input/test.txt"); fs.copyFromLocalFile(false, true, localFile, hdfsFile); // 验证：打印文件和块信息 FileStatus status = fs.getFileStatus(hdfsFile); System.out.println("文件大小: " + status.getLen() + " bytes, 块大小: " + status.getBlockSize()); // 逐块打印位置 BlockLocation[] blocks = fs.getFileBlockLocations(status, 0, status.getLen()); for (BlockLocation b : blocks) { System.out.println("块偏移: " + b.getOffset() + ", 长度: " + b.getLength() + ", 所在节点: " + String.join(",", b.getNames())); } fs.close(); } }

copyFromLocalFile的四个参数含义依次是：delSrc是否删除源文件、overwrite是否覆盖目标文件、src本地路径、dstHDFS路径。这里传false, true表示保留本地源文件且允许覆盖。getFileBlockLocations返回的是文件所有块在DataNode上的分布信息，实验报告里贴这段输出比贴一万字原理都直观。

4. 目录操作与元数据管理：mkdir、listFiles、fsck配套使用

HDFS编程实践里再常见的任务是目录遍历和元数据读取。这部分代码不难，但涉及几个API的行为边界，不搞清楚会在代码里绕弯子，比如listFiles的递归参数、delete的递归删除参数、FileStatus和LocatedFileStatus的区别。

4.1 mkdirs与delete的边界行为

mkdirs是幂等操作，目录存在时不会报错，这一点比Linux的mkdir -p还安全。delete则不然，它有两个参数：第一个是路径，第二个是是否递归删除。如果目标目录非空且第二个参数传false，调用会直接返回false，不删任何东西。

// 创建多级目录并删除 Path multiDir = new Path("/data/project/2024/test"); boolean created = fs.mkdirs(multiDir); System.out.println("目录创建结果: " + created); // 非空目录必须递归删除，否则返回false Path nonEmptyDir = new Path("/data/project"); boolean deleted = fs.delete(nonEmptyDir, true); System.out.println("递归删除结果: " + deleted);

注意fs.delete的第二个参数是recursive，传true才能删除非空目录。实验里经常有人想清空整个目录结构，结果只删了顶层，底层数据全留下，原因就是忘了递归参数。这个坑在写批量清理脚本时尤其明显。

4.2 遍历目录：listFiles与迭代器的坑

listFiles返回一个迭代器，注意它的第二个参数是recursive，传true会遍历所有子目录下的文件，传false只列出当前目录。还有一个容易踩的坑：listFiles返回的是LocatedFileStatus，它比FileStatus多了块位置信息，但同一个目录下混合使用两者时，别把类型写错。

// 递归遍历 /input 下所有文件并打印路径与块大小 RemoteIterator<LocatedFileStatus> iterator = fs.listFiles(new Path("/input"), true); while (iterator.hasNext()) { LocatedFileStatus fileStatus = iterator.next(); System.out.println("文件: " + fileStatus.getPath().toString() + ", 块大小: " + fileStatus.getBlockSize()); }

这里迭代器的hasNext()会阻塞等待下一次分页结果，在文件数量很多的目录下是正常行为，不是卡死。如果只想遍历当前目录不递归，加false参数即可。另外，listStatus返回的是数组，listFiles返回的是迭代器，两者看似等价，但listStatus拿不到块分布信息，需要块信息时只能用listFiles。

4.3 用fsck命令核对块与副本：实验报告的硬证据

代码层面拿到块信息之后，建议用hdfs fsck命令做一次交叉验证。fsck是HDFS自带的文件系统检查工具，能输出每个文件的块数、副本数、缺失块等关键指标，这些都是实验报告里最有说服力的数据。

# 检查 /input 目录下所有文件的健康状态，输出块和副本详情 hdfs fsck /input -files -blocks -locations -racks

-files列出文件基本信息，-blocks显示每个文件包含的块，-locations显示每个块所在DataNode，-racks显示机架位置。如果文件只有一个块，输出里能看到该块的BlockId和对应DataNode主机名。这里有个经验：fsck输出里的replicas数值应该等于dfs.replication配置的值，如果小于预期，说明有DataNode掉线或块尚未复制完成。

注意：hdfs fsck未授权的问题多半是端口写错。Hadoop 3.x版本NameNode的Web端口是9870，很多旧教程写的50070只适用Hadoop 2.x。访问http://localhost:9870能让fsck的HTML报告正常渲染，否则你会看到连接拒绝对应的是配置问题，不是fsck本身的问题。

5. HDFS编程实践避坑指南：权限、覆盖、端口与租约

这一章集中写实验里最容易翻车的几个点，全部来自我在实验课和实际项目里的血泪经验。每条都按现象→原因→解决的路径写，方便你在报错时直接对照。

5.1 权限不足Permission denied：现象、原因、解决

现象：Java程序运行时抛出org.apache.hadoop.security.AccessControlException: Permission denied: user=root, access=WRITE, inode="/input":hadoop:supergroup:drwxr-xr-x。

原因：当前Linux系统用户是root，但HDFS上的目录是hadoop用户所有，权限为755，非属主只有读和执行权限，没有写权限。

解决：在FileSystem.get时显式指定用户身份为hadoop。如果你用的是HdfsUpload那类代码，把FileSystem.get(conf)改成FileSystem.get(new URI("hdfs://localhost:9000"), conf, "hadoop")，问题立刻消失。也可以用环境变量方式：HADOOP_USER_NAME=hadoop java -cp ... HdfsUpload，作用和代码里指定用户一样。

5.2 文件已存在/追加失败：现象、原因、解决

现象：第一次运行程序成功，第二次运行报org.apache.hadoop.fs.FileAlreadyExistsException，或调用append时报IllegalArgumentException: Wrong FS。

原因：fs.create默认不允许覆盖已存在文件，代码里没传overwrite参数为true。Wrong FS则是因为配置文件里fs.defaultFS没有统一，客户端用的是file:///协议，和HDFS协议不匹配。

解决：创建文件时用fs.create(path, true)来自动覆盖。提交作业前检查core-site.xml和代码里Configuration对象的fs.defaultFS是否为hdfs://localhost:9000，保持两端一致。这个问题在从单机模式切换到伪分布式模式时特别容易犯。

5.3 hdfs fsck未授权/端口不对：现象、原因、解决

现象：执行hdfs fsck /input -files后输出ConnectException: Connection refused或提示NameNode的HTTP服务器未启动。

原因：fsck默认走NameNode的HTTP端口。旧教程写的是50070，Hadoop 3.x已经换成9870。很多人照着2.x的资料配环境，端口号对不上，自然连不上。

解决：先到hdfs-site.xml里确认dfs.namenode.http-address的值，一般情况下伪分布式是localhost:9870。fsck命令本身不需要指定端口，它读取的是配置文件里的fs.defaultFS，所以重点检查core-site.xml里的端口是否和NameNode实际监听端口一致。再不行直接看日志，数据目录下logs文件里的报错信息比任何猜测都准。

5.4 集群时间不同步导致租约过期：现象、原因、解决

现象：客户端写入一段时间后抛出LeaseExpiredException: No lease on /input/test.txt (inode 123456): File does not exist，或写完后立即读文件读到不完整数据。

原因：NameNode维护了文件租约机制，租约默认软限制60秒，硬限制60分钟。如果客户端写操作间隔超过了租约时长，而集群各节点系统时间不同步，NameNode会认为客户端已死亡，主动释放租约并关闭文件流。

解决：如果是单机伪分布式，先检查系统时间：date -R查看时区，执行sudo ntpdate ntp.aliyun.com强制校准时间。如果是多节点集群，所有节点都要同步到同一时间源，否则除了租约过期，还会出现副本复制异常、心跳超时等连锁问题。写好代码后，写入循环里可以定期调用client.hflush()刷一下缓冲，尽量缩短两次写操作之间的无活动间隔。

6. 把实验二做出彩：块大小调优、验证方法论与避免“只跑通不验证”

到这里，读、写、目录、fsck校验都跑通了，但实验二想拿高分，还得再往前走一步——用数据说明白你的代码到底做了什么。课堂实验里最不缺“能跑”的程序，缺的是“敢说结论”的验证过程。

验证方法论的起点是“先设计后执行”。写代码前先用Shell命令脚本把数据准备好，记录初始状态；执行Java程序后，用hdfs fsck对比块数量和副本数量；最后用getFileBlockLocations输出的节点信息与Web UI做交叉核对。我一般会刻意写入一个大于块大小的文件，比如块大小调成4MB，写入12MB随机文本，这时fsck会输出3个块，代码里也能拿到三个不同偏移的块位置信息——实验报告里放这张对比表，比贴十行文字都清楚。

块大小参数dfs.blocksize是HDFS里最能体现“你懂原理”的开关。默认128MB适合大数据场景，但实验课的小文件用这个值，一个文件只占一个块，完全看不出分布式存储的效果。我在实验里会把块调小到4MB或8MB，重启NameNode后写入多块文件，让块分布信息丰富起来。小文件多时，这个参数直接影响NameNode内存占用和DataNode存储效率——块越碎，元数据量越大。

最后说一个习惯：每次运行完Java程序，先去查看hdfs fsck /output -files -blocks的输出，再回代码里对块ID和节点位置，全部对上才认为这次实验通过。这个方法让我少走了很多“表面成功、实际数据错乱”的弯路，也帮你把黑匣子里的分布式文件系统看清楚。希望帮到你。

本文还有配套的精品资源，点击获取