Java连接HDFS实战：Hadoop3.3.1客户端配置与API避坑指南

1. 项目概述：为什么Java操作HDFS是Hadoop工程落地的“临门一脚”

在某高校大数据实验室带学生做课程设计时，我常遇到一个典型场景：学生能顺利启动Hadoop3.3.1伪分布式集群，也能用hdfs dfs -ls /命令在终端里看到文件列表，但一到写Java程序读写HDFS，就卡在ClassNotFoundException、NoClassDefFoundError、Connection refused这些报错上，反复重装客户端、改pom.xml、抄网上的配置，三天都跑不通一个listFiles()。这背后不是代码写错了，而是对Hadoop Java API与底层通信机制的理解存在断层——它既不是纯Java开发，也不是纯运维配置，而是一个典型的“中间态能力”：既要懂JVM类加载路径和依赖传递规则，又要理解HDFS的RPC协议栈、NameNode心跳机制、DataNode数据块定位逻辑，还得会调试网络端口、用户权限、Kerberos认证（哪怕当前没启用）这些隐藏关卡。

“Hadoop3.3.1详细教程（七）Java操作HDFS”这个标题，表面看是教你怎么用FileSystem类，实际拆解下来，它是一套完整的生产级HDFS接入方法论。它解决的不是“能不能连上”，而是“怎么连得稳、读得准、写得快、错得明”。比如，你用FileSystem.get(URI, conf)创建实例时，看似一行代码，背后却触发了至少6个关键动作：配置文件自动加载顺序判断、默认FS自动推导、RPC客户端初始化、NN地址解析与重试、用户身份模拟（Simple或Kerberos）、连接池预热。任何一个环节出偏差，都会在后续open()或create()时爆发，而错误堆栈往往只显示最表层的IOException，根本看不出是配置没生效，还是端口被防火墙拦了，或是core-site.xml里fs.defaultFS写成了hdfs://localhost:9000却忘了同步到Java客户端classpath里。

这个内容最适合三类人：一是刚学完Hadoop原理、正要动手写ETL任务的初学者；二是从传统Java后端转大数据开发的工程师，需要快速补全HDFS交互能力；三是负责搭建数据平台的运维同学，得知道Java客户端连不上时，该查NameNode日志还是检查客户端JDK版本。它不讲MapReduce编程模型，也不展开YARN调度原理，所有内容都锚定在一个具体目标上：让一段Java代码，在本地IDE里，不改一行Hadoop源码，就能稳定、可调试、可监控地操作远程HDFS集群。接下来我会把整个过程拆成四块：先说清楚整体架构设计为什么必须这样搭，再逐个解析核心API背后的原理和避坑点，然后手把手带你走通从Maven依赖配置到文件上传下载的完整链路，最后把我在多个项目里踩过的、文档里绝不会写的12个典型问题列成速查表——包括为什么/user/root目录总提示Permission denied，为什么copyFromLocal比put慢3倍，以及如何用DFSClient源码级调试定位超时根源。

2. 整体设计与思路拆解：为什么必须绕开“直接new FileSystem()”这种写法

2.1 核心设计原则：配置驱动而非硬编码

很多初学者第一反应是直接new org.apache.hadoop.fs.FileSystem()，这是绝对错误的起点。Hadoop的FileSystem是一个抽象类，真实实例由FileSystem.get(URI, Configuration)工厂方法根据URI协议头（如hdfs://、file://、s3a://）动态加载对应子类（DistributedFileSystem、RawLocalFileSystem、S3AFileSystem）。如果你跳过工厂方法，等于绕过了整个Hadoop配置体系——这意味着core-site.xml和hdfs-site.xml里的所有参数（如fs.defaultFS、dfs.client.use.datanode.hostname）都不会生效，你手动传的Configuration对象也只会加载默认值，导致连接地址永远是hdfs://localhost:9000，而你的集群可能部署在hdfs://namenode-prod:8020。

正确的设计思路是：所有HDFS操作必须通过Configuration对象统一注入配置，且该对象必须能自动加载集群侧的XML文件。这就引出第一个关键选择：配置文件怎么放？常见方案有三种：

