HDFS存储优化实战：从NameNode内存到写入性能的全链路调优

1. 从一次写入超时说起：HDFS存储优化的真实起点

很多人第一次接触HDFS存储优化，不是因为想优化，而是因为被逼的。我印象很深的一次，一个跑在Hadoop集群上的离线任务突然大面积超时，日志里全是DataStreamer Exception和Slow BlockReceiver。当时第一反应是网络问题，查了半天交换机、带宽、丢包率，全都正常。最后定位到根因，是NameNode堆内存吃紧，导致元数据操作响应变慢，连带整个写入链路卡死。

这件事让我意识到一个很朴素的道理：HDFS的存储优化，从来不是单纯“把磁盘换大”或者“把副本数调低”这么简单。它是一条从元数据管理、数据块布局、I/O路径到压缩编码的完整链路。任何一个环节出问题，都会以“写入慢”“读取慢”“NameNode卡顿”等形式暴露出来。

这篇内容适合谁看？如果你正在维护一套HDFS集群，或者准备搭建一套用于离线计算、日志存储、数据归档的分布式文件系统，那这里面的经验应该对你有用。如果你只是听说过HDFS但没实际碰过，也没关系，我会尽量用生活化的方式把原理讲清楚，再给出可以直接参考的配置和排查思路。

需要提前说明的是，HDFS的调优没有“万能参数”。不同业务场景——比如海量小文件、超大文件顺序写、随机读密集——对应的优化策略完全不同。所以我会先讲清楚每个优化动作背后的逻辑，再给出具体操作，这样你在自己的环境里才能判断该不该用、怎么用。

2. 元数据才是HDFS的命门：NameNode内存与RPC调优

2.1 为什么NameNode内存比DataNode磁盘更值得关注

很多人搭建HDFS集群时，把注意力全放在DataNode的磁盘容量上，觉得“存储优化”就是加盘。但实际上，HDFS的扩展性瓶颈往往先出现在NameNode上。原因很简单：NameNode在内存里维护整个文件系统的元数据，包括目录树、文件到块的映射、块到DataNode的映射。每一条记录都要占内存。

行业里有一个粗略的估算经验：每个文件、每个目录、每个块大约占用150到300字节的NameNode堆内存。注意，是每个块，不是每个文件。如果一个文件被切成100个块，那它占用的元数据内存就是文件本身条目加上100个块条目。这就解释了为什么“海量小文件”是HDFS的经典难题——不是磁盘存不下，而是NameNode内存先扛不住。

我见过一个典型场景：某业务每天产生几百万个几十KB的小文件，直接写入HDFS。跑了不到三个月，NameNode堆内存从8GB一路调到32GB还是紧张，Full GC频繁触发，整个集群的RPC响应时间从毫秒级恶化到秒级。后来通过合并小文件、引入归档存储，才把内存增长曲线压下来。

所以做HDFS存储优化，第一步应该是看NameNode的内存使用情况，而不是先动DataNode的磁盘。

2.2 NameNode堆内存的估算方法与JVM参数设置

估算NameNode需要多少堆内存，可以用一个简化的公式：

所需堆内存 ≈ (文件数 + 目录数 + 块数) × 200字节 × 冗余系数

冗余系数一般取2到3，因为JVM本身需要空间，而且元数据操作过程中会产生临时对象。举个例子，假设集群有1000万个文件、100万个目录、平均每个文件5个块，那么总条目数约为1000万 + 100万 + 5000万 = 6100万。按200字节算，约12.2GB，再乘以2.5的冗余系数，大约需要30GB堆内存。

对应的JVM参数配置，我通常这样设置：

# hadoop-env.sh 中 NameNode 的 JVM 配置 export HDFS_NAMENODE_OPTS="-Xmx30g -Xms30g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/hadoop/namenode-gc.log"

这里有几个关键点值得展开说。-Xmx和-Xms设成一样，是为了避免JVM堆动态伸缩带来的额外开销。用G1GC而不是CMS，是因为在大堆场景下G1的停顿时间更可控。InitiatingHeapOccupancyPercent=45表示堆使用率达到45%就开始并发标记周期，这个值比默认的45略低一些，给并发回收留出更多余量。GC日志一定要开，不然出了问题只能靠猜。

注意：NameNode的堆内存不是越大越好。堆太大，Full GC的停顿时间会显著增加。如果单机内存实在不够，可以考虑HDFS Federation方案，把命名空间拆分成多个独立的NameNode，每个管理一部分目录树。这是横向扩展NameNode的官方思路。

