吕欣团队《大数据平台架构》第四章读书笔记：HDFS——把一块硬盘“拆”成一整个数据中心

最近在系统地补 Hadoop 的基础设施部分，第四章讲的是 HDFS（Hadoop Distributed File System）。这一章看下来最大的感受是：HDFS 本质上不是一个“文件系统增强版”，而是一种完全围绕“大规模数据处理”重新设计的存储哲学。

以前学操作系统时，总觉得文件系统无非就是“目录 + 文件 + 权限 + 磁盘块”。但 HDFS 让我意识到，当数据规模上升到 TB、PB 甚至 EB 级别时，传统文件系统的很多设计假设都不成立了。这个时候，思路不再是“如何把文件存在一块硬盘上”，而是“如何让成百上千台机器看起来像一块巨大的硬盘”。

一、从 GFS 到 HDFS：Google 又一次定义了问题

HDFS 的故事，几乎就是 Google 的 GFS（Google File System）论文的开源续作。

2003 年 Google 发表 GFS 论文时，核心问题很现实：搜索引擎每天要抓取海量网页，数据量大到传统存储方案既贵又不好维护。Google 的答案非常“工程师思维”：

• 与其买昂贵的高可靠服务器，不如接受廉价机器经常坏掉；

• 与其追求低延迟，不如追求高吞吐；

• 与其复杂地支持随机修改，不如直接规定“一次写入，多次读取”。

后来 Doug Cutting 受这篇论文启发，设计出了 HDFS。可以说，HDFS 不是凭空出现的技术，而是 GFS 思想在开源世界中的最成功实践。

这一点让我很有感触：很多看似“革命性”的系统，其实不是发明了全新的理论，而是重新定义了问题边界。

二、分布式文件系统到底解决了什么问题？

一句话概括：

分布式文件系统就是把多台机器的磁盘，在逻辑上伪装成一块超级硬盘。

这个定义听起来简单，但真正难的是：

• 文件到底存在哪些机器上？

• 某台机器坏了怎么办？

• 如何保证用户感觉不到这些复杂性？

• 上千台机器如何协同工作？

以前我总以为“分布式存储”的重点在于“分布”，现在才发现真正难的是“系统一致地管理这些分布”。数据散着存不难，难的是散着存还能像一个整体一样工作。

三、HDFS 的核心思想：承认现实，而不是对抗现实

1. 文件分块（Block）

HDFS 将大文件切分成固定大小的数据块，默认是128MB。

这个设计初看似乎平平无奇，但意义非常大。

如果有一个 1TB 文件，不可能要求某一台机器必须有 1TB 可用空间。切块之后，不同块可以分布到不同节点上。这样：

• 文件大小不再受单机限制；

• 多个节点可以并行处理；

• 故障恢复也更容易。

我觉得这里最妙的地方在于：系统不再以“文件”为基本单位，而是以“块”为基本单位。

2. 副本机制（Replication）

默认每个块保存3 个副本。

这个数字看起来很随意，但其实是性能和可靠性的经典折中。

• 1 个副本：节省空间，但毫无容错；

• 2 个副本：可以容忍一次故障；

• 3 个副本：可靠性大幅提升，同时空间成本仍可接受。

这种设计体现了一种非常务实的工程思路：

硬件一定会坏，所以不要想着避免故障，而是让系统天然能够容忍故障。

3. 一次写入，多次读取

HDFS 的文件模型非常“粗暴”：

• 文件写好以后基本不修改；

• 可以不断读取；

• 只允许追加，不支持随机修改。

刚开始我觉得这限制很大，但后来意识到，这其实是针对日志、网页抓取、监控数据等典型大数据场景做出的精准取舍。

很多系统设计的精髓就在于：

放弃那些不必要的通用性，换取极致的性能。

4. 移动计算，而不是移动数据

传统思路是：

把数据传到程序所在机器。

Hadoop 的思路是：

把程序调度到数据所在机器。

这就是经典的Move Computation, Not Data。

说白了：

如果山不过来，那就让人过去。

四、HDFS 的优点与“祖传缺陷”

优点：为大规模批处理而生

HDFS 的几个关键词：

• 高吞吐量

• 高容错

• 高扩展性

• 低成本

• 高可靠性

这些特性决定了它特别适合：

• 日志分析

• 离线 ETL

• 搜索引擎索引构建

• 海量数据归档

缺点：不是万能存储

HDFS 的局限也非常明确：

• 不适合低延迟访问；

• 不适合海量小文件；

• 不支持随机修改；

• 不支持并发写入。

这一节给我的启发很深：

任何系统的优势，本质上都是某种限制的另一种表达。

五、HDFS 架构：一个“指挥官”和一群“搬运工”