• 方案A：把core-site.xml和hdfs-site.xml复制到Java项目的src/main/resources下
  优点：简单直接，Maven打包后自动在classpath里；缺点：配置与代码强耦合，不同环境（开发/测试/生产）需手动替换文件，易出错。

• 方案B：用conf.addResource("hdfs-site.xml")显式指定文件路径
  优点：路径可控，支持从任意位置（如/etc/hadoop/conf/）加载；缺点：路径硬编码，Linux和Windows路径分隔符不同，生产环境需额外挂载配置卷。

• 方案C：通过系统属性-Dhadoop.home.dir=/path/to/hadoop让Hadoop自动扫描
  优点：完全复用集群部署结构，无需复制文件；缺点：要求客户端机器安装完整Hadoop发行版，增加部署复杂度。

我最终采用的是方案A+方案B混合模式：开发阶段把配置文件放resources下保证快速启动；生产部署时通过Docker volume将集群配置挂载到容器内，并在代码中用conf.addResource(new Path("/etc/hadoop/conf/core-site.xml"))优先加载。这样既兼顾开发效率，又确保生产一致性。实测下来，这种设计在某电商实时数仓项目中支撑了200+个Flink作业的HDFS读写，零配置相关故障。

2.2 依赖管理策略：为什么必须排除hadoop-client的传递依赖冲突

Hadoop3.3.1的hadoop-client模块依赖极深，仅hadoop-common就引入了commons-collections4、commons-configuration2、slf4j-api等20+个jar包。而你的Spring Boot项目很可能已引入commons-collections3.x或slf4j-log4j12，直接<dependency><groupId>org.apache.hadoop</groupId><artifactId>hadoop-client</artifactId><version>3.3.1</version></dependency>会导致运行时NoSuchMethodError——比如Configuration.set()方法在3.3.1里签名是set(String, String, String)，而老版本只有set(String, String)，JVM加载了旧jar就会爆错。

解决方案是精准依赖+强制版本锁定。我在pom.xml中这样写：

<dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> <version>3.3.1</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <!-- 统一使用slf4j-simple，避免日志桥接冲突 --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.7.32</version> </dependency>

这里的关键逻辑是：Hadoop只负责提供HDFS协议实现，日志、配置、集合工具等基础能力应由应用层统一管理。排除slf4j-log4j12是因为它会尝试绑定Log4j1.x，而现代项目多用Logback或Log4j2；排除commons-logging是因它与SLF4J存在双重桥接风险。实操中，我曾遇到一个诡异问题：FileSystem.listStatus()返回空数组，但hdfs dfs -ls能看到文件。排查三天才发现是commons-logging的LogFactory静态块在类加载时触发了错误的Logger初始化，导致Hadoop内部日志输出被静默丢弃，根本看不到DEBUG级别的RPC调用日志。加上<exclusion>后，问题立即消失。

2.3 安全上下文设计：为什么Simple Authentication在开发环境足够用

Hadoop默认启用Simple认证（即操作系统用户身份透传），这在开发环境反而是最合理的选择。很多人一上来就想配Kerberos，结果陷入kinit、krb5.conf、keytab分发等运维泥潭，反而忽略了业务逻辑本身。Simple模式下，Java客户端以当前OS用户（如ubuntu）身份连接NameNode，NameNode检查该用户对目标路径是否有读写权限。这就要求你在集群侧提前创建好对应用户，并用hdfs dfs -chmod -R 755 /user/ubuntu授权。

但Simple模式有个致命陷阱：Windows开发机无法直连Linux集群。因为Windows没有ubuntu用户，System.getProperty("user.name")返回的是DESKTOP-ABC\John，NameNode收到后会尝试查找DESKTOP-ABC\John用户，自然失败。解决方案有两个：一是用UserGroupInformation.createRemoteUser("ubuntu")显式指定用户；二是更彻底的——在Windows上用WSL2安装Ubuntu子系统，在其中运行IDEA，让user.name天然匹配。我推荐后者，因为WSL2的网络与宿主机互通，hdfs://namenode:8020可直接访问，且避免了用户模拟带来的权限继承问题。某金融客户曾因在Windows上强行用createRemoteUser，导致Spark作业提交后，Executor进程以ubuntu身份运行，但临时目录/tmp/hadoop-ubuntu的属主却是root，引发Permission denied，折腾两天才定位到这个根源。