2.3 RPC队列与处理线程数的调整逻辑

NameNode的RPC处理能力直接决定了客户端读写请求的响应速度。有两个参数经常被忽略：

dfs.namenode.handler.count的估算公式来自社区实践：假设集群有100个DataNode，那么20 × ln(100) ≈ 20 × 4.6 ≈ 92，可以设置为90左右。如果设置太小，客户端请求会排队；设置太大，线程上下文切换开销会增加，反而降低吞吐。

我曾经遇到过一个案例：集群规模从50个节点扩展到200个节点后，没有调整这个参数，导致高峰期大量客户端报Call queue is full。把handler.count从10调到120之后，RPC队列积压问题明显缓解。但要注意，这个值不是越大越好，需要结合NameNode的CPU核数来定，一般不要超过CPU核数的两倍。

3. 数据块大小与副本策略：不是默认值就适合你

3.1 块大小的选择如何影响吞吐与元数据压力

HDFS默认块大小是128MB（Hadoop 2.x之后），早期版本是64MB。块大小的选择是一个典型的权衡：

• 块越大，NameNode需要维护的块条目越少，元数据压力越小；同时顺序读写时，每个块对应的寻址开销被摊薄，吞吐更高。
• 块越大，单个文件的最后一个块可能浪费更多磁盘空间；同时MapReduce任务的分片粒度变粗，可能影响并行度。

对于以顺序写为主的大文件场景（比如日志归档、视频存储），我通常会把块大小调到256MB甚至512MB。实测下来，在千兆网络环境下，256MB块比128MB块的顺序写吞吐能提升15%到20%。但如果你的业务是大量中等大小文件（比如几十MB到一两百MB），保持128MB更合适，避免单个文件只占一个块却浪费大量空间。

修改块大小可以在hdfs-site.xml中配置：

<property> <name>dfs.blocksize</name> <value>268435456</value> <!-- 256MB --> </property>

也可以在创建文件时通过API指定，但一般建议在集群级别统一配置，避免管理混乱。

3.2 副本系数：可靠性、存储成本与读取性能的三方博弈

副本系数默认是3，意味着每份数据存三份。这个设计的初衷是：在任何一个DataNode故障时，数据仍然有两个可用副本；在机架感知策略下，副本分布在不同的机架，即使整个机架断电也不丢数据。

但副本数不是越高越好。副本数每增加1，存储成本就增加一份，写入时的网络传输量也成倍增加。对于临时数据、可重新计算的数据（比如中间计算结果），完全可以把副本数降到2甚至1。

我的一般原则是这样的：

• 核心业务数据、不可再生数据：副本数3，保持默认。
• 可重算的中间数据、临时表：副本数2，节省存储和写入带宽。
• 测试环境、非关键日志：副本数1，但要做好数据可能丢失的心理准备。

设置副本数可以在文件级别指定：

hdfs dfs -setrep -w 2 /path/to/temp/data

-w表示等待副本调整完成再返回。对于目录，可以加-R递归设置。需要注意的是，降低副本数后，NameNode不会立即删除多余副本，而是等待下一次块报告时再处理，所以磁盘空间不会马上释放。

3.3 机架感知配置不当引发的写入性能下降

机架感知是HDFS副本放置策略的基础。默认情况下，HDFS采用“本地机架一个副本、远程机架一个副本、另一个远程机架一个副本”的策略。如果机架感知没有正确配置，所有DataNode都被认为在同一个机架，那么副本会随机放置，可能导致写入时跨机架流量激增。

配置机架感知需要两个步骤：一是编写一个脚本或Java类，根据节点IP返回机架路径；二是在core-site.xml中指定这个脚本。

<property> <name>net.topology.script.file.name</name> <value>/etc/hadoop/conf/topology.sh</value> </property>

一个简单的topology.sh示例：

#!/bin/bash # 根据IP返回机架路径 while [ $# -gt 0 ]; do case $1 in 192.168.1.*) echo "/rack1" ;; 192.168.2.*) echo "/rack2" ;; *) echo "/default-rack" ;; esac shift done

这个脚本需要根据实际网络拓扑来写。配置完成后，可以用hdfs dfsadmin -printTopology验证机架感知是否生效。如果输出中所有节点都在/default-rack下，说明配置没起作用，需要检查脚本权限和路径。

4. 小文件治理：从根源上缓解NameNode压力

