分布式文件系统与对象存储：HDFS/GFS架构

可视化演示

展示HDFS写入流水线中副本在DataNode间的传递、副本放置与容错机制，以及纠删码相较3副本的存储开销优化，可切换三种模式观察。

总索引册与大楼

社区图书馆决定不再把书一本本完整存放在单间库房，而是建一栋巨大的“数据大楼”。大楼里有成千上万个房间（DataNode），每个房间专门存放标准大小的“分册”——比如 128MB 一章。馆长办公室里摆着一本总索引册（NameNode），上面记录了：哪些书被拆成了哪些分册、每个分册存放在哪个房间的哪个架子上、读者当前正在借走哪些分册。这套设计，就是 HDFS 的宏观骨架。

在技术世界里，“总索引册”叫 NameNode（名字节点），“数据大楼的房间”叫 DataNode（数据节点）。NameNode 只负责管理元数据——即“文件叫什么、分成几块、每块在哪”这类信息，不存真实数据。DataNode 则真正保管数据内容。为了让管理更简单，文件被拆成固定大小的 块（Block），默认 128MB，每个块独立存储、独立复制。

这个“拆书分册”的设计带来了三个好处：第一，单本书可以超过单个房间的容量（单个文件可以大于单台磁盘）；第二，每个分册可以复制多份放在不同房间，防止火灾/磁盘损坏造成数据丢失；第三，读者可以直接从离自己最近的房间读取某个分册，实现负载均衡。当然也有代价——总索引册一旦丢失，整栋大楼就“失明”了，这引出了后面要讲的 HA（高可用）方案。

回到图书馆的比喻：总索引册虽然不占太多空间，但它必须放在最安全的保险柜里，并且时刻保持更新。任何一个分册的房间出了问题，索引册都能立刻发现并安排重新抄录一份。这就是 NameNode 与 DataNode 各司其职的精髓——元数据集中、数据分散。

写入流水线

现在，一位读者（客户端）想把一本新书存入图书馆。流程是什么样的？他不能自己抱着一堆分册随便找个房间塞进去——他必须先到馆长办公室（NameNode）申请一个“图书编号”（写入许可）。馆长翻开总索引册，找到一个有空间的房间列表，告诉读者：“你可以把这些分册依次放到 1 号房、3 号房、5 号房。”更聪明的是，馆长还会指定“管线顺序”：先放入 1 号房，再由 1 号房直接转发给 3 号房，3 号房再转发给 5 号房，像接力赛一样，而不是让读者来回跑三趟。

在 HDFS 中，这个“接力赛”就叫 写入流水线（Pipeline）。客户端将数据切分成一个个 数据包（Packet，默认 64KB），沿管线依次发送。第一个 DataNode 收到一个包后，一边落盘一边转发给下一个 DataNode，同时最后一个节点会向上游逐级发送确认（ACK）。整个过程像消防员传递水桶救火——每一级只做“接、传、确认”三件事，效率极高。

这样做最大的好处是减少了客户端与各个 DataNode 之间的网络传输次数。如果让客户端分别给三个副本节点各传一遍，就要消耗三倍的客户端带宽；而流水线方式下，客户端只需传一份数据，由节点间内部转发完成复制。Google 的 GFS 论文中详细描述了这一设计，HDFS 沿用了同样的思想。

图书馆馆长不需要亲自帮读者搬书，读者只需把书交给第一个房间的管理员，后面的房间之间会自动接力。这套流水线设计让“写一本 1TB 的大书”变得像“串一串糖葫芦”一样顺畅——一颗一颗串，串完一整串。而在 AI 时代，训练数据动辄 TB 级，流水线写入的高效性直接决定了数据集准备的速度。

副本放置策略

图书馆馆长有一个重要的“排书原则”：同一本书的分册副本，不能放在同一栋楼里（否则火灾就全没了），也不能放在治安太差的街区。在分布式系统中，这个“街区”就是 机架（Rack）。一个机架上的多台服务器共享一个网络交换机和电源，如果机架断电或交换机故障，整批机器都会“失联”。

HDFS 默认的副本放置策略是 机架感知（Rack Awareness）：第一个副本放在客户端所在机架的一个 DataNode 上（写入最快）；第二个副本放在同机架的另一个 DataNode 上（满足机架内冗余，且流量可控）；第三个副本放在不同机架的某个 DataNode 上（防止整个机架失效）。这就像图书馆把一本书的三个副本分别放在“本栋楼一层”“本栋楼二层”和“隔壁栋楼”——既兼顾了写入效率，又最大化了容灾能力。