3. 核心细节解析与实操要点：FileSystem API背后的五个关键真相

3.1FileSystem.get()不是简单连接，而是构建RPC客户端工厂

当你调用FileSystem.get(URI.create("hdfs://namenode:8020"), conf)时，Hadoop执行的远不止建立TCP连接。它实际创建了一个DistributedFileSystem实例，该实例内部持有一个DFSClient对象，而DFSClient又包含三个核心组件：

• ClientProtocol代理：通过动态代理生成NameNodeProxies.createProxy()，封装了与NameNode的RPC通信。它不是普通HTTP调用，而是基于Hadoop自研的WritableRpcEngine序列化协议，比gRPC更轻量，但调试难度更高。
• BlockLocation缓存：首次open()文件时，DFSClient会向NameNode请求该文件所有Block的位置列表（含每个副本的DataNode IP+端口），并缓存到本地blockLocationsMap中。后续读取同一文件的其他Block时，直接从缓存取，避免重复RPC。
• Socket连接池：每个DataNode连接都维护一个DFSOutputStream连接池，默认大小为dfs.client.max.block.acquire.failures=3，即单个Block最多重试3次获取连接。如果DataNode宕机，连接池会自动剔除失效连接。

这个设计意味着：FileSystem实例是线程安全的，但不应被频繁创建销毁。我见过有同学在for循环里每次get()再close()，结果QPS上不去，因为每次都要重建RPC代理和连接池。正确做法是单例持有FileSystem，并在应用启动时预热：fileSystem.listStatus(new Path("/"))触发一次完整连接流程。

提示：调试DFSClient行为，可在log4j.properties中添加log4j.logger.org.apache.hadoop.hdfs.DFSClient=DEBUG，你会看到类似Connecting to namenode via 192.168.1.100:8020和Got 3 locations for block BP-123456789-192.168.1.100-1600000000000:blk_1073741825_1001的日志，这是定位网络问题的第一手证据。

3.2Path对象不是字符串，而是HDFS路径的语义化封装

初学者常把new Path("hdfs://namenode:8020/user/data/input.txt")和new Path("/user/data/input.txt")混用，认为只是写法差异。实际上，Path构造函数会自动解析URI scheme，"hdfs://..."格式会提取出authority（namenode:8020）作为默认FS，而"/user/..."格式则完全依赖conf.get("fs.defaultFS")的值。如果core-site.xml里fs.defaultFS配置为hdfs://backup-nn:8020，那么new Path("/user/data.txt")会连接备份集群，而非你预期的主集群。

更隐蔽的问题是路径分隔符。Hadoop内部统一用/，但Windows系统File.separator是\。如果你写new Path("C:\\data\\input.txt")，Path构造函数会把它当成本地文件路径，FileSystem调用exists()时会去查本地磁盘而非HDFS。正确写法永远是new Path("/user/data/input.txt")，用正斜杠，且不带盘符。

还有一个易忽略的细节：Path的toString()返回的是标准化路径，但getName()只返回最后一级文件名。比如new Path("/user/data/input.txt").getName()返回"input.txt"，而new Path("hdfs://nn:8020/user/data/input.txt").getName()同样返回"input.txt"。这在批量处理文件时很关键——你不能用path.toString().contains("input")来过滤，而应该用path.getName().startsWith("input")，否则跨集群迁移时路径前缀变化会导致逻辑错误。

3.3FSDataInputStream的read()方法不是阻塞IO，而是带预读的缓冲流

FSDataInputStream继承自DataInputStream，但底层是DFSInputStream，它实现了智能预读（prefetch）机制。当你调用in.read(buffer, 0, 1024)时，DFSInputStream不会只读1KB，而是根据dfs.client.read.prefetch.size（默认1MB）参数，预先从DataNode拉取更多数据到本地缓冲区。这样下次read()就不用等网络IO，直接从内存拷贝。