HDFS 的核心组件可以概括为：

• NameNode

• DataNode

• Client

• Secondary NameNode

1. NameNode：大脑

NameNode 保存所有元数据：

• 文件目录结构

• 权限信息

• 文件到数据块的映射

• 数据块到 DataNode 的映射

一句话：

NameNode 负责知道“东西在哪”，但不亲自搬东西。

2. DataNode：真正干活的人

DataNode 存储实际数据块，并响应客户端读写请求。

如果把 HDFS 比作物流系统：

• NameNode 是调度中心；

• DataNode 是仓库；

• Client 是用户；

• Secondary NameNode 是定期做备份的档案管理员。

3. Client：中介

客户端先向 NameNode 查询数据位置，再直接和 DataNode 通信。

这意味着 NameNode 不参与实际数据传输，从而避免成为网络瓶颈。

4. Secondary NameNode：最容易被误解的角色

名字里带着 “Secondary”，很容易让人以为它是备用 NameNode。

但实际上：

它不是热备，也不能接管服务，只负责定期合并 FsImage 和 EditLog。

这几乎是 Hadoop 初学者必踩的坑。

六、FsImage 与 EditLog：元数据的“快照 + 日志”模式

NameNode 的元数据管理采用两份核心文件：

• FsImage：完整快照

• EditLog：增量日志

这种设计和数据库中的：

• 数据文件 + WAL（Write-Ahead Log）

几乎是一个思路。

这个地方让我再次感受到：不同系统表面形式不同，但底层思想高度相通。

七、心跳机制：集群里的“报平安”

每个 DataNode 默认每 3 秒向 NameNode 发送一次心跳，每 6 小时发送一次完整块报告。

如果 NameNode 长时间收不到心跳，就会认为该节点已经挂掉，然后触发副本重建。

这个机制本质上非常朴素：

“你还活着吗？”
“我还活着。”
“好的，继续干活。”

八、高可用（HA）：从“能恢复”到“几乎不停机”

Hadoop 2.x 开始支持 NameNode HA，通过：

• Active NameNode

• Standby NameNode

• JournalNode

• ZooKeeper

实现自动故障切换。

这一节让我真正理解了“高可用”和“容错”的区别：

• 容错：出了问题还能恢复；

• 高可用：最好让用户根本感觉不到问题。

九、纠删码（Erasure Coding）：用数学换空间

Hadoop 3.x 引入了纠删码机制。

相比传统三副本：

• 三副本：占 3 倍空间；

• RS-6-3 等方案：约占 1.5 倍空间。

这部分让我再次感受到理论与工程结合的魅力：抽象代数里的编码理论，最终变成了工业级存储系统的核心技术。

某种意义上，这就是计算机科学最迷人的地方——数学公式最后真的能帮公司省下几千万的硬盘钱。

十、我的整体理解：HDFS 是一种“工程哲学”

读完这一章后，我最大的感受不是记住了多少命令，而是理解了 HDFS 背后的系统设计哲学：

1. 默认硬件会坏；

2. 接受限制，而不是追求万能；

3. 通过分块实现规模扩展；

4. 通过副本实现容错；

5. 通过移动计算降低网络成本；

6. 用日志和快照保证恢复能力。

这些原则几乎贯穿了整个大数据生态，甚至很多现代分布式系统。

十一、一些个人感想

刚开始接触 HDFS 时，我觉得它的很多设计很“反直觉”：

• 为什么不支持随机修改？

• 为什么 NameNode 只存元数据？

• 为什么一个文件要切成这么大的块？

但越往后看，越发现这些设计都不是缺陷，而是经过大量实践后的主动取舍。

这让我想起一句很经典的话：

Architecture is about trade-offs.

系统架构从来不是“把所有功能都加上”，而是“明确知道什么必须支持，什么可以放弃”。

HDFS 的成功，某种程度上就是因为它足够专注：它不试图成为万能文件系统，而是坚定地服务于海量数据的批处理场景。

十二、总结

如果用一句话概括 HDFS：

HDFS 是一个建立在廉价硬件之上，通过“分块 + 副本 + 主从架构 + 故障容忍”实现海量数据可靠存储的分布式文件系统。

如果再更直白一点：

它的核心思想就是：机器会坏，数据不能丢；网络很贵，程序过去；功能可以少，但规模必须大。

这一章读下来，不只是理解了 HDFS 的工作机制，更重要的是第一次真正体会到分布式系统设计中的那种“接受现实、拥抱故障”的工程智慧。

说得稍微中二一点：

单机系统相信机器不会出错，分布式系统则默认世界本就充满故障。
而 HDFS 的伟大之处，在于它把这种悲观主义，变成了一种稳定可靠的生产力。