在上一篇文章中，我们绘制了大数据生态的全景图，而 Hadoop 正是支撑起这个生态的基石。本文将深入剖析 Hadoop 的核心组件之一 ——HDFS（Hadoop Distributed File System），从设计思想、核心原理到实战操作，带你真正理解大数据存储的底层逻辑。
一、Hadoop 与 HDFS：大数据时代的存储基石
1. Hadoop 的诞生背景
2003 年，Google 发表了《Google File System》（GFS）论文，提出了一种在廉价商用硬件上构建大规模分布式文件系统的思路。2006 年，Apache 软件基金会基于这一思想，孵化出了 Hadoop 项目，而 HDFS 正是对 GFS 的开源实现。 Hadoop 的设计哲学是：'移动计算比移动数据更划算'。它将数据分散存储在大量廉价服务器上，然后将计算任务分发到数据所在的节点执行，从而极大地提升了处理效率。
2. HDFS 的核心设计目标
- 高容错性：通过数据冗余备份，在硬件故障时保证数据不丢失。
- 高吞吐量：优化了大文件的顺序读写，适合批量数据处理。
- 可扩展性：可以线性扩展到数千个节点，存储 PB 级数据。
- 简化一致性模型：采用'一次写入，多次读取'的模型，简化了设计。
二、HDFS 核心原理：从架构到数据读写
1. 主从架构（Master/Slave）
HDFS 采用经典的主从架构，主要由以下几个角色组成：
- NameNode（主节点）：
- 管理文件系统的命名空间（Namespace），维护文件目录树、文件和块的元数据。
- 不存储实际数据，只存储元数据（如文件块 ID、所在 DataNode 地址等）。
- 是整个集群的单点，因此需要配置高可用（HA）方案。
- DataNode（从节点）：
- 负责存储实际的数据块（Block）。
- 定期向 NameNode 发送心跳（Heartbeat）和块报告（Blockreport），汇报自身状态和存储的数据块信息。
- SecondaryNameNode：
- 并非 NameNode 的热备，而是负责定期合并 NameNode 的编辑日志（Edits）和镜像文件（FsImage），以减轻 NameNode 的压力。
2. 数据块（Block）的概念
HDFS 将大文件分割成固定大小的数据块进行存储，默认块大小为 128MB（Hadoop 2.x 之后）。
- 为什么这么大？：减少寻址开销，最大化磁盘顺序读写的吞吐量。
- 冗余备份：每个数据块默认有 3 个副本，分别存储在不同的 DataNode 上，保证数据可靠性。
3. 数据写入流程
- 客户端向 NameNode 发起文件写入请求。
- NameNode 检查权限和空间，分配数据块和 DataNode 列表。
- 客户端将文件分割成数据包（Packet），按顺序写入由多个 DataNode 组成的流水线（Pipeline）。
- DataNode 之间相互复制数据包，完成副本备份。
- 所有副本写入成功后，客户端通知 NameNode，文件写入完成。
4. 数据读取流程
- 客户端向 NameNode 查询文件块的位置信息。
- NameNode 返回每个数据块所在的 DataNode 列表。
- 客户端选择距离最近的 DataNode，并行读取各个数据块。
- 客户端将读取到的数据块按顺序拼接，还原成完整文件。
三、HDFS 实战：常用命令与操作
下面我们通过几个常用命令，来体验 HDFS 的基本操作。
1. 环境准备
假设你已经搭建好了 Hadoop 集群，并且 HDFS 服务已启动。