这个机制带来两个实操影响：一是小文件读取性能远超预期。测试显示，读取100个1KB文件，用FSDataInputStream比hdfs dfs -cat快4倍，因为后者每次都要建立新连接，而前者复用连接池和缓冲区。二是**available()方法不可靠**。in.available()返回的是缓冲区剩余字节数，不是文件总长度，所以不能用它来分配数组大小。正确方式是先fileStatus.getLen()获取文件长度，再分配byte[] buffer = new byte[(int) len]。

注意：预读会占用JVM堆外内存（Direct Memory），如果同时打开上千个FSDataInputStream，可能触发OutOfMemoryError: Direct buffer memory。解决方案是控制并发流数量，或调大JVM参数-XX:MaxDirectMemorySize=2g。

3.4FSDataOutputStream的write()不是立即落盘，而是分块写入+管道复制

FSDataOutputStream的写入流程比读取复杂得多。当你out.write(bytes)时，数据首先进入客户端内存缓冲区（默认4MB，由io.file.buffer.size控制），当缓冲区满或调用hflush()时，才触发真正的写入：

1. 客户端将缓冲区数据切分为dfs.blocksize（默认128MB）的Block；
2. 向NameNode申请Block ID和DataNode列表（如3副本，则返回3个DN地址）；
3. 建立Pipeline管道：客户端→DN1→DN2→DN3，数据以Packet（64KB）为单位沿管道流动；
4. 每个DN收到Packet后，写入本地磁盘并转发给下一个DN，同时向客户端发送ACK；
5. 客户端收到所有DN的ACK后，才确认该Packet写入成功。

这个设计意味着：write()调用返回不代表数据已持久化。如果DN2在转发时宕机，客户端会收到异常，并自动尝试重建Pipeline（如换DN4）。但如果你没捕获异常，就以为写入成功，数据其实只存到了DN1。因此，生产代码必须包含try-catch和finally { out.close() }，因为close()会触发hflush()和hsync()，确保所有Packet完成Pipeline复制并刷盘。

实测发现，某物流公司的订单日志写入作业，因未加close()，每天丢失约0.3%的数据——这些数据在DN1内存缓冲区里，DN1重启后缓冲区清空，而NameNode认为该Block已分配，不再重新调度。

3.5 权限模型不是Linux chmod，而是HDFS专属ACL体系

HDFS权限检查发生在NameNode侧，与Linux文件系统完全独立。hdfs dfs -chmod 755 /user/data设置的不是Linux的rwx，而是HDFS的FsPermission对象，它包含三部分：owner（所有者）、group（所属组）、other（其他用户），每部分用3位二进制表示（r=4,w=2,x=1）。但HDFS的x权限有特殊含义：对文件，x无意义（文件不可执行）；对目录，x表示“可进入”，即cd权限。所以755对目录意味着owner可读写执行，group和其他用户可读执行（可ls和cd，但不能touch新文件）。

更关键的是用户组映射机制。HDFS不存储用户组信息，而是调用/usr/bin/groups命令查询当前用户所属组。如果你在集群里用useradd -G hadoop ubuntu把ubuntu加入hadoop组，但客户端机器没装groups命令，HDFS会认为ubuntu只属于ubuntu组，导致/user/hadoop目录权限不生效。解决方案是在core-site.xml中配置hadoop.user.group.static.mapping，例如：

<property> <name>hadoop.user.group.static.mapping</name> <value>ubuntu:hadoop,devops:admin</value> </property>

这样HDFS就跳过外部命令调用，直接查配置映射。我在某政务云项目中就遇到这个问题：客户提供的CentOS镜像精简掉了which和groups，所有Java客户端连HDFS都报AccessControlException: Permission denied，加了这个配置后秒解。

4. 实操过程与核心环节实现：从零开始跑通HDFS文件上传下载全流程

4.1 环境准备：三步搞定本地开发机与Hadoop3.3.1集群连通

第一步：确认集群状态。登录NameNode服务器，执行：

# 检查NameNode是否Active（非Standby） hdfs haadmin -getServiceState nn1 # 查看Live DataNode列表 hdfs dfsadmin -report | grep "Live datanodes" # 验证端口可达（从开发机ping不通，但telnet必须通） telnet namenode-prod 8020

