2.3 读取路径与客户端操作

2.3 读取路径与客户端操作

本节摘要：HDFS 读取路径的核心是"就近选块"：客户端向 NameNode 索取块位置，按节点距离排序后依次尝试，配合校验块验证完整性，失败自动换副本重读。本节走完这条路径，覆盖短路读、零拷贝等优化，并给出命令行与 Java API 的日常操作全集。

读取的时序：先问路，再上路

与写入对称，读取同样把元数据与数据分离。以读取 /data/logs/access-2026-08-18.log 的第二个字节区间为例：

1. 客户端向 NameNode 发起 RPC："我要读这个文件的偏移 128MB 到 256MB"；
2. NameNode 返回目标块（blk_1073741826）所在的 DataNode 列表，并已按与客户端的距离排序：同节点 → 同机架 → 跨机架；
3. 客户端与列表中第一个 DataNode 建立 TCP 连接，请求"读该块的某区间"；
4. DataNode 顺序读盘，连同校验信息一起发送；客户端按 512 字节单元验证 CRC，不匹配则报错；
5. 校验失败或连接失败，客户端换列表中的下一个 DataNode 重读该区间——读取端容错就在这一步体现；
6. 块读完，客户端继续向 NameNode 要下一块的位置，直到文件读完。

整个过程中 NameNode 只被"问路"，不经手任何数据。这个设计让读吞吐可以随 DataNode 数量线性扩展——每个块的三副本意味着三倍的读取服务能力，热点文件的高并发读天然被分摊。

图 2-3 读取路径选块示意：按距离排序与降级重读

距离怎么算：四层拓扑度量

"按距离排序"需要一个可计算的距离定义。HDFS 把网络拓扑组织成树，常见的四层是：数据中心 → 机架 → 节点 → 进程。两节点的距离 = 它们到最近共同祖先的距离之和。举例：

• 同一节点上的两个进程：距离 0；
• 同机架不同节点：距离 2（各自上溯到机架，各一跳）；
• 同集群不同机架：距离 4；
• 跨数据中心：距离 6。

这个度量同时服务于读取排序与第 3 章 Map 任务的本地性判定（节点本地 → 机架本地 → 跨架三级）。回忆 2.2 节的副本放置——正是"一本地两跨架其中同架再放一份"的布局，让任意位置的读者都能在距离 2 以内找到一个副本。

读取性能的两个优化

短路读（Short-Circuit Read）。如果读者进程与 DataNode 在同一节点（典型场景：Map 任务读取本地块），数据还要经过一次本机回环 TCP 与 DataNode 进程的中转。短路读允许客户端通过 Unix 域套接字直接打开 DataNode 管理的块文件，跳过整个 TCP 栈与 DataNode 数据面，读延迟显著下降。配置要点：

<property>
  <name>dfs.client.read.shortcircuit</name>
  <value>true</value>
</property>
<property>
  <name>dfs.domain.socket.path</name>
  <value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>
​

零拷贝转移（Zero-copy Transfer）。传统读路径中数据要从页缓存拷到用户态、再拷回内核发送缓冲区；HDFS 的 DataNode 支持 transferTo（Linux 上即 sendfile 系统调用），文件数据直接从页缓存进网卡缓冲区，省去两次内存拷贝与上下文切换。这是 DataNode 侧的优化，客户端无感知，但对大吞吐集群的 CPU 占用改善明显。

💡 关键直觉：HDFS 读取路径的绝大多数优化，目标都是"让数据少走一跳"——少一次跨网络（就近选块）、少一次跨进程（短路读）、少一次跨态拷贝（零拷贝）。方向一致的。

命令行操作全集

日常 90% 的 HDFS 交互用命令行完成。以下按用途分组，括号内为典型输出或说明：

# 目录与浏览
hdfs dfs -ls /data                    # 列目录
hdfs dfs -mkdir -p /data/warehouse/dt=2026-08-18   # 递归建目录
hdfs dfs -du -h /data                 # 显示各路径占用 人类可读

