4.3 从 HDFS 到 Spanner：工作负载决定架构

HDFS 与 Spanner 都跨机器保存数据，但服务目标不同：前者面向大文件和高吞吐顺序访问，后者面向全球分片、同步复制和外部一致事务。不能用产品规模替代工作负载分析。

HDFS 分离元数据与数据路径

NameNode 维护命名空间、文件到 block 的映射和副本状态；DataNode 保存实际 block。客户端先查询元数据，再直接与 DataNode 传输数据。

text

Client ──metadata──> NameNode
  │
  └──block stream──> DataNode A → DataNode B → DataNode C

大 block 减少元数据数量和寻址开销，流水线复制提高写入吞吐。机架感知副本放置在网络成本与故障域之间权衡。

HDFS 适合大文件、批处理和流式读写，不适合海量小文件、低延迟随机更新和通用 POSIX 语义。具体 block 大小和副本数由部署配置决定，不应把某个默认值写成协议定律。

Active/Standby NameNode 需要共享编辑日志或一致的日志机制、故障检测与 fencing。只有“检测到 Active 不健康”还不够，必须阻止旧 Active 继续写共享资源，否则会脑裂。

DataNode 定期上报 block 状态，NameNode 根据缺副本、过量副本和故障域执行再复制。恢复流量要限速，避免节点故障触发的复制风暴影响前台作业。

Spanner 将数据按 key range 分片，每个分片的副本通过共识保持同步；事务层协调跨分片读写，TrueTime 暴露物理时间的不确定区间，以支持外部一致性和历史时间读取。

关键点不是“有 GPS/原子钟所以数据库很快”，而是：

这些保证会支付跨地域网络、共识和提交等待成本。schema 与 key 设计仍要避免热点范围。

还要明确：对象大小、请求率、范围查询、事务范围、读新鲜度、地域、RPO/RTO、成本和运维能力。

副本会同步应用误删除、错误写入和应用 bug。备份需要独立故障域、保留周期、不可变性和恢复演练。

对任何存储系统都要证明：