HDFS 读写究竟做了什么？从 Java 代码看数据流内幕

open() 被调用后，事情大概是这样的：

客户端先构造一个 DFSInputStream，这时还没真正连数据节点，而是立刻通过 RPC 去问 NameNode：文件的前几个数据块存在哪些 DataNode 上？NameNode 会返回这些 DataNode 的地址，并且按照它们与客户端的网络距离排好顺序。

接着客户端从列表里挑一个最近的 DataNode，建立连接并开始拉数据。数据源源不断从 DataNode 传到客户端，这块读完就关闭连接。然后 DFSInputStream 会调用 getBlockLocations() 查下一个数据块的位置——如果本地缓存里已经有，就不用再问 NameNode 了。重复这个过程，直到把整个文件读完。

如果连某个 DataNode 时出错，客户端会自动切换到这副本的下一个节点，对上层调用者完全是透明的。最后，close() 把流关掉，资源释放。

写数据

写入比读取复杂，因为要保证多副本的一致性。先看写入的典型代码：

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;

public class Chapter3 {
    public static void main(String[] args) {
        try {
            Configuration conf = new Configuration();
            conf.set("fs.defaultFS", "hdfs://localhost:9000");
            conf.set("fs.hdfs.impl", "org.apache.hadoop.hdfs.DistributedFileSystem");
            FileSystem fs = FileSystem.get(conf);
            byte[] buff = "Hello world".getBytes();
            String filename = "test";
            FSDataOutputStream out = fs.create(new Path(filename));
            out.write(buff, 0, buff.length);
            System.out.println("Create:" + filename);
            out.close();
            fs.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

create() 一执行，客户端先用 RPC 通知 NameNode 在文件系统命名空间里建一个文件记录，NameNode 顺便检查权限、文件是否已存在等。没问题的话，NameNode 会返回一些元数据给客户端。紧接着，客户端再次请求 NameNode 分配存放数据块的 DataNode 列表，这个列表构成了一个'数据管道'（pipeline），通常包含多个节点，对应设定的副本数。

真正写数据时，客户端把数据切分成一个个小包（packet），先塞进 DFSOutputStream 的内部队列。然后从管道取出第一个 DataNode，把包发过去。第一个 DataNode 收到后立刻转发给第二个，第二个再转发给第三个，如此包就在管道里从头流到尾。

为了保证不丢数据，每经过一个节点，接收方都会向上一个节点回送一个确认包（ACK）。ACK 逆着管道一路传回客户端，客户端收到后把对应的 packet 从队列里清除。如果中间某个节点出了问题，管道会重新协商，只保留正常节点，这个过程对应用也是透明的。

所有数据写完，客户端调用 close()，先等到队列里剩余的包都收到 ACK，然后通过 ClientProtocol.complete() 通知 NameNode 关闭文件。到这步，文件才算正式写入完成。

回顾整个过程，读的核心是 NameNode 提供块位置 + 就近读取 DataNode，写的核心是管道复制 + ACK 确认。这些机制屏蔽了大量分布式细节，让上层 API 保持简洁的同时，还能做到高吞吐和强容错。