简介这份实验报告出自计算机系《云计算技术》课程以Hadoop IO为主题聚焦如何改写实验4的GetMerge程序从而将HDFS云端多个文件经过Gzip压缩后合并下载到本地。报告详细记录了实验目标、Eclipse环境下MapReduce项目的创建过程、核心代码片段以及实验结果同时体现了从Hadoop配置初始化、压缩器创建到数据流复制的完整流程适合正在学习Hadoop分布式文件系统读写与压缩编程的高校学生、云计算课程实践者参考。包体为1个PDF文件容量仅573KB内容精炼便于快速阅读和打印使用。目前已有307人学习下载。报告中重点展示了CompressionCodec、GzipCodec和IOUtils.copyBytes等API的实际用法并附有压缩工具类的初始化、压缩输出流创建等关键步骤说明对于想掌握HDFS数据本地化压缩处理、完成类似实验任务或撰写实验报告的人来说是一份有直接借鉴价值的参考材料。1. 云计算技术实验报告五Hadoop IO 到底在考察什么如果只把“云计算技术实验报告五 Hadoop IO”当成一次文件读写演示那实验做完你也不会留下多少东西反过来如果能看到这 8 个英文字母背后是 HDFS 的完整数据通路一次实验就能把分布式存储的副本放置、数据管道、序列化、压缩和调优串成一条线。多数人在这一步的困惑不是“命令不会敲”而是看不懂hdfs dfs -put之后发生了什么数据从客户端内存到 DataNode 磁盘中间经过几层缓冲、几次网络往返、哪些参数在起作用。这份实验报告本质上是在要求你完整复现并解释 Hadoop 的 I/O 路径而不是跑通一个 WordCount。本文按实验报告常见的五步骤展开先建立 HDFS 写入链路的心智模型再分别拆数据写、数据读、序列化与压缩、I/O 调优与验证最后落在实验课自己动手验证的关键技巧上。适合正在做《云计算技术》课程设计、需要提交 Hadoop 实验报告或者准备云计算相关岗位面试的人。2. HDFS 写入链路从 put 命令到三副本落盘2.1 客户端、NameNode 与 DataNode 三方协作的写入模型hdfs dfs -put看起来像一次普通文件复制实际由客户端、NameNode、DataNode 三个角色配合完成。客户端把文件按块切分默认块大小dfs.blocksize为 128MB每写一个块客户端先向 NameNode 发起addBlock请求NameNode 根据副本放置策略返回一组 DataNode 地址客户端再与这些 DataNode 建立管道pipeline执行写入。这个模型决定了 HDFS 写入的“一次写入、多次读取”语义——文件一旦关闭就不能修改适合分析型负载不适合随机写。副本放置策略是理解写入链路的第一关。默认策略dfs.replication3时第一个副本放在客户端所在节点如果客户端在集群外则随机挑一个负载较低的 DataNode第二个副本放在与第一个不同机架的节点第三个副本放在与第二个相同机架的另一节点。这个“机架感知”写法是为了平衡容错机架级故障不至于丢数据与写带宽跨机架网络流量有限。实验报告里如果你只搭了伪分布式那么三个副本实际上落在一个节点的三块不同磁盘目录里这一点要在报告中说明否则会让人觉得你不清楚副本与节点的区别。2.2 数据管道与 ack 机制每 512 字节要经过一次校验管道建立后客户端按dfs.client-write-packet-size默认 64KB打包数据包内又按 512 字节做 CRC32 校验。数据包按“客户端 → DataNode1 → DataNode2 → DataNode3”逐级传递每个 DataNode 收到包后先落盘再转发给下游然后以相反方向返回 ack。只有客户端收到管道中所有 DataNode 的成功 ack这个数据包才算写成功。这段逻辑你应该能复述清楚HDFS 不做写入后的异步复制而是用同步管道保证副本之间的一致性代价是写入延迟被拉高但读取时任意副本都是完整可用的。用命令验证管道写入状态时最直接的方法是看 DataNode 日志和系统网络连接# 在 DataNode 节点上查看与客户端或相邻 DataNode 的连接伪分布式时是本机回环 ss -tnp | grep java # 实时跟踪 DataNode 日志观察 block 接收和 ack 返回 tail -f $HADOOP_HOME/logs/hadoop-hadoop-datanode-*.log | grep -E Receiving|writeBlock|ack日志中如果频繁出现Timeout waiting for ack或Packet ack timeout说明管道中某个 DataNode 写入慢或网络抖动客户端会触发管道重建把故障节点剔除后重建剩余副本管道。这个行为在实验报告里可以作为“故障处理”小节写HDFS 的写入不是简单失败重试而是“定位故障节点 → 剔除 → 重建管道 → 补充副本”。2.3 写入链路中的核心参数速查与实测建议伪分布式做实验时以下参数和默认值会直接影响实测表现报告里建议用表格列出并说明调整后的效果参数名默认值作用实验建议dfs.blocksize128MB文件块大小调成 1MB 便于观察 block 分布dfs.replication3副本数伪分布式调成 1 避免报错dfs.client-write-packet-size64KB写入包大小调大可提升吞吐调小可降低延迟dfs.client.block.write.replace-datanode-on-failure.policyDEFAULT管道故障处理观察写入失败场景时保留默认值dfs.namenode.handler.count10NameNode 处理线程数小文件场景调大避免 RPC 积压实际写入性能与块大小的关系可以用一条时间线描述4KB 小文件配 128MB 块每个文件一个块每写一个文件都要与 NameNode 做一次 RPC而 1GB 文件配 128MB 块只需要 8 次块申请。因此块大小与文件大小匹配时吞吐最好这也是为什么实验里-put一个几 GB 的测试文件比大量小文件省时间。3. 读路径与本地性优化为什么 HDFS 读比写快3.1 从 DFSInputStream 到短路读的完整读链路HDFS 读取时客户端创建DFSInputStream先从 NameNode 拿文件块与副本位置的映射然后选择“最近”的副本建立 TCP 连接读取。这里的“最近”由dfs.client.use.datanode.hostname与网络拓扑共同决定客户端与 DataNode 在同一节点时优先读本地副本避免网络传输。读路径上数据不经过 NameNodeNameNode 只负责元数据与块定位所以读吞吐可以接近本机磁盘上限。实验报告里最常见的问题是“为什么读比写快很多”。原因有三个层面。一写入要同步复制三份至少产生两次跨节点传输读只需要一份数据。二写入要返回 ack每个数据包都有等待延迟而读是流水线式拉取一个连接上连续发请求。三HDFS 读取命中本地副本时直接走本地文件系统读不占网络。验证方法很直接# 对比读写同一文件的耗时在集群内某节点执行 time hdfs dfs -put /data/testfile.bin /tmp/testfile.bin time hdfs dfs -cat /tmp/testfile.bin /dev/null如果写耗时是读的 2 到 3 倍说明副本同步在起作用。若相差不大检查是否副本数被改成了 1。3.2 短路读让客户端绕过 TCP 直接读 DataNode 文件标准读路径上即使客户端在 DataNode 本机也要通过 TCP 把数据从 DataNode 的 50010 端口取回来。短路读Short-Circuit Read允许客户端直接以文件描述符映射方式读 DataNode 上的块文件省掉一次本机 TCP 回环。这是对“本地读还是走了网络栈”的优化实验环境里的效果可能不明显但面试会问。开启短路读需要配置两个地方。一是 DataNode 的dfs.domain.socket.path指定 socket 文件路径且目录权限要满足 DataNode 与客户端都可访问二是dfs.client.read.shortcircuittrue。伪分布式单节点下配置如下property namedfs.client.read.shortcircuit/name valuetrue/value /property property namedfs.domain.socket.path/name value/var/lib/hadoop-hdfs/dn_socket/value /property property namedfs.client.read.shortcircuit.skip.checksum/name valuefalse/value /property配置后建议在核心代码里执行一次测试小文件读取再从 DataNode 日志中确认短路读是否生效日志出现Setting up short-circuit read即成功。注意如果实验报告里只验证了hdfs dfs -cat短路读可能不触发因为 HDFS Shell 客户端默认走完整读路径用 Java API 的FSDataInputStream才稳定触发。3.3 小文件读放大效应对伪分布式实验的影响小文件问题在实验里被低估。每个文件、每块副本在 NameNode 内存里对应一条元数据记录默认每条约 150 字节一万个 1KB 小文件在 NameNode 里要占约 4MB 堆内存而读这些小文件时磁盘寻道开销远大于传输开销。实验报告建议补一个“小文件读放大”测试生成 10000 个 1KB 文件与 10 个 1GB 文件对比总读取时间。前者常见耗时是后者数倍原因是每个文件都要发起 RPC、建立连接、等待响应。伪分布式下 I/O 性能明显下降时第一步看是不是小文件撑爆了 NameNode 的 RPC 队列。可以查 NameNode 日志里的rpc相关统计或直接执行hdfs dfsadmin -report | grep -E Configured Capacity|Present Capacity|DFS Used|Total FilesTotal Files数量异常大且DFS Used很小就是小文件问题。缓解手段是har归档或 SequenceFile 合并这正好引出第四章的序列化与压缩。4. SequenceFile 与小文件合并实验里 IO 层面的序列化方案4.1 为什么 MapReduce 的中间数据需要 SequenceFileMapReduce 执行过程中Map 阶段输出写到本地磁盘Shuffle 阶段再把输出拉取到 Reduce 端。这个中间数据不是纯文本也不是普通二进制而是带 key 与 value 类型标识的序列化记录。Hadoop 官方方案是 SequenceFile一种二进制键值容器持久化 key 的类名与 value 的字节流读的时候能拿到类型信息。实验中用 SequenceFile 合并小文件既能减少 NameNode 元数据条目又能避免 Map 端大量小文件导致的 InputSplit 膨胀。SequenceFile 的写入逻辑很简单注意Writer关闭后不能继续追加Configuration conf new Configuration(); Path path new Path(/tmp/seq/part-00000.seq); SequenceFile.Writer.Option[] opts new SequenceFile.Writer.Option[]{ SequenceFile.Writer.file(path), SequenceFile.Writer.keyClass(Text.class), SequenceFile.Writer.valueClass(BytesWritable.class), SequenceFile.Writer.compression(SequenceFile.CompressionType.RECORD, new DefaultCodec()) }; SequenceFile.Writer writer SequenceFile.createWriter(conf, opts); Text key new Text(); BytesWritable value new BytesWritable(); key.set(file-001); value.set(bytes, 0, bytes.length); writer.append(key, value); writer.close();代码中每一个写法都有对应考点CompressionType.RECORD表示每条记录独立压缩随机读时能定位到某条记录直接解压若换成CompressionType.BLOCK则压缩比更高但读取时要把整个块载入内存解压。DefaultCodec使用 zlib压缩率中等偏上、CPU 占用高实验里如果数据是日志文本GzipCodec更合适若是压测环境图吞吐SnappyCodec更好。4.2 三种压缩编解码器的选型对比表Hadoop 压缩选型看两个指标压缩比与压缩速度二者不可兼得。常见编解码器对比如下实验报告可以直接引用编解码器压缩比压缩速度是否可切分适用场景DefaultCodeczlib高慢否冷数据存储GzipCodec高慢否日志归档BZip2Codec最高最慢是极高压缩率SnappyCodec中极快否中间数据、实时查询Lz4Codec中极快否高频写入“是否可切分”这一项在 MapReduce 里直接决定并行度。不可切分的压缩文件放在 HDFS 上一个文件只能由一个 Map 任务处理即使块被拆成两半也无解。因此实验里如果用 Gzip 归档大日志Map 阶段并行度等于文件数而不是块数想兼顾压缩与并行要么用 BZip2要么改用 LZO需要额外安装 native 库。4.3 用 SequenceFile 合并小文件的完整 Java 代码真实场景中把 HDFS 上一个目录下的全部小文件合并成一个 SequenceFile代码可复现如下public class SmallFileToSeq { public static void main(String[] args) throws IOException { Configuration conf new Configuration(); FileSystem fs FileSystem.get(conf); Path srcDir new Path(args[0]); Path seqFile new Path(args[1]); SequenceFile.Writer.Option[] opts new SequenceFile.Writer.Option[]{ SequenceFile.Writer.file(seqFile), SequenceFile.Writer.keyClass(Text.class), SequenceFile.Writer.valueClass(BytesWritable.class), SequenceFile.Writer.compression(SequenceFile.CompressionType.BLOCK, new GzipCodec()) }; SequenceFile.Writer writer SequenceFile.createWriter(conf, opts); FileStatus[] files fs.listStatus(srcDir); Text key new Text(); BytesWritable value new BytesWritable(); for (FileStatus file : files) { if (file.isDirectory()) continue; try (FSDataInputStream in fs.open(file.getPath())) { byte[] buffer new byte[(int) file.getLen()]; in.readFully(buffer); key.set(file.getPath().getName()); value.set(buffer, 0, buffer.length); writer.append(key, value); } } writer.close(); System.out.println(merged files: files.length); } }in.readFully保证一次循环把整个文件读进内存适合小文件如果文件平均超过 10MB就不要用这种方式改成IOUtils.copyBytes分块读。压缩选 BLOCK 而非 RECORD是因为这里读取要扫描全部记录BLOCK 压缩比更高Gzip 对文本日志能压到原体积的四分之一以下。4.4 读取 SequenceFile 并验证合并结果合并完成后必须验证内容与原始文件一致这一步是实验报告里的依据SequenceFile.Reader reader new SequenceFile.Reader(conf, SequenceFile.Reader.file(new Path(args[1]))); Text key new Text(); BytesWritable value new BytesWritable(); int count 0; while (reader.next(key, value)) { if (count 3) { System.out.println(key key , len value.getLength()); } count; } reader.close(); System.out.println(total records: count);验证时注意两点BytesWritable.getLength()才是真实长度getBytes()返回的数组可能大于实际长度拷贝时不能直接Arrays.copyOf(value.getBytes(), value.getLength())之外的做法容易读出脏尾部字节。另外若是用hdfs dfs -text查看 SequenceFile需要保证 key/value 类在 classpath 中否则输出二进制乱码。5. Hadoop IO 调优实战吞吐量、校验与实验验证技巧5.1 三组必调参数缓冲、并发与校验开关实验做到这一步报告里应该有一节“性能调优”。HDFS 客户端 I/O 表现受三处影响。缓冲上dfs.client.read.prefetch.sizeHDFS 2.x 后由dfs.client.read.prefetch.size控制默认 4MB决定每次读取预取数据量跑大文件顺序读时建议至少 8MBdfs.client-write-packet-size控制写入包大小64KB 与 128KB 之间通常有一个吞吐拐点。并发上客户端到 DataNode 的读连接由dfs.client.mmap.enabled和dfs.client.mmap.cache.size影响mmap 开启后读小文件省去用户态拷贝。校验上dfs.client.read.shortcircuit.skip.checksum若开启可提升吞吐但会失去数据完整性保护生产环境不建议开启实验里想对比校验开销可以分别在 true 与 false 下测同一文件读取时间。# 读取吞吐粗略测试读取 丢弃 hdfs dfs -cat /tmp/largefile.bin /dev/null5.2 用日志和 dfsadmin 验证调优效果调优不能只看“感觉变快了”要拿数据说话。实验环境可用以下链条验证。第一从写入侧观察吞吐使用hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-*-tests.jar TestDFSIO -write -nrFiles 4 -fileSize 128MB这是 Hadoop 自带压测工具输出会给出吞吐与平均 IO 速率。第二从系统侧观察磁盘队列用iostat -x 1看%util与await如果%util长期 90% 以上磁盘已是瓶颈调参数徒劳。第三从 HDFS 侧确认块分布均衡hdfs fsck /tmp/largefile.bin -files -blocks -locations能列出每个块与副本位置能直观看到 128MB 块与文件的映射。5.3 伪分布式环境下最容易踩的三个 IO 坑伪分布式与环境变量相关的坑最隐蔽。第一io.file.buffer.size默认 4096,用默认值跑大文件读写磁盘 IO 次数被放大数倍改为 131072 效果立竿见影。第二Hadoop 3.x 移植到新机器上常见Error: Could not find or load main class这通常是YARN相关 classpath 没配全排查时先hadoop classpath确认输出再决定去留不必急着重装。第三DataNode 与 NameNode 的dfs.datanode.data.dir落在同一块磁盘的两个分区看起来磁盘容量变大了实际写三副本时三个副本竞争同一块磁盘的 IO 队列写放大不降反升实验报告如果做了多目录配置建议声明“多目录不等于多磁盘”。5.4 实验结论部分可以这样写实验报告收尾时不要只写“完成文件上传下载”建议给出一个“HDFS IO 行为对照表”文件大小从 1MB 到 512MB测写时间、读时间和 NameNode RPC 次数hdfs dfsadmin -printTopology与 Namenode 日志做参考;序列化与压缩对比原始文本、Gzip 压缩前后体积、SequenceFile 记录数、压缩比;调优前后对照默认配置与调优后io.file.buffer.size131072、dfs.blocksize64MB下的吞吐差异。用几组数字写出实测结论比如“128MB 块下 512MB 文件写入耗时是 64MB 块下的 1.2 倍说明块大小并非越大越好”或“Snappy 压缩在写入场景下比 Gzip 快 3 倍但文件体积增加 20%”。这比“通过本次实验掌握了 HDFS”有价值得多。本文还有配套的精品资源点击获取 Hadoop IO实验报告：HDFS读写链路与调优实战
简介这份实验报告出自计算机系《云计算技术》课程以Hadoop IO为主题聚焦如何改写实验4的GetMerge程序从而将HDFS云端多个文件经过Gzip压缩后合并下载到本地。报告详细记录了实验目标、Eclipse环境下MapReduce项目的创建过程、核心代码片段以及实验结果同时体现了从Hadoop配置初始化、压缩器创建到数据流复制的完整流程适合正在学习Hadoop分布式文件系统读写与压缩编程的高校学生、云计算课程实践者参考。包体为1个PDF文件容量仅573KB内容精炼便于快速阅读和打印使用。目前已有307人学习下载。报告中重点展示了CompressionCodec、GzipCodec和IOUtils.copyBytes等API的实际用法并附有压缩工具类的初始化、压缩输出流创建等关键步骤说明对于想掌握HDFS数据本地化压缩处理、完成类似实验任务或撰写实验报告的人来说是一份有直接借鉴价值的参考材料。1. 云计算技术实验报告五Hadoop IO 到底在考察什么如果只把“云计算技术实验报告五 Hadoop IO”当成一次文件读写演示那实验做完你也不会留下多少东西反过来如果能看到这 8 个英文字母背后是 HDFS 的完整数据通路一次实验就能把分布式存储的副本放置、数据管道、序列化、压缩和调优串成一条线。多数人在这一步的困惑不是“命令不会敲”而是看不懂hdfs dfs -put之后发生了什么数据从客户端内存到 DataNode 磁盘中间经过几层缓冲、几次网络往返、哪些参数在起作用。这份实验报告本质上是在要求你完整复现并解释 Hadoop 的 I/O 路径而不是跑通一个 WordCount。本文按实验报告常见的五步骤展开先建立 HDFS 写入链路的心智模型再分别拆数据写、数据读、序列化与压缩、I/O 调优与验证最后落在实验课自己动手验证的关键技巧上。适合正在做《云计算技术》课程设计、需要提交 Hadoop 实验报告或者准备云计算相关岗位面试的人。2. HDFS 写入链路从 put 命令到三副本落盘2.1 客户端、NameNode 与 DataNode 三方协作的写入模型hdfs dfs -put看起来像一次普通文件复制实际由客户端、NameNode、DataNode 三个角色配合完成。客户端把文件按块切分默认块大小dfs.blocksize为 128MB每写一个块客户端先向 NameNode 发起addBlock请求NameNode 根据副本放置策略返回一组 DataNode 地址客户端再与这些 DataNode 建立管道pipeline执行写入。这个模型决定了 HDFS 写入的“一次写入、多次读取”语义——文件一旦关闭就不能修改适合分析型负载不适合随机写。副本放置策略是理解写入链路的第一关。默认策略dfs.replication3时第一个副本放在客户端所在节点如果客户端在集群外则随机挑一个负载较低的 DataNode第二个副本放在与第一个不同机架的节点第三个副本放在与第二个相同机架的另一节点。这个“机架感知”写法是为了平衡容错机架级故障不至于丢数据与写带宽跨机架网络流量有限。实验报告里如果你只搭了伪分布式那么三个副本实际上落在一个节点的三块不同磁盘目录里这一点要在报告中说明否则会让人觉得你不清楚副本与节点的区别。2.2 数据管道与 ack 机制每 512 字节要经过一次校验管道建立后客户端按dfs.client-write-packet-size默认 64KB打包数据包内又按 512 字节做 CRC32 校验。数据包按“客户端 → DataNode1 → DataNode2 → DataNode3”逐级传递每个 DataNode 收到包后先落盘再转发给下游然后以相反方向返回 ack。只有客户端收到管道中所有 DataNode 的成功 ack这个数据包才算写成功。这段逻辑你应该能复述清楚HDFS 不做写入后的异步复制而是用同步管道保证副本之间的一致性代价是写入延迟被拉高但读取时任意副本都是完整可用的。用命令验证管道写入状态时最直接的方法是看 DataNode 日志和系统网络连接# 在 DataNode 节点上查看与客户端或相邻 DataNode 的连接伪分布式时是本机回环 ss -tnp | grep java # 实时跟踪 DataNode 日志观察 block 接收和 ack 返回 tail -f $HADOOP_HOME/logs/hadoop-hadoop-datanode-*.log | grep -E Receiving|writeBlock|ack日志中如果频繁出现Timeout waiting for ack或Packet ack timeout说明管道中某个 DataNode 写入慢或网络抖动客户端会触发管道重建把故障节点剔除后重建剩余副本管道。这个行为在实验报告里可以作为“故障处理”小节写HDFS 的写入不是简单失败重试而是“定位故障节点 → 剔除 → 重建管道 → 补充副本”。2.3 写入链路中的核心参数速查与实测建议伪分布式做实验时以下参数和默认值会直接影响实测表现报告里建议用表格列出并说明调整后的效果参数名默认值作用实验建议dfs.blocksize128MB文件块大小调成 1MB 便于观察 block 分布dfs.replication3副本数伪分布式调成 1 避免报错dfs.client-write-packet-size64KB写入包大小调大可提升吞吐调小可降低延迟dfs.client.block.write.replace-datanode-on-failure.policyDEFAULT管道故障处理观察写入失败场景时保留默认值dfs.namenode.handler.count10NameNode 处理线程数小文件场景调大避免 RPC 积压实际写入性能与块大小的关系可以用一条时间线描述4KB 小文件配 128MB 块每个文件一个块每写一个文件都要与 NameNode 做一次 RPC而 1GB 文件配 128MB 块只需要 8 次块申请。因此块大小与文件大小匹配时吞吐最好这也是为什么实验里-put一个几 GB 的测试文件比大量小文件省时间。3. 读路径与本地性优化为什么 HDFS 读比写快3.1 从 DFSInputStream 到短路读的完整读链路HDFS 读取时客户端创建DFSInputStream先从 NameNode 拿文件块与副本位置的映射然后选择“最近”的副本建立 TCP 连接读取。这里的“最近”由dfs.client.use.datanode.hostname与网络拓扑共同决定客户端与 DataNode 在同一节点时优先读本地副本避免网络传输。读路径上数据不经过 NameNodeNameNode 只负责元数据与块定位所以读吞吐可以接近本机磁盘上限。实验报告里最常见的问题是“为什么读比写快很多”。原因有三个层面。一写入要同步复制三份至少产生两次跨节点传输读只需要一份数据。二写入要返回 ack每个数据包都有等待延迟而读是流水线式拉取一个连接上连续发请求。三HDFS 读取命中本地副本时直接走本地文件系统读不占网络。验证方法很直接# 对比读写同一文件的耗时在集群内某节点执行 time hdfs dfs -put /data/testfile.bin /tmp/testfile.bin time hdfs dfs -cat /tmp/testfile.bin /dev/null如果写耗时是读的 2 到 3 倍说明副本同步在起作用。若相差不大检查是否副本数被改成了 1。3.2 短路读让客户端绕过 TCP 直接读 DataNode 文件标准读路径上即使客户端在 DataNode 本机也要通过 TCP 把数据从 DataNode 的 50010 端口取回来。短路读Short-Circuit Read允许客户端直接以文件描述符映射方式读 DataNode 上的块文件省掉一次本机 TCP 回环。这是对“本地读还是走了网络栈”的优化实验环境里的效果可能不明显但面试会问。开启短路读需要配置两个地方。一是 DataNode 的dfs.domain.socket.path指定 socket 文件路径且目录权限要满足 DataNode 与客户端都可访问二是dfs.client.read.shortcircuittrue。伪分布式单节点下配置如下property namedfs.client.read.shortcircuit/name valuetrue/value /property property namedfs.domain.socket.path/name value/var/lib/hadoop-hdfs/dn_socket/value /property property namedfs.client.read.shortcircuit.skip.checksum/name valuefalse/value /property配置后建议在核心代码里执行一次测试小文件读取再从 DataNode 日志中确认短路读是否生效日志出现Setting up short-circuit read即成功。注意如果实验报告里只验证了hdfs dfs -cat短路读可能不触发因为 HDFS Shell 客户端默认走完整读路径用 Java API 的FSDataInputStream才稳定触发。3.3 小文件读放大效应对伪分布式实验的影响小文件问题在实验里被低估。每个文件、每块副本在 NameNode 内存里对应一条元数据记录默认每条约 150 字节一万个 1KB 小文件在 NameNode 里要占约 4MB 堆内存而读这些小文件时磁盘寻道开销远大于传输开销。实验报告建议补一个“小文件读放大”测试生成 10000 个 1KB 文件与 10 个 1GB 文件对比总读取时间。前者常见耗时是后者数倍原因是每个文件都要发起 RPC、建立连接、等待响应。伪分布式下 I/O 性能明显下降时第一步看是不是小文件撑爆了 NameNode 的 RPC 队列。可以查 NameNode 日志里的rpc相关统计或直接执行hdfs dfsadmin -report | grep -E Configured Capacity|Present Capacity|DFS Used|Total FilesTotal Files数量异常大且DFS Used很小就是小文件问题。缓解手段是har归档或 SequenceFile 合并这正好引出第四章的序列化与压缩。4. SequenceFile 与小文件合并实验里 IO 层面的序列化方案4.1 为什么 MapReduce 的中间数据需要 SequenceFileMapReduce 执行过程中Map 阶段输出写到本地磁盘Shuffle 阶段再把输出拉取到 Reduce 端。这个中间数据不是纯文本也不是普通二进制而是带 key 与 value 类型标识的序列化记录。Hadoop 官方方案是 SequenceFile一种二进制键值容器持久化 key 的类名与 value 的字节流读的时候能拿到类型信息。实验中用 SequenceFile 合并小文件既能减少 NameNode 元数据条目又能避免 Map 端大量小文件导致的 InputSplit 膨胀。SequenceFile 的写入逻辑很简单注意Writer关闭后不能继续追加Configuration conf new Configuration(); Path path new Path(/tmp/seq/part-00000.seq); SequenceFile.Writer.Option[] opts new SequenceFile.Writer.Option[]{ SequenceFile.Writer.file(path), SequenceFile.Writer.keyClass(Text.class), SequenceFile.Writer.valueClass(BytesWritable.class), SequenceFile.Writer.compression(SequenceFile.CompressionType.RECORD, new DefaultCodec()) }; SequenceFile.Writer writer SequenceFile.createWriter(conf, opts); Text key new Text(); BytesWritable value new BytesWritable(); key.set(file-001); value.set(bytes, 0, bytes.length); writer.append(key, value); writer.close();代码中每一个写法都有对应考点CompressionType.RECORD表示每条记录独立压缩随机读时能定位到某条记录直接解压若换成CompressionType.BLOCK则压缩比更高但读取时要把整个块载入内存解压。DefaultCodec使用 zlib压缩率中等偏上、CPU 占用高实验里如果数据是日志文本GzipCodec更合适若是压测环境图吞吐SnappyCodec更好。4.2 三种压缩编解码器的选型对比表Hadoop 压缩选型看两个指标压缩比与压缩速度二者不可兼得。常见编解码器对比如下实验报告可以直接引用编解码器压缩比压缩速度是否可切分适用场景DefaultCodeczlib高慢否冷数据存储GzipCodec高慢否日志归档BZip2Codec最高最慢是极高压缩率SnappyCodec中极快否中间数据、实时查询Lz4Codec中极快否高频写入“是否可切分”这一项在 MapReduce 里直接决定并行度。不可切分的压缩文件放在 HDFS 上一个文件只能由一个 Map 任务处理即使块被拆成两半也无解。因此实验里如果用 Gzip 归档大日志Map 阶段并行度等于文件数而不是块数想兼顾压缩与并行要么用 BZip2要么改用 LZO需要额外安装 native 库。4.3 用 SequenceFile 合并小文件的完整 Java 代码真实场景中把 HDFS 上一个目录下的全部小文件合并成一个 SequenceFile代码可复现如下public class SmallFileToSeq { public static void main(String[] args) throws IOException { Configuration conf new Configuration(); FileSystem fs FileSystem.get(conf); Path srcDir new Path(args[0]); Path seqFile new Path(args[1]); SequenceFile.Writer.Option[] opts new SequenceFile.Writer.Option[]{ SequenceFile.Writer.file(seqFile), SequenceFile.Writer.keyClass(Text.class), SequenceFile.Writer.valueClass(BytesWritable.class), SequenceFile.Writer.compression(SequenceFile.CompressionType.BLOCK, new GzipCodec()) }; SequenceFile.Writer writer SequenceFile.createWriter(conf, opts); FileStatus[] files fs.listStatus(srcDir); Text key new Text(); BytesWritable value new BytesWritable(); for (FileStatus file : files) { if (file.isDirectory()) continue; try (FSDataInputStream in fs.open(file.getPath())) { byte[] buffer new byte[(int) file.getLen()]; in.readFully(buffer); key.set(file.getPath().getName()); value.set(buffer, 0, buffer.length); writer.append(key, value); } } writer.close(); System.out.println(merged files: files.length); } }in.readFully保证一次循环把整个文件读进内存适合小文件如果文件平均超过 10MB就不要用这种方式改成IOUtils.copyBytes分块读。压缩选 BLOCK 而非 RECORD是因为这里读取要扫描全部记录BLOCK 压缩比更高Gzip 对文本日志能压到原体积的四分之一以下。4.4 读取 SequenceFile 并验证合并结果合并完成后必须验证内容与原始文件一致这一步是实验报告里的依据SequenceFile.Reader reader new SequenceFile.Reader(conf, SequenceFile.Reader.file(new Path(args[1]))); Text key new Text(); BytesWritable value new BytesWritable(); int count 0; while (reader.next(key, value)) { if (count 3) { System.out.println(key key , len value.getLength()); } count; } reader.close(); System.out.println(total records: count);验证时注意两点BytesWritable.getLength()才是真实长度getBytes()返回的数组可能大于实际长度拷贝时不能直接Arrays.copyOf(value.getBytes(), value.getLength())之外的做法容易读出脏尾部字节。另外若是用hdfs dfs -text查看 SequenceFile需要保证 key/value 类在 classpath 中否则输出二进制乱码。5. Hadoop IO 调优实战吞吐量、校验与实验验证技巧5.1 三组必调参数缓冲、并发与校验开关实验做到这一步报告里应该有一节“性能调优”。HDFS 客户端 I/O 表现受三处影响。缓冲上dfs.client.read.prefetch.sizeHDFS 2.x 后由dfs.client.read.prefetch.size控制默认 4MB决定每次读取预取数据量跑大文件顺序读时建议至少 8MBdfs.client-write-packet-size控制写入包大小64KB 与 128KB 之间通常有一个吞吐拐点。并发上客户端到 DataNode 的读连接由dfs.client.mmap.enabled和dfs.client.mmap.cache.size影响mmap 开启后读小文件省去用户态拷贝。校验上dfs.client.read.shortcircuit.skip.checksum若开启可提升吞吐但会失去数据完整性保护生产环境不建议开启实验里想对比校验开销可以分别在 true 与 false 下测同一文件读取时间。# 读取吞吐粗略测试读取 丢弃 hdfs dfs -cat /tmp/largefile.bin /dev/null5.2 用日志和 dfsadmin 验证调优效果调优不能只看“感觉变快了”要拿数据说话。实验环境可用以下链条验证。第一从写入侧观察吞吐使用hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-*-tests.jar TestDFSIO -write -nrFiles 4 -fileSize 128MB这是 Hadoop 自带压测工具输出会给出吞吐与平均 IO 速率。第二从系统侧观察磁盘队列用iostat -x 1看%util与await如果%util长期 90% 以上磁盘已是瓶颈调参数徒劳。第三从 HDFS 侧确认块分布均衡hdfs fsck /tmp/largefile.bin -files -blocks -locations能列出每个块与副本位置能直观看到 128MB 块与文件的映射。5.3 伪分布式环境下最容易踩的三个 IO 坑伪分布式与环境变量相关的坑最隐蔽。第一io.file.buffer.size默认 4096,用默认值跑大文件读写磁盘 IO 次数被放大数倍改为 131072 效果立竿见影。第二Hadoop 3.x 移植到新机器上常见Error: Could not find or load main class这通常是YARN相关 classpath 没配全排查时先hadoop classpath确认输出再决定去留不必急着重装。第三DataNode 与 NameNode 的dfs.datanode.data.dir落在同一块磁盘的两个分区看起来磁盘容量变大了实际写三副本时三个副本竞争同一块磁盘的 IO 队列写放大不降反升实验报告如果做了多目录配置建议声明“多目录不等于多磁盘”。5.4 实验结论部分可以这样写实验报告收尾时不要只写“完成文件上传下载”建议给出一个“HDFS IO 行为对照表”文件大小从 1MB 到 512MB测写时间、读时间和 NameNode RPC 次数hdfs dfsadmin -printTopology与 Namenode 日志做参考;序列化与压缩对比原始文本、Gzip 压缩前后体积、SequenceFile 记录数、压缩比;调优前后对照默认配置与调优后io.file.buffer.size131072、dfs.blocksize64MB下的吞吐差异。用几组数字写出实测结论比如“128MB 块下 512MB 文件写入耗时是 64MB 块下的 1.2 倍说明块大小并非越大越好”或“Snappy 压缩在写入场景下比 Gzip 快 3 倍但文件体积增加 20%”。这比“通过本次实验掌握了 HDFS”有价值得多。本文还有配套的精品资源点击获取