# 上传下载
hdfs dfs -put localfile /data/        # 上传
hdfs dfs -get /data/big.bin /tmp/     # 下载
hdfs dfs -getmerge /data/logs/part-* merged.log    # 合并下载多个分片

# 删除与移动
hdfs dfs -rm -r -skipTrash /data/tmp # 直接删（跳过回收站）
hdfs dfs -mv /data/a.log /data/b.log  # 移动重命名（仅元数据操作 瞬间完成）
hdfs dfs -cp /data/a.log /data/copy/  # 复制（真实拷贝数据）

# 权限与属主
hdfs dfs -chmod 750 /data/private     # 与Linux语义一致
hdfs dfs -chown analyst:etl /data/inbox

# 元数据与运维
hdfs dfs -setrep -w 2 /data/big.bin   # 调整副本因子 -w等待生效
hdfs dfs -stat %b /data/big.bin       # 文件字节数
hdfs dfsadmin -report                 # 集群容量与节点概览
​

注意 -mv 与 -cp 的区别：前者只改账本（纳秒级），后者真的复制三副本（分钟级）。批处理任务里误用 -cp 处理海量分区是新手常见的性能事故。

Java API：三段式读写骨架

生产 ETL 常直接用 API 操作 HDFS。写文件的骨架：

Configuration conf = new Configuration();
conf.set("fs.defaultFS", "hdfs://nn.example.com:9000");
FileSystem fs = FileSystem.get(conf);

// 写：三段式 创建流 → 写入 → 关闭触发提交
try (FSDataOutputStream out = fs.create(
        new Path("/data/ingest/2026-08-18.log"),
        (short) 3,      // 副本因子
        4 * 1024 * 1024 // 写缓冲 4MB
)) {
    out.writeBytes("2026-08-18 10:00:00 GET /api/item 200\n");
} // close 内部完成管线flush与块提交

// 读：先开流 → 定位偏移 → 流式读
try (FSDataInputStream in = fs.open(new Path("/data/ingest/2026-08-18.log"))) {
    in.seek(128L * 1024 * 1024);   // 直接定位到第二块区间
    byte[] buf = new byte[4096];
    int n = in.read(buf);          // 客户端自动选择该区间所在块
}
fs.close();
​

骨架之外有三个工程要点。其一，FileSystem.get 有连接缓存，同 JVM 内频繁获取应复用实例或调用 close 释放，否则连接泄漏。其二，seek 是廉价操作（只改客户端读指针并触发一次问路），随机访问少量区间可行，但 HDFS 的高延迟寻址本质没变——大量小随机读仍是 HBase（第 5 章）的领地。其三，写流一旦关闭不可重开追加（除非启用 append 并谨慎使用），"先写临时文件再原子 rename 提交"是保证读者只见完整文件的标准模式，Hive 与 Spark 的提交协议都建立在这个原语上。

读取路径上的排错思路

读取故障定位有一条清晰的检查链，按数据流逆向排查：报错是"块找不到"还是"读超时"？前者用 hdfs fsck 确认副本是否真的缺失（可能处于复制中），后者查目标 DataNode 的负载与网络。校验错误（ChecksumException）则指向磁盘静默损坏——DataNode 后台目录扫描器会发现并上报，NameNode 调度好副本重建。把这三类故障对照到读取时序图的对应环节，排错就有了坐标系。

本节要点回顾

• 先问路再上路：NameNode 只给位置不给数据，读吞吐随 DataNode 线性扩展；
• 副本列表按距离排序，失败自动降级到下一副本，读取端容错免费获得；
• 距离 = 到共同祖先跳数之和，同节点 0、同机架 2、跨机架 4，读取与调度共用此度量；
• 短路读省进程跳、零拷贝省态跳，加上就近选块省网络跳，优化方向一致；
• 命令行记三组：浏览上传下载、删除移动、元数据运维；-mv 是账本操作而 -cp 是数据复制；
• API 三段式读写加"临时文件加原子改名"提交模式，是所有上层组件写 HDFS 的公共套路。

下一章数据从存储层进入计算层：MapReduce 编程模型。