这个策略是“效率”与“安全”的折中。如果三个副本都放同一机架，虽然机架内带宽高、写入快，但一个机架断电就全丢；如果三个副本放三个不同机架，安全但跨机架网络流量巨大。Google 的 GFS 论文和 Hadoop 官方文档都强调“机架感知”是分布式存储的基石——它要求管理员配置网络拓扑，让系统“知道”每台服务器在哪个机架。

回到图书馆：馆长把副本放得“既不太近也不太远”。太近，一起遭殃；太远，调书太慢。这个朴素的“三副本折中”至今仍是分布式存储领域最经典可靠的设计之一——虽然它浪费了 200% 的空间，但换来了“随便挂掉一台机器都不丢数据”的确定性保障。对 AI 训练来说，几 TB 的模型参数和数据集，可靠性远比空间成本更重要。

心跳机制与故障

图书馆的每个房间管理员每隔几分钟就会到馆长办公室报到一次：“我还在，书都完好。”如果有管理员连续很久不来报到，馆长就会在索引册上标记该房间“失联”，并安排其他房间重新抄录这些分册的副本。这就是 心跳机制（Heartbeat）——是分布式系统感知“谁还活着”的眼睛。

在 HDFS 中，每个 DataNode 默认每 3 秒 向 NameNode 发送一次心跳，携带自己的存储容量、剩余空间、当前块数量等信息。NameNode 如果连续 10 分钟 没有收到某个 DataNode 的心跳，就判定该节点死亡，然后把该节点上所有块的副本标记为“副本数不足”，并调度其他节点重新复制。这个“3 秒报到、10 分钟判死”的参数设计很讲究：太短会误判（网络抖动）；太长会导致系统对故障反应迟钝。

心跳不只是“我活着”的信号，它还是 控制指令的下行通道。NameNode 会在心跳响应中携带命令：如“把某块复制到某节点”“删除某块”“关停某个节点进入维护模式”。这就像馆长在管理员报到时顺便递上一张纸条：“今天去 3 号房抄一本书。”这种“上行状态 + 下行指令”的双向通信模式是所有分布式系统（包括 K8s、ZooKeeper）的通用设计。

图书馆馆长不需要亲自巡查每个房间，管理员的自发报到让“这件事”变得极其轻量。同样，HDFS 的心跳机制让 NameNode 不必主动轮询所有节点，而是被动接收状态——这对上万个节点的集群来说，是唯一可行的规模化解法。如果你在面试中被问“NameNode 怎么知道 DataNode 挂了”，答案就是心跳超时。

小文件问题

图书馆的“总索引册”有个尴尬的短板：它的纸张是有限的，每一条“某书某章在某房间”的记录都要占一行。如果一个读者存了 1000 本只有 1 页的小册子，索引册就要记 1000 行；但如果他存 10 本很厚的书（每本 100 分册），索引册只需 1000 行记录。索引册的内存空间，取决于文件数量，而不是数据总量。HDFS 里这条规则同样成立——NameNode 的元数据条目与文件/块数量成正比，而与存储的数据量关系不大。

一个小文件（比如 1KB）在 HDFS 中也要占用一个独立的 Block，产生一条元数据记录。每条元数据记录在 NameNode 内存中大约占用 150 字节。1000 万个 1KB 的小文件意味着 1000 万个块，元数据就占了 1.5GB 内存——而它实际存储的数据只有 10GB。相比之下，1000 万个 128MB 的块（即约 1.2PB 数据）的元数据也只有 1.5GB。这就是 小文件问题（Small Files Problem）：文件数量才是 NameNode 内存的杀手，而不是数据量。

解决方案也很直接：把许多小文件“打包”成一个大文件——比如使用 HAR（Hadoop Archive）、SequenceFile，或者数据湖方案中的 Hudi/Iceberg，它们本质都是“把小册子合订成一本厚书”，减少索引册的记录条数。在 AI 场景中，海量小图片、小文本片段常常作为训练数据，通常会先用 TFRecord 或 Parquet 格式做 合并（Coalescing），这正是对 HDFS 小文件问题的经典规避。

图书馆馆长最怕的不是书太多，而是“书太碎”。所以优秀的图书管理员会把零散的小册子定期合订成合集，贴上醒目标签。HDFS 用户也养成了同样的习惯：宁可写大文件，也不要写海量小文件。对 AI 工程师而言，理解这一点能避免“数据明明不多，集群却 OOM”的诡异问题。

纠删码演进

三副本方案虽然简单可靠，但它太“奢侈”了——存 1TB 数据实际要占 3TB 空间。图书馆馆长会想：“有没有一种办法，既不用存三份，又能在任一分册丢失时把它恢复出来？”答案是数学：纠删码（Erasure Coding, EC）。它把数据切成若干数据块，再计算出若干校验块。任何一块丢了，都可以用剩下的块（数据块+校验块）通过数学运算恢复出来。