4.1 小文件为什么是HDFS的“慢性病”

前面提到，每个块在NameNode内存中约占200字节。一个小文件如果只有几KB，但它仍然是一个独立文件，占用一个文件条目和一个块条目。假设有1亿个小文件，每个文件1个块，那就是2亿个条目，按200字节算就是40GB内存。这还只是元数据，不包括DataNode上的实际存储开销。

更麻烦的是，小文件会拖慢MapReduce和Spark任务。每个小文件可能对应一个Map任务，任务启动和调度的开销远大于实际数据处理时间。我见过一个作业处理10万个几KB的文件，跑了两个小时，其中大部分时间花在任务调度上，而不是数据计算上。

所以小文件治理不是“可选项”，而是HDFS存储优化中必须面对的问题。

4.2 合并小文件的三种实用方案对比

治理小文件，常见的有三种思路：

方案一：写入前合并。在数据进入HDFS之前，用Flume、Logstash等工具做聚合，或者用Spark的coalesce/repartition减少分区数，把多个小文件合并成一个大文件再写入。这是最根本的办法，但需要在上游系统改造，实施成本较高。

方案二：定期合并。用定时任务扫描小文件目录，通过MapReduce或Spark作业读取小文件并重写为大文件。Hadoop自带了一个FileCrush工具，也可以自己写脚本。这种方案适合已经存在大量小文件的历史数据。

方案三：归档存储。使用HAR（Hadoop Archive）或SequenceFile把小文件打包。HAR文件对NameNode来说是一个单独的文件，内部包含多个小文件，可以显著减少元数据条目。但HAR的读取性能不如原生文件，适合归档不常访问的数据。

三种方案的对比：

我个人的建议是：新业务尽量在写入前做合并，老数据用定期合并作业处理，极冷的数据用HAR归档。三者结合，基本能覆盖大部分场景。

4.3 用CombineFileInputFormat提升小文件读取效率

如果小文件已经存在，短期内无法合并，那么在读取端可以用CombineFileInputFormat来缓解。它的核心思路是：把多个小文件打包成一个InputSplit，让一个Map任务处理多个小文件，减少任务数量。

在MapReduce作业中配置：

job.setInputFormatClass(CombineTextInputFormat.class); CombineTextInputFormat.setMaxInputSplitSize(job, 256 * 1024 * 1024); // 256MB CombineTextInputFormat.setMinInputSplitSize(job, 128 * 1024 * 1024); // 128MB

这样设置后，多个小文件会被合并到同一个split中，Map任务数量大幅减少。实测下来，处理10万个平均50KB的文件，任务数从10万降到几十个，作业运行时间从小时级降到分钟级。

注意：CombineFileInputFormat只解决读取端的任务调度问题，不解决NameNode内存问题。元数据条目该占的内存还是占，所以它不能替代小文件合并。

5. 压缩与编码：用CPU换存储和I/O的经典交易

5.1 HDFS支持的压缩格式与选型依据

HDFS本身不强制压缩，但支持对存储的数据进行压缩。压缩的核心价值有两个：一是减少磁盘占用，二是减少网络传输量。代价是增加CPU开销。

常见的压缩格式对比：

“可分割”是一个关键属性。如果压缩格式不可分割，那么一个压缩文件只能由一个Map任务处理，无法并行。Gzip和Snappy都不可分割，所以不适合作为MapReduce输入的大文件压缩格式。LZO和Bzip2可分割，但LZO需要额外安装索引器。

Zstandard（zstd）是近几年比较推荐的格式，压缩比接近Gzip，但速度快很多，而且支持可分割。如果集群环境支持，我一般优先选zstd。

5.2 在写入链路中启用压缩的配置方法

在MapReduce作业中启用中间结果压缩：

<property> <name>mapreduce.map.output.compress</name> <value>true</value> </property> <property> <name>mapreduce.map.output.compress.codec</name> <value>org.apache.hadoop.io.compress.SnappyCodec</value> </property>

对于最终输出到HDFS的数据，可以在作业中设置：

FileOutputFormat.setCompressOutput(job, true); FileOutputFormat.setOutputCompressorClass(job, ZStandardCodec.class);

如果用的是Spark，配置类似：

spark.conf.set("spark.sql.parquet.compression.codec", "zstd")

Parquet和ORC这类列式存储格式自带压缩选项，一般推荐用zstd或snappy。列式存储加上压缩，通常能把存储空间降到原始文本的20%到30%。