注意：8020是NameNode RPC端口（dfs.namenode.rpc-address），不是WebUI的9870。如果telnet失败，90%是防火墙问题，需在NameNode执行sudo ufw allow 8020（Ubuntu）或sudo firewall-cmd --permanent --add-port=8020/tcp（CentOS）。

第二步：获取集群配置文件。登录NameNode，将$HADOOP_HOME/etc/hadoop/下的core-site.xml和hdfs-site.xml复制到本地IDEA项目的src/main/resources目录。重点检查以下参数：

• core-site.xml中fs.defaultFS值必须是hdfs://<namenode-host>:8020，且<namenode-host>必须能被开发机DNS解析（不能是localhost或127.0.0.1）；
• hdfs-site.xml中dfs.namenode.http-address用于WebUI，dfs.client.use.datanode.hostname=true表示客户端用hostname而非IP连接DN（避免IP漂移问题）。

第三步：配置IDEA运行环境。在Run Configuration的VM options中添加：

-Dhadoop.home.dir=/path/to/hadoop-3.3.1 -Djava.library.path=/path/to/hadoop-3.3.1/lib/native

hadoop.home.dir指向你本地解压的Hadoop3.3.1目录（需包含lib/native下的libhadoop.so），这是解决UnsatisfiedLinkError: hadoop.dll的关键。Windows用户必须下载编译好的hadoop.dll并放在C:\hadoop\bin，再在系统PATH中添加该路径。

实操心得：我曾帮某教育公司远程调试，他们死活连不上，最后发现是core-site.xml里fs.defaultFS写成了hdfs://namenode:9000，而集群实际端口是8020。Hadoop不会报“端口错误”，而是静默超时，因为9000端口根本没服务监听。建议在core-site.xml里加一行注释：<!-- Production cluster: hdfs://nn-prod:8020 -->，避免手误。

4.2 Maven依赖配置：一份可直接粘贴的pom.xml片段

以下是经过20+个项目验证的最小可行依赖配置，已排除所有常见冲突：

<properties> <hadoop.version>3.3.1</hadoop.version> <slf4j.version>1.7.32</slf4j.version> </properties> <dependencies> <!-- Hadoop核心客户端，排除日志和日志桥接器 --> <dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> <version>${hadoop.version}</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <!-- 统一日志实现，避免桥接冲突 --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>${slf4j.version}</version> </dependency> <!-- 如果用JUnit测试，需添加此依赖解决Hadoop测试类加载问题 --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> <dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-minicluster</artifactId> <version>${hadoop.version}</version> <scope>test</scope> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> </dependencies>

关键点说明：

• hadoop-minicluster仅用于单元测试，它会在本地启动一个嵌入式HDFS，避免依赖远程集群。测试类中用MiniDFSCluster.Builder即可创建；
• slf4j-simple体积小（仅15KB），无依赖，适合生产环境，避免slf4j-log4j12与Logback共存时的Multiple binding警告；
• 所有exclusion必须显式写出，不能依赖<optional>true</optional>，因为Maven传递依赖解析规则会忽略optional标记。

4.3 文件上传：copyFromLocalFile()与create()的性能对比实测

上传文件有两种主流方式，适用场景完全不同：

方式一：FileSystem.copyFromLocalFile()（推荐用于大文件）

FileSystem fs = FileSystem.get(URI.create("hdfs://namenode:8020"), conf); Path localPath = new Path("/home/ubuntu/data.csv"); Path hdfsPath = new Path("/user/ubuntu/data.csv"); fs.copyFromLocalFile(false, true, localPath, hdfsPath); // deleteSrc=false, overwrite=true

参数false, true含义：不删除本地源文件，覆盖HDFS目标文件。它的优势是零内存拷贝——Hadoop直接调用FileChannel.transferTo()，数据从本地磁盘文件描述符直接送入Socket缓冲区，不经过JVM堆内存，上传1GB文件仅耗时12秒（万兆网络）。

方式二：FileSystem.create()+IOUtils.copyBytes()（推荐用于流式数据）

FSDataOutputStream out = fs.create(hdfsPath, true); // overwrite=true InputStream in = new FileInputStream(new File("/home/ubuntu/data.csv")); IOUtils.copyBytes(in, out, conf, true); // close streams=true

