做大数据平台有些年头了，前后接触过的存储方案不算少，但要论最绕不开的那个，还得是 HDFS。不管上层是 Hive、Spark 还是 Flink，只要落库到 Hadoop 生态，最终数据几乎都会躺进 HDFS。很多人觉得它只是一个“能存大文件的分布式文件系统”，这句话没错，但太表面了。真正把海量数据跑起来之后你会发现，HDFS 的存储机制直接决定了集群的容错能力、扩缩容方式和排障思路。这篇文章我会把它的存储机制拆开讲透，再用实际运维里的经验告诉你，它的优势到底怎么用才发挥得出来。
写这篇文章的初衷很实在，给三类人看：刚接触大数据、想搞懂 HDFS 底层原理的初学者；负责集群维护、经常要排查存储问题的运维；还有准备面试、需要把机制讲清楚而不是背概念的人。我会尽量用大白话，但该有的细节一个不落。
1. HDFS 到底在解决什么问题
1.1 单机存储的物理天花板
先想一个简单场景。你的业务每天产生 10TB 日志，一台服务器挂 8 块 2TB 的盘，理论上能存 16TB，看起来够用一天。可第二天呢？第三天呢？就算你不断加盘，单机能驱动的磁盘数量是有限的，机箱空间、电源功率、主板接口都在约束你。传统做法是搞一台大的磁盘阵列，用 RAID 把一堆盘捆成一个逻辑卷。但 RAID 的成本高，扩展时要停机或者迁移，而且它解决的是“单台机器上多块盘”的问题，解决不了“多台机器联合存储”的问题。
大数据场景的真正麻烦在于：数据量不是 TB 级，而是 PB 级甚至更大。你必须把数据分散到很多台普通服务器上，让它们像一个整体一样提供服务。你需要的不是一个高性能的单点存储，而是一个能水平扩展、愿意接受普通硬件、不怕磁盘坏的系统。这就是 HDFS 出现的最核心原因：用成百上千台廉价服务器，构建一个逻辑上统一的超大文件系统。
1.2 硬件故障是常态，不是意外
单台服务器上，硬盘年故障率通常有百分之几，听起来不高。但当你拥有 5000 台机器、每台 12 块盘，那就是 6 万块盘在同时转。按故障率估算，每天坏几块盘很正常。传统文件系统遇到磁盘损坏，顶多影响那台机器上的数据，但如果数据没有冗余，业务就直接中断。
HDFS 的设计思路从这里就转变了：它默认不信任硬件，而是通过数据副本机制把“单点故障”变成“日常可容忍故障”。数据被切成块，每个块在多个节点上保存副本，某个节点宕机了，其他节点上的副本还在，系统继续工作。这个概念现在听起来很自然，但你要知道，在设计 HDFS 的年代，把“故障容错”当作第一优先级，是很超前的事情。
2. 存储机制的核心：块、副本与元数据
2.1 主从架构和两个关键角色
HDFS 是典型的主从架构，集群里通常有一个 NameNode 和多个 DataNode。NameNode 管元数据，也就是“这个文件叫什么、分成哪些块、每个块放在哪台机器上”；DataNode 管实际数据，也就是真正把数据落到本地磁盘上。你可以把 NameNode 想象成图书馆的总目录，DataNode 就是书库里一排排书架。你想找一本书，先查总目录，再去对应书架拿。
日常运维里，NameNode 的稳定压倒一切。它不存数据本身，但一旦它挂了，整个集群就失去导航，客户端不知道该去哪个节点找数据。所以生产环境里 NameNode 的高可用配置几乎是标配，用两个节点做 active/standby，共享编辑日志。DataNode 就没那么娇贵，坏一台，系统会自动把它的块副本在其他节点上补出来。
2.2 块存储：为什么默认是 128MB
HDFS 里文件被拆成一个个 block，默认大小是 128MB（老版本是 64MB）。每次读写都以块为单位，而不是以文件为单位。这个小设计带来两个直接好处：一是文件可以比单块磁盘大，一个 1TB 的文件可以划分成 8000 多个块，均匀散落在几十台机器上；二是块是固定大小的逻辑单元，NameNode 管理块信息比管理海量小文件信息要轻松得多。
很多人问过：为什么偏偏是 128MB，不是 64MB 也不是 1GB？这里有个平衡。块太大，意味着 MapReduce 或 Spark 在处理时，单个任务的输入数据量太大，并行度下降；块太小，元数据膨胀，NameNode 内存压力大，磁盘寻址开销也高。128MB 是在“单任务处理量”和“元数据开销”之间取的一个经验值。如果你的集群任务普遍是大规模扫描，可以适当调大到 256MB；如果文件平均体积偏小，那就别盲目调大，不然小文件会“堵”在单个块里，并行度反而降低。
2.3 副本机制与机架感知
HDFS 默认给每个块保存 3 个副本。副本数可以通过配置dfs.replication调整，但 3 是最常用的选择：既能扛住一两个节点同时故障，又不会让存储成本高到离谱。我见过有人为了省空间把副本降到 2，结果某次机架交换机故障，一批数据同时丢了两副本，恢复起来非常痛苦。副本不仅是容错手段，还能提升读取吞吐，多个客户端可以从不同副本读取同一个块。
副本放在哪，不是随机的，这里有个机架感知的概念。默认策略是：第一个副本放在客户端所在节点（如果客户端在集群外，就挑一个空闲节点）；第二个副本放在不同机架的某个节点；第三个副本放在与第二个副本相同机架但不同节点的位置。这样做的好处是，既能防止整个机架掉电导致数据全丢，又能减少跨机架的数据传输开销。在规划物理机架时，一定要上报机架拓扑信息，否则系统把全部副本都放到同一个机架，机架故障就是灾难。
2.4 元数据的落地方式：FsImage 和 EditLog
NameNode 里的元数据不是只存在内存里，它需要持久化。HDFS 用两个文件配合：FsImage 是元数据的“快照”，EditLog 是从快照之后所有变更操作的“流水账”。每次重启或触发 checkpoint 时，NameNode 会把 EditLog 合并进 FsImage，形成新的快照。
这里有个常见的误解：SecondaryNameNode 不是 NameNode 的备份，它干的事是定期拉取 FsImage 和 EditLog，在内存里合并，再把新的快照传回 NameNode，帮主节点“减负”。如果主 NameNode 挂了，SecondaryNameNode 顶多能减少恢复时间，但它无法直接变成主节点。生产环境要的是双机热备，而不是靠 SecondaryNameNode 当救兵。
3. 读与写的完整流程，到底发生了什么
3.1 写入流程：从客户端到管道
在 HDFS 里写一个文件，过程比你想象的要复杂，目的是保证数据不丢、副本一致。以客户端上传一个 300MB 的文件到集群为例：
- 客户端调用
create，向 NameNode 发起 RPC 请求。 - NameNode 检查文件是否已存在、权限是否足够，然后在命名空间里创建文件条目，但此时数据还没写。
- 客户端开始把文件切分成块，默认 128MB 一块，向 NameNode 申请第一个块的 DataNode 列表。
- NameNode 返回一组 DataNode 地址，这些地址已经按照机架感知策略排好了顺序，比如 dn1、dn2、dn3。
- 客户端与 dn1 建立连接，dn1 再与 dn2 连接，dn2 再与 dn3 连接，形成一个管道。
- 客户端把数据拆成更小的 packet，逐个推送到管道里。每个 DataNode 收到 packet 后，边写本地磁盘边转发给下一个节点。
- 下游节点写完后逐级向上返回确认信息（ack），客户端收到整个块的确认后，再向 NameNode 汇报块已提交。
这个流程最关键的是“管道复制”而不是“客户端分别发给三个节点”。如果客户端复制三份，那么网络负载会翻三倍，而且三个节点的写入进度很难对齐。用管道方式，数据只走一条链路，节点间自动接力，效率和一致性都更好。
3.2 副本同步的失败处理
管道复制过程中最怕的是某个 DataNode 中途挂掉。假设 dn2 正在写，dn1 已经写完并转发了数据给 dn2，但 dn2 还没把 ack 传回，连接就断了。这时客户端会收到异常，HDFS 的处理策略是：
- 把未确认的块重新加入写入队列。
- 告诉 NameNode 撤销 dn2 的状态。
- 从剩余正常节点中选一个新节点，继续建立管道。
- 写入结束后，NameNode 发现副本数不足，会自行安排另一个副本补上。
这些流程对上层应用几乎是透明的。你只需要知道，HDFS 在设计上已经把“写入过程中节点故障”当成默认会发生的事，而不是意外。
3.3 读取流程：就近读是最实在的优化
读取比写入简单，但也有讲究。客户端请求读取某个文件时，先从 NameNode 拿到文件所有块的存储位置列表，然后客户端根据“网络距离”选择最近的副本。距离的计算规则一般是这样：本机优先，本机架次之，同机房再次，最后才是跨机房。距离越短，数据传输越快，也越省核心带宽。
实际生产中，我发现“就近读”一个容易被忽略的点是计算与存储的协同部署。如果你用独立的计算集群去读 HDFS，客户端节点不在 DataNode 上，每条数据都要走网络，吞吐量浮动很大。把 Spark 或 Hive 的 Worker 和 DataNode 混布在同一批机器上，读数据时很多块可以走本机磁盘，性能提升立竿见影。这也是很多生产集群采用“存储计算一体化”部署的原因。
3.4 删除与覆盖写：别拿它当普通文件系统
HDFS 的删除不是即时物理删除。文件被删除后会先进入回收站（trash），默认保留一段时间（比如 6 小时），超过保留时间才真正清除。这个设计让我在无数次误删后还能救回数据，所以建议不要为了省那点空间把fs.trash.interval设成 0。
HDFS 对文件的修改支持非常有限。它不支持随机写，也不支持任意位置的追加以外的大改，追加写还要确认管道是打开的。为什么限制这么死？因为支持任意修改，就要引入复杂的并发控制和一致性协议，这对一个面向海量批处理场景的系统来说性价比极低。如果你需要频繁更新或删改单条记录，应该把 HDFS 当底层存储，在上面接 HBase 之类的组件，而不是硬怼 HDFS 去改文件。
4. HDFS 的优势，以及那些“看起来不太行”的地方
4.1 优势到底体现在哪
聊优势要落到指标上，不能空泛地说“可靠”“高可用”。我列几个平时最有感的方面：
- 海量数据支持：一个集群可以存上百 PB 数据，单文件可以远超单机磁盘容量，这是传统文件系统很难做到的。
- 水平扩展能力：数据不够了，加 DataNode 节点就能扩容，不需要停机迁移旧数据，新节点会自动参与数据均衡。
- 容错与自愈：默认 3 副本，节点宕机后系统会自动重新复制副本，不需要人工介入。一块坏盘在传统系统里是事故，在 HDFS 里只是日常。
- 高吞吐量：HDFS 追求的是批量读写的大吞吐，而不是单条数据的低延迟。把块做大、顺序读写、管道复制，都是围绕吞量设计的。
- 低成本硬件适配：不强制要求高性能存储设备，SATA 盘、普通服务器都能撑起一套集群。
再补充一句，HDFS 的“一次写入、多次读取”模型特别适合离线分析。日志收集进来之后基本不修改，后续所有计算都是扫描式读取，这种工作负载正好踩在 HDFS 的优势区。
4.2 绕不开的短板
把 HDFS 吹上天不负责，它有几条明显的边界，知道这些边界才不会用错地方：
- 低延迟访问不行：读写一次要经过 NameNode 调度、网络传输、管道确认，单次访问延迟在毫秒到几十毫秒不等，做不了实时在线业务。
- 小文件噩梦：每个文件、每个块都要在 NameNode 内存里占一条记录。如果存 1000 万个 1KB 小文件，内存和磁盘寻道都会扛不住。官方建议 NameNode 内存至少能覆盖所有对象，实际经验是尽量把文件合并成 SequenceFile 或 ORC 这种大文件。
- 并发写限制：同一个文件同一时刻只能有一个写入者，也不支持并发追加。多任务同时写同一个目录没问题，但写同一个文件的并发能力很差。
- 修改代价大：不支持高效的随机写和文件局部更新，如果业务需要频繁更新数据，它的模型会让你很难受。
拿 HDFS 和传统 NAS 做对比，就像拿仓库和快递柜比。快递柜取件快、适合小包裹，但仓库能堆几千吨货。你要是让快递员把每件小东西都搬进大仓库，仓库的管理员会疯掉；反过来，你要让快递柜存几十吨货，它根本装不下。理解了这个比喻，你就懂 HDFS 该用在什么场景了。
5. 常见问题与排查技巧实录
5.1 写入速度上不去，但 CPU 和内存都不忙
遇到这种问题，先别怀疑集群坏了，按下面顺序排查：
- 用
hdfs dfsadmin -report看有没有节点处于异常状态，副本数量是否齐。 - 检查网络，尤其是跨机架带宽。HDFS 管道写入时，数据要经过多个节点，跨机架交换机经常是瓶颈。
- 查磁盘 IO。DataNode 同时写多块盘，如果有某块盘是 SATA 且没做 RAID，写并发很容易被拖死。建议 DataNode 数据目录分布在多块物理磁盘上，不要都堆在同一块盘。
- 看看是否有小文件大量写入。每个小文件写操作都要和 NameNode 做多次 RPC，RPC 队列一长，整体吞吐立刻下滑。
我接手过一集群，现象是白天写入很慢，晚上就好了。查了半天，发现是某个实时采集任务白天高频写大量小文件，NameNode 的 RPC 处理线程被打满。后来把采集任务改成先合并再上传，问题直接消失。
5.2 块副本数一直不满足（Under Replicated）
hdfs fsck /path -files -blocks -locations是排查数据健康度的利器。输出里如果看到Under replicated的块，就要引起注意。常见原因有三种：
- 某个 DataNode 宕机，副本数暂时减少。正常等系统自动复制即可。
- 磁盘损坏，块副本永久丢失。
- 文件被设置了更低的副本系数。
强制恢复的手段是执行hdfs dfs -setrep -R 3 /path，把目录下所有文件的副本数重新设为 3。注意，这命令只对当前文件生效，之前已经损坏且无法恢复的数据是救不回来的，所以重要数据不要只依赖默认 3 副本，关键目录可以单独设置更高副本。
5.3 NameNode 内存居高不下，甚至频繁 Full GC
NameNode 内存主要被文件、目录、块这几种元数据对象占着。对象越多内存越大，小文件多时尤其明显。排查时先看hdfs dfsadmin -report里的文件数和块数，再结合实际内存配置估算。经验公式大致是：每个文件对象约 150 字节，每个块约 150 字节，目录也类似。1000 万个小文件，光元数据就要好几个 GB。
解决思路有两个：一是合并小文件，二是调大 NameNode 堆内存。在原有数据已经堆积的情况下，更实际的办法是定期把小文件目录通过文件合并工具重写成大文件。单纯的加内存只是延长了爆炸时间，不是根治。
5.4 误删文件或者目录
先冷静，检查回收站。默认的回收站目录在/user/当前用户名/.Trash下，只要没超过保留时间，用hdfs dfs -mv就能把文件搬回来。回收站在命令行下可能要用hdfs dfs -ls .Trash/Current/查看。我在一次项目里误删了整个 ods 层某个分区，靠回收站花了十分钟恢复，当时手都在抖。
注意，如果用了hdfs dfs -rm -skipTrash，文件会直接删除，回收站拦不住。所以除非你非常确定不要，否则别轻易带-skipTrash。
5.5 集群磁盘使用不均
新节点加入后，HDFS 并不会自动把所有历史数据立即均衡到新节点。默认情况下，没有hdfs balancer运行时，写入的新数据会偏向新节点，旧数据留在老节点。过一阵子就会出现“有些节点 90% 满，有些节点 40% 满”的怪异局面。
处理办法是手动执行hdfs balancer -threshold 5，让系统自动把数据从高负载节点搬到低负载节点，直到各节点使用率差异控制在 5% 以内。但别在业务高峰期跑，它占带宽，建议维护窗口期执行。还有一种静默手段是调整dfs.datanode.balance.bandwidthPerSec，压低均衡速度，避免影响正常读写。
6. 容量规划与日常维护的几条实战建议
6.1 副本数不要随意调低
存储成本压力大的时候，有人会把全局副本数改成 2，甚至 1。我劝你不要这么干。副本数每降一档，容错能力就指数级下降。如果你确实想省空间，优先考虑：把不重要的临时数据放单独的目录，单独设置副本为 2，并做好数据生命周期清理，而不是把全局副本数下调。
6.2 块大小要按数据特征适配
如果你主要跑的是大规模离线计算，文件都很大，可以把块大小调到 256MB，减少元数据量。如果文件平均大小只有几十 MB，块大小保持 128MB 就好，甚至可以考虑把多个小文件打包。说到底，块大小是为了让任务并行度和元数据开销达到平衡，不经过实测就拍脑袋调参数，往往适得其反。
6.3 机架感知一定要配置
新集群搭建时，最值得花时间的就是把机架拓扑上报配置好。默认不配置时，HDFS 会认为所有节点都处在同一个机架，后果是副本可能全落在同一个物理机架里。某个机架的交换机一出问题，该机架上的所有副本同时失联。这个坑我见过不止一次，都是到了故障发生时才补救，非常被动。把拓扑配置做好后，副本会自动跨机架分布，虽然多一点点网络消耗，但换来的安全边际太高。
6.4 谨慎使用权限命令
HDFS 的权限模型其实很朴素，但它挡不住误操作。以前我遇到过有人用hdfs dfs -chmod -R 777 /把整个集群根目录权限全放开，结果任何用户都能看数据和删除数据。你在生产环境里对根目录或重要数据目录执行递归权限变更前，一定要三思。权限变化不像删除那样有明显提示，等你发现数据被清掉时，往往连源头都追不到了。
7. HDFS 的后续延伸：它和对象存储、云存储的关系
现在很多新项目会直接上对象存储，比如兼容 S3 接口的存储服务，不少人就问：那 HDFS 是不是过时了？我的看法是，它们解决的问题高度重叠，但各有侧重。对象存储对外的接口简单，做到无限扩展和低成本，适合存静态文件和数据湖。HDFS 的优势在于它和计算框架的集成度极高，尤其是需要把存储本地化以提升计算性能的场景，HDFS 的数据本地性调度依然很香。
很多云上架构采取的是并行方案：热数据放 HDFS，让 Spark 和 Hive 直接读本地块；冷数据归档到对象存储，降低存储成本。这个组合在实践中非常普遍。所以别抱着“HDFS 要被淘汰了”的想法，它依然是离线大数据生态里的地基之一。
从我个人经验来说，判断一个存储系统好不好用，不能只看峰值性能，要看它在日常故障、扩容、权限误操作这些乱七八糟的情况里能不能稳住。HDFS 不是完美的系统，它的启动速度、小文件表现、低延迟能力都有明显短板，但当你的场景是海量离线数据、批处理分析、日志归档，它依然是最不容易翻车的那一个。把它的存储机制理解透了，你才算真正迈进了大数据存储的大门。