5.3 压缩带来的CPU开销与集群负载平衡

压缩不是免费的。以Snappy为例，压缩和解压各需要消耗CPU，虽然速度很快，但在CPU密集型的作业中，额外的压缩开销可能拖慢整体进度。

我的经验是：如果集群的CPU利用率长期在70%以上，慎用高压缩比的格式；如果CPU有富余而磁盘或网络是瓶颈，那就大胆用压缩。可以通过压测来量化：对同一份数据，分别用不压缩、Snappy、Gzip跑一遍，记录作业耗时和资源使用情况，再决定用哪种。

另外，压缩格式的选择要考虑上下游兼容性。比如Hive表用zstd压缩，那么读取这张表的Spark作业也需要支持zstd，否则会报解码错误。在集群层面统一压缩格式，能避免很多麻烦。

6. 磁盘与I/O层优化：从硬件到配置的逐层排查

6.1 多磁盘挂载与DataNode磁盘选择策略

DataNode通常配置多块磁盘。默认情况下，HDFS会轮询使用所有可用磁盘目录。配置方式是在hdfs-site.xml中指定多个目录：

<property> <name>dfs.datanode.data.dir</name> <value>/data1/dfs/dn,/data2/dfs/dn,/data3/dfs/dn,/data4/dfs/dn</value> </property>

如果磁盘性能不一致（比如有的SSD有的HDD），可以通过dfs.datanode.data.dir的挂载点标签来区分。HDFS支持存储类型感知，可以把SSD标记为SSD，HDD标记为DISK，然后为不同目录设置不同的存储策略。

# 将数据目录标记为SSD hdfs storagepolicies -setStoragePolicy -path /hot/data -policy HOT

HOT策略表示所有副本都放在DISK上，ALL_SSD表示都放在SSD上，ONE_SSD表示一个副本在SSD其余在DISK。对于热数据，用ONE_SSD可以在成本和性能之间取得平衡。

6.2 磁盘吞吐瓶颈的识别与iostat实战分析

判断DataNode是否遇到磁盘瓶颈，iostat是最直接的工具：

iostat -x -d 2 10

重点关注几个指标：

• %util：磁盘利用率，持续接近100%说明磁盘饱和。
• await：平均I/O等待时间，包括排队时间。如果远高于磁盘的理论寻道时间，说明队列积压。
• r/s和w/s：每秒读写次数。对于HDD，随机读写IOPS通常只有100到200，如果这个值很高但吞吐上不去，说明是随机I/O瓶颈。

我曾经遇到一个案例：DataNode的%util长期在95%以上，但吞吐只有几十MB/s。查下来是因为大量随机读导致磁头频繁寻道。后来通过调整数据布局，把随机读改成顺序读，吞吐提升到200MB/s以上。

6.3 DataNode线程数与网络带宽的匹配调优

DataNode有两个关键线程参数：

dfs.datanode.max.transfer.threads控制的是同时进行的块传输数量。如果集群并发读写很高，这个值需要调大。但也不是无限调大，因为每个线程都消耗内存和文件描述符。一般建议根据DataNode的磁盘数量和网络带宽来估算：假设每块磁盘能支撑50MB/s的吞吐，千兆网卡理论带宽125MB/s，那么4块磁盘的节点，网络可能是瓶颈，线程数不需要太多；如果是万兆网卡，线程数可以适当增加。

dfs.datanode.handler.count一般保持默认即可，除非DataNode的RPC队列出现积压。可以通过DataNode的JMX指标监控RPC队列长度，如果持续大于0，说明需要增加处理线程。

7. 写入路径优化：从客户端到DataNode的全链路思考

7.1 HDFS写入流程的逐步拆解

理解写入路径是优化的前提。HDFS的写入流程大致如下：

1. 客户端调用create()，NameNode在命名空间中创建文件条目，返回一个FSDataOutputStream。
2. 客户端开始写数据，数据先写入本地缓冲区。
3. 当缓冲区达到一个块的大小（默认128MB）或手动flush时，客户端向NameNode申请一个块，NameNode返回一组DataNode（默认3个）作为写入管道。
4. 客户端把数据包发送给管道中的第一个DataNode，第一个DataNode收到后转发给第二个，第二个转发给第三个。
5. 每个DataNode收到数据后写入本地磁盘，并向上游发送ACK确认。
6. 当所有DataNode确认写入完成，客户端继续写下一个数据包。