这种方式把文件读入JVM内存再写出，1GB文件需分配1GB堆内存，GC压力大，耗时28秒。但它支持动态生成内容，比如从Kafka消费消息实时写入HDFS：

FSDataOutputStream out = fs.create(new Path("/data/kafka-" + System.currentTimeMillis() + ".avro")); AvroDatumWriter<GenericRecord> writer = new AvroDatumWriter<>(schema); DataFileWriter<GenericRecord> dataFileWriter = new DataFileWriter<>(writer); dataFileWriter.create(schema, out); // 每收到一条Kafka消息，调用dataFileWriter.append(record)

性能实测数据（10次平均，网络带宽1Gbps）：

结论：批量上传固定文件，无条件选copyFromLocalFile；需要边生成边写入，必须用create。某视频平台用create写入直播流切片，因未控制单文件大小（超过2GB），触发HDFS的MAX_FILE_SIZE限制（默认2GB），导致IOException: File size is larger than max allowed。解决方案是加fs.create(path, true, 4096, (short)3, 128*1024*1024L)，最后一个参数显式设置BlockSize为128MB，避免单文件过大。

4.4 文件下载：copyToLocalFile()的隐藏参数陷阱

下载操作看似简单，但copyToLocalFile()有三个易踩的坑：

坑一：useRawLocalFileSystem参数决定是否校验CRC

fs.copyToLocalFile(false, hdfsPath, localPath, true); // 第四个参数true表示useRawLocalFileSystem=true，跳过CRC校验

HDFS默认为每个Block生成MD5校验码（.crc文件），copyToLocalFile默认开启校验，下载时会读取.crc文件比对。如果HDFS上文件被hdfs dfs -put覆盖但.crc未更新，校验失败会抛ChecksumException。设为true可跳过校验，但风险是损坏文件被静默下载。生产环境建议保持false，并确保上游写入用hflush()保证CRC一致。

坑二：copyToLocalFile不支持通配符，必须用listStatus遍历想下载/user/logs/2023-10-*所有文件？copyToLocalFile不支持*，必须：

FileStatus[] statuses = fs.listStatus(new Path("/user/logs/")); for (FileStatus status : statuses) { if (status.getPath().getName().startsWith("2023-10-")) { fs.copyToLocalFile(status.getPath(), new Path("/local/logs/" + status.getPath().getName())); } }

坑三：Windows路径分隔符导致FileNotFoundException在Windows上调用fs.copyToLocalFile(hdfsPath, new Path("D:\logs\data.txt"))会失败，因为\被Java当转义符。必须用双反斜杠或正斜杠：

// 正确写法 new Path("D:/logs/data.txt") // 或 new Path("D:\\logs\\data.txt")

4.5 目录操作与元数据管理：listStatus()的深度用法

listStatus()是HDFS元数据操作的核心，但多数人只用它ls，其实它能做更多：

递归遍历所有子文件（替代hdfs dfs -ls -R）

public static void listAllFiles(FileSystem fs, Path path) throws IOException { FileStatus[] statuses = fs.listStatus(path); for (FileStatus status : statuses) { if (status.isDirectory()) { listAllFiles(fs, status.getPath()); // 递归 } else { System.out.println("File: " + status.getPath() + ", Size: " + status.getLen()); } } }

按修改时间过滤（获取最近1小时的文件）

long oneHourAgo = System.currentTimeMillis() - 60 * 60 * 1000; FileStatus[] statuses = fs.listStatus(new Path("/user/data")); for (FileStatus status : statuses) { if (status.getModificationTime() > oneHourAgo && !status.isDirectory()) { processFile(status.getPath()); } }

获取Block分布详情（诊断数据倾斜）

FileStatus status = fs.listStatus(new Path("/user/data/part-00000"))[0]; BlockLocation[] locations = fs.getFileBlockLocations(status, 0, status.getLen()); for (BlockLocation location : locations) { System.out.println("Block length: " + location.getLength() + ", Hosts: " + Arrays.toString(location.getHosts())); }

BlockLocation返回每个Block的副本所在DataNode列表，如果某个DN出现在90%的Block中，说明数据分布不均，需执行hdfs balancer。

5. 常见问题与排查技巧实录：12个血泪教训总结的速查表