分布式系统（E02）：GFS/HDFS 与 Bigtable/HBase 的存储架构

GFS 与 HDFS 面向大文件和顺序吞吐，Bigtable 与 HBase 面向按键查找的稀疏有序表。后两者把前者一类分布式文件系统当成持久层，却没有因此变成“文件系统加一层索引”。它们增加了 row range、写前日志、内存表、不可变文件和 Region 分配，故障恢复的单位也从块副本变成可服务的键范围。

本篇沿三条路径比较四个系统：控制面保存什么，用户数据经过哪里，节点失效后凭什么恢复。论文模型、当前产品文档与本地有限模型分别陈述。

分布式系统（E01）：CRDT、多主写入与收敛边界

共同骨架：元数据只负责找到数据

文件路径或 row key 先经过一个权威元数据视图，再落到保存字节的节点。元数据控制面决定命名、位置和归属；数据面承载大块内容。把两者拆开，才能让控制面保持较小状态，同时让客户端或服务节点直接传输大量数据。

flowchart LR
  C[客户端] --> M[元数据控制面]
  M -->|块位置或Region位置| C
  C --> D[数据节点]
  D --> P[复制文件块或写WAL/StoreFile]
  M -.不承载全部用户字节.-> P

这也给出第一个恢复边界。控制面知道 block-7 在哪些节点，不能凭这个列表重新创造 block-7 的内容；它必须找到仍然正确的副本。表系统知道 Region 的起止 key，也仍要读取持久 StoreFile，并重放尚未刷入文件的 WAL 编辑。

可迁移的模式是“元数据定位，数据证据恢复”：目录、路由表或租约告诉请求去哪里，真正恢复仍依赖副本、日志、快照或不可变文件。

GFS 与 HDFS：文件被拆成可复制的块

GFS 原论文把文件分成固定大小 chunk。master 保存命名空间、文件到chunk的映射和chunk位置，并为修改选择带租约的primary；client从master取得位置后，数据直接流向chunkserver。第03篇已经展开GFS写入次序，这里只保留架构位置。

HDFS 的相似边界是 NameNode 与 DataNode。NameNode 管理目录树、权限和文件到block的映射，DataNode保存block并周期报告。客户端创建文件时先向NameNode申请命名与目标，随后把数据写入DataNode pipeline。复制因子表达希望保留多少份，不表示任意时刻所有副本都健康，也不单独定义同步到物理介质的层次。

sequenceDiagram
  participant C as Client
  participant N as NameNode
  participant D1 as DataNode1
  participant D2 as DataNode2
  participant D3 as DataNode3
  C->>N: create /logs/a
  N-->>C: block与目标pipeline
  C->>D1: packet
  D1->>D2: packet
  D2->>D3: packet
  D3-->>D2: ack
  D2-->>D1: ack
  D1-->>C: ack

一个DataNode停止汇报后，控制面可以把它视为不可用，从剩余副本向其他节点补复制。安全性依赖至少一个正确副本仍存在、校验与元数据没有共同损坏；活性还依赖控制面可用、网络恢复和目标节点有容量。全部副本丢失时，重新分配位置不能恢复字节。

现代HDFS可配置active/standby NameNode、JournalNode和fencing，不能再用“NameNode必然是单点”概括所有部署。HA解决的是元数据服务切换；DataNode上的块复制仍是另一层故障证据。

Bigtable 与 HBase：row range 是服务和恢复单位

Bigtable把表按连续row range切成tablet。tablet server服务读写；写入先进入commit log和内存中的memtable，随后形成不可变SSTable。master负责tablet分配和负载管理，但数据内容在日志与SSTable中。

HBase沿用相似谱系，名称换成Region、RegionServer、WAL、MemStore与HFile。row key的字典序决定Region范围，因此表设计会直接影响热点：时间单调递增的前缀可能让新写集中到单个Region，增加Region数量不会自动消掉单热区。

flowchart TD
  K[row key] --> R{Region边界}
  R -->|a..m| R1[RegionServer 1]
  R -->|m..z| R2[RegionServer 2]
  R1 --> W1[WAL]
  R1 --> M1[MemStore]
  M1 --> H1[HFile]
  R2 --> W2[WAL]
  R2 --> M2[MemStore]
  M2 --> H2[HFile]

RegionServer崩溃后，协调层先确认失效并撤销旧服务资格，master再把Region分配给其他服务器。新持有者打开持久文件，并重放需要恢复的WAL编辑。这里至少有三个阶段：判定旧节点失效、选择新位置、恢复数据到可服务状态。只看到“新RegionServer已分配”还不足以回复读取。

HBase使用ZooKeeper参与活动master、RegionServer存活和关键位置协调；业务表数据不因此复制进ZooKeeper。ZooKeeper会话和watch属于控制面信号，HFile/WAL的耐久性由存储路径承担。

四个系统不能按名称一一对应

维度	GFS	HDFS	Bigtable	HBase
逻辑单位	file/chunk	file/block	table/tablet	table/Region
控制面	master	NameNode	master + 元数据层	HMaster + ZooKeeper/元数据表
主要数据节点	chunkserver	DataNode	tablet server	RegionServer
持久数据形态	chunk replica	block replica	log、memtable、SSTable	WAL、MemStore、HFile
常见恢复动作	找副本、补复制	找block、补复制	重分配tablet、读文件/重放log	重分配Region、恢复WAL/StoreFile

表中的相似项是职责类比，不是协议等价。GFS的lease与HDFS写pipeline不同；Bigtable的Chubby依赖与HBase的ZooKeeper使用也不能逐API替换。论文描述的历史系统更不能覆盖当前产品的HA、运维和版本行为。

一次节点故障要穿过两层状态

有限实验固定文件 /logs/a 的两个block，每个有三个副本。dn2失效后，每个block仍有两个副本，读取可继续；控制面随后从存活副本把 b0补到dn4、把b1补到dn1，恢复三副本。该过程没有模拟pipeline、校验和或机架策略。

表场景固定两个Region。rs1失效后，低range暂时无服务者；控制面把它交给rs3，数据恢复仍明确列出sf0和w1。模型特意拒绝“元数据有映射，所以数据已经恢复”的偷换。

stateDiagram-v2
  [*] --> Serving
  Serving --> Suspect: 心跳缺失
  Suspect --> Unassigned: 失效判定与旧资格隔离
  Unassigned --> Recovering: 新节点取得归属
  Recovering --> Serving: 打开持久文件并重放日志

安全性要求同一Region不能让两个未隔离的节点同时接受冲突写，且恢复不能漏掉已承诺记录。活性需要协调服务、master、底层文件系统和足够RegionServer最终可用。网络分区中旧节点仍运行时，fencing比“新节点已经被选中”更重要。

运行有限模型

mkdir -p examples/distributed-systems/.build/e02/tmp
export TMPDIR="$PWD/examples/distributed-systems/.build/e02/tmp"
export TMP="$TMPDIR" TEMP="$TMPDIR" PYTHONDONTWRITEBYTECODE=1
python3 -B examples/distributed-systems/storage-e02/check.py \
  --output examples/distributed-systems/.build/e02/observations.json