这个管道式写入的优点是充分利用了网络带宽，缺点是任何一个节点慢都会拖累整个管道。所以写入性能优化，本质上是让管道中每个环节都不成为瓶颈。

7.2 客户端缓冲区与数据包大小的调整

客户端写入缓冲区大小由dfs.client-write-packet-size控制，默认是64KB。对于高延迟网络或大文件顺序写，可以适当调大：

<property> <name>dfs.client-write-packet-size</name> <value>131072</value> <!-- 128KB --> </property>

调大packet size可以减少网络往返次数，提升吞吐。但也不能太大，否则单个packet的传输时间变长，一旦失败重传的代价也更大。一般128KB到256KB是比较稳妥的范围。

另外，dfs.client.write.max-retries和dfs.client.write.timeout也值得关注。在网络不稳定的环境中，适当增加重试次数和超时时间，可以避免因偶发网络抖动导致的写入失败。

7.3 写入管道故障的排查与恢复经验

写入管道中最常见的问题是“慢节点”拖累整个管道。HDFS本身有一定的容错机制：如果某个DataNode响应慢，客户端会将其从管道中移除，用新的DataNode替换。但这个过程需要时间，而且会导致当前数据包重传。

排查慢节点，可以看DataNode的BlockReceiver相关日志，搜索Slow BlockReceiver关键字。如果某个节点频繁出现这个日志，说明它的磁盘或网络有问题。

我处理过的一个案例：一个DataNode的磁盘出现坏道，写入时频繁重试，导致整个写入管道吞吐从100MB/s降到10MB/s。把该节点下线后，写入恢复正常。所以定期检查DataNode磁盘健康状态，比事后排查更重要。

可以用smartctl检查磁盘SMART信息：

smartctl -a /dev/sdX | grep -E "Reallocated_Sector|Current_Pending_Sector"

如果Reallocated_Sector_Ct或Current_Pending_Sector的值持续增长，说明磁盘正在退化，应该尽快更换。

8. 实际调优案例：一次集群写入性能提升的完整过程

8.1 问题现象与初步定位

某离线计算集群，规模约80个DataNode，运行Spark和MapReduce作业。业务方反馈：最近一个月，写入HDFS的速度明显变慢，原来10分钟能跑完的作业，现在要30分钟以上。

初步排查：网络带宽正常，交换机无告警；DataNode磁盘%util平均在60%左右，不算饱和；NameNode的RPC队列偶尔有积压，但不严重。看起来每个环节都“还行”，但整体就是慢。

8.2 从NameNode GC日志发现元数据瓶颈

打开NameNode的GC日志，发现Full GC频率从每天1到2次增加到每小时1到2次，每次停顿3到5秒。在Full GC期间，所有RPC请求都会挂起，客户端写入自然变慢。

进一步分析堆内存使用，发现元数据条目数在过去一个月增长了40%，主要来自一个新上线的业务，每天产生大量小文件。NameNode堆内存虽然设了24GB，但实际使用率长期在85%以上，GC压力很大。

8.3 组合拳：小文件合并加副本策略调整

针对这个问题，我们采取了三个措施：

第一，对新业务的小文件做写入前合并。在Spark作业中增加repartition，把输出文件数从每天几十万降到几千。这一步实施后，NameNode元数据增长速度明显放缓。

第二，对历史小文件做定期合并。写了一个Spark作业，每天凌晨扫描小文件目录，把小于10MB的文件合并成128MB的大文件。合并后删除原文件，NameNode元数据条目减少了约30%。

第三，对临时数据降低副本数。把中间计算结果目录的副本数从3降到2，节省了约20%的存储空间和写入带宽。

8.4 调优后的效果验证与后续监控

调整完成后，观察了一周：

• NameNode Full GC频率从每小时1到2次降到每天1次。
• 写入作业平均耗时从30分钟降到12分钟。
• DataNode磁盘%util从60%降到45%，I/O压力减轻。

后续建立了监控看板，重点跟踪NameNode堆内存使用率、GC停顿时间、RPC队列长度、DataNode磁盘%util和写入吞吐。一旦某个指标偏离基线，就能提前介入，避免问题积累到影响业务。

这个案例给我的最大体会是：HDFS存储优化不能头痛医头。写入慢的表象背后，可能是元数据膨胀、小文件过多、副本策略不合理等多个因素叠加。只有从全链路视角去分析，才能找到真正的根因。

9. 日常运维中值得固化的几个习惯

9.1 建立NameNode和DataNode的基线指标