纠删码最经典的是 Reed-Solomon（RS）编码，常用配置是 RS(6,3)：把数据切成 6 个数据块，计算 3 个校验块，总共 9 块，任意丢失 3 块都能恢复。对比三副本：同样存储 6 个数据块，三副本需要 18 块空间；而 EC 只需 9 块，节省了 50% 的存储空间。代价是什么呢？如果一块丢失，重建时需要读取至少 6 块（副本重建只需读 1 块），网络 IO 和 CPU 开销显著增加。

HDFS 在 3.0 版本中正式引入了 EC 支持（此前主要靠 Apache Ozone/Kudu 等外部系统实现）。工程上的权衡是：冷数据（不常访问）用 EC 省空间，热数据（频繁读写）用副本保性能。这就像图书馆对“新书畅销书”买多本放各层，对“十年没人借的古籍”只存一份原稿+电子扫描即可——访问频率决定冗余策略。GFS 论文中的设计虽然没有完整实现 EC，但后续的 Colossus（GFS 的下一代）已经将纠删码作为核心存储手段。

纠删码是分布式存储从“蛮力冗余”走向“数学冗余”的关键一步。今天的云存储厂商（AWS S3、Azure Blob、阿里云 OSS）几乎全部使用 EC 来降低成本——这也是“对象存储”与 HDFS 在底层架构上的核心差异之一。对 AI 工程师来说，理解 EC 能帮你回答“为什么同样是存 100TB 数据，S3 比自建 HDFS 便宜这么多”。

AI 应用场景

Python 演示

import hashlibimport randomimport time  class DataNode:    def __init__(self, node_id, rack):        self.node_id = node_id        self.rack = rack        self.blocks = {}        self.alive = True        self.last_heartbeat = time.time()     def heartbeat(self):        self.last_heartbeat = time.time()     def store_block(self, block_id, data):        self.blocks[block_id] = data     def is_dead(self, timeout=10):        return time.time() - self.last_heartbeat > timeout  class NameNode:    def __init__(self, replication=3):        self.datanodes = []        self.file_table = {}        self.replication = replication     def register_datanode(self, datanode):        self.datanodes.append(datanode)     def choose_datanodes(self, rack):        same_rack = [dn for dn in self.datanodes if dn.rack == rack]        other_rack = [dn for dn in self.datanodes if dn.rack != rack]        chosen = []        if same_rack:            chosen.append(random.choice(same_rack))        if len(chosen) < self.replication and same_rack:            chosen.append(random.choice(same_rack))        while len(chosen) < self.replication:            chosen.append(random.choice(other_rack))        return chosen[:self.replication]     def write_file(self, path, data):        block_size = 64        blocks = [data[i:i + block_size] for i in range(0, len(data), block_size)]        locations = []        for idx, block in enumerate(block_id_assign()):            if len(locations) == 0:                continue        block_ids = [hashlib.md5(f"{path}-{i}".encode()).hexdigest()[:8] for i in range(len(blocks))]        for bid, block in zip(block_ids, blocks):            client_rack = random.choice(list(set(dn.rack for dn in self.datanodes)))            targets = self.choose_datanodes(client_rack)            for dn in targets:                dn.store_block(bid, block)            locations.append((bid, [dn.node_id for dn in targets]))        self.file_table[path] = locations        return locations     def check_health(self):        dead = []        for dn in self.datanodes:            if dn.is_dead():                dead.append(dn.node_id)        return dead  def block_id_assign():    yield hashlib.md5(b"fake").hexdigest()[:8]  def main():    nn = NameNode(replication=3)    racks = ["rack-a", "rack-a", "rack-b", "rack-b"]    for i in range(4):        dn = DataNode(node_id=f"dn-{i}", rack=racks[i])        nn.register_datanode(dn)     data = b"hello hdfs! " * 40    locations = nn.write_file("/user/ai/data.bin", data)    print("=== 文件块分布 ===")    for block_id, nodes in locations:        print(f"block {block_id} -> {', '.join(nodes)}")     print("=== 心跳检查 ===")    time.sleep(1)    for dn in nn.datanodes:        dn.heartbeat()    print(f"存活节点数: {len(nn.datanodes) - len(nn.check_health())}")  if __name__ == "__main__":    main()

1. block_size = 64设定块大小（实际 HDFS 为 128MB），演示文件被切分。
2. def choose_datanodes(self, rack)实现机架感知策略：优先同机架、再跨机架。
3. dn.store_block(bid, block)将块数据写入 DataNode 的 blocks 字典，模拟磁盘存储。
4. def check_health(self)遍历所有 DataNode，判定心跳超时的节点并返回。
5. nn.write_file("/user/ai/data.bin", data)模拟客户端通过 NameNode 完成一次文件写入。

常见误区

面试题