没有基线就没有异常判断。我习惯在集群稳定运行一段时间后，记录一组基线指标：NameNode堆内存使用率、GC频率和停顿时间、RPC队列长度、DataNode磁盘%util、网络吞吐、块报告间隔。这些指标不需要实时告警，但每周对比一次，就能发现趋势性变化。

比如NameNode堆内存如果每周增长2%，看起来不多，但三个月后就会逼近上限。提前发现这个趋势，就有时间做小文件治理或扩容，而不是等到Full GC频繁触发才手忙脚乱。

9.2 定期做小文件扫描与合并作业

小文件治理不是一次性的。新业务不断上线，小文件会持续产生。所以我把小文件扫描和合并做成了定时作业，每周跑一次。扫描逻辑很简单：遍历指定目录，统计文件大小分布，找出小于阈值的文件，输出报告。合并作业根据报告决定是否执行。

阈值怎么定？我一般用块大小的十分之一作为小文件标准。如果块大小是128MB，那么小于12.8MB的文件就算小文件。这个标准可以根据业务特点调整，但核心思路是：文件大小应该尽量接近块大小，避免一个块只存一点点数据。

9.3 压缩格式的统一与上下游兼容性检查

压缩格式不统一是运维中的常见坑。比如Hive表用Snappy压缩，Spark作业默认用zstd读取，就会报错。所以我在集群层面做了规定：所有持久化数据统一用zstd压缩，中间数据用Snappy。新业务上线前，必须确认压缩格式与集群标准一致。

另外，压缩格式的兼容性不仅涉及计算引擎，还涉及数据交换。如果数据要导出到其他系统，对方可能不支持zstd。这种情况下，可以在导出时转成Gzip或未压缩格式，但要在导出流程中明确处理。

9.4 磁盘故障的早期发现与数据再平衡

磁盘故障在HDFS集群中是常态，不是异常。关键是早发现、早处理。除了前面提到的SMART检查，还可以通过DataNode的块扫描器（BlockScanner）日志发现坏块。如果某个DataNode的坏块数量突然增加，说明磁盘可能有问题。

发现磁盘故障后，第一步是把该节点上的数据再平衡到其他节点。可以用hdfs balancer命令：

hdfs balancer -threshold 10

-threshold 10表示磁盘使用率差异超过10%才开始平衡。这个值可以根据集群规模调整，小集群可以设小一点，大集群设大一点，避免频繁触发平衡操作。

再平衡过程中要注意网络带宽，避免影响正常业务。可以设置dfs.datanode.balance.bandwidthPerSec限制平衡带宽：

<property> <name>dfs.datanode.balance.bandwidthPerSec</name> <value>104857600</value> <!-- 100MB/s --> </property>

这个值需要根据集群网络情况来定。如果业务高峰期网络紧张，可以调低；夜间空闲时可以调高。

10. 关于HDFS存储优化，我踩过的几个坑

第一个坑是盲目调大NameNode堆内存。早期遇到NameNode内存不足，第一反应就是加-Xmx。结果堆从16GB加到32GB，Full GC停顿时间反而从2秒增加到8秒。后来才明白，堆越大，GC扫描的对象越多，停顿时间越长。正确的做法是先做小文件治理，减少元数据条目，而不是一味加内存。

第二个坑是忽略机架感知配置。有一次集群扩容，新加的节点没有正确配置机架感知，所有新节点都被认为是同一个机架。结果写入时副本放置策略失效，跨机架流量激增，网络带宽被打满。后来补上机架感知配置，问题才解决。

第三个坑是压缩格式选错。曾经为了追求高压缩比，把归档数据全用Bzip2压缩。压缩比确实高，但解压速度太慢，读取时CPU成为瓶颈，查询性能下降明显。后来换成zstd，压缩比略低但速度快很多，整体体验更好。

第四个坑是副本数调整后忘记等待。有一次把临时数据的副本数从3降到1，以为磁盘空间会立即释放，结果发现磁盘使用率没变化。后来才知道，NameNode需要等到下一次块报告才会删除多余副本，而且删除是异步的。所以调整副本数后，要留出足够的时间让集群完成数据清理。

这些坑的共同点是：看起来都是“参数调整”的小事，但背后涉及HDFS的内部机制。如果不理解机制，只照搬参数，很容易踩坑。所以我在做任何优化之前，都会先问自己：这个操作会影响哪些组件？数据流会怎么变化？有没有副作用？想清楚这些，再动手。