Google 在 2003~2006 年连续公开了三篇经典论文：GFS、MapReduce、Bigtable。
它们不是孤立系统，而是一套相互配合的“数据工厂”：
GFS负责把海量数据稳定存下来。MapReduce负责把大任务拆开并行算完。Bigtable负责把结构化/半结构化数据按键高效读写。
这三者几乎定义了后续 Hadoop 生态（HDFS、MapReduce、HBase）和云原生数据平台的基础形态。
一图看懂三者关系
GFS：为“廉价机器 + 大文件 + 高故障率”设计的文件系统
解决了什么问题？
传统文件系统假设硬件可靠、文件较小、写操作随机且频繁。Google 的现实恰好相反：
- 文件极大（日志、网页快照、索引数据）。
- 顺序追加远多于随机改写。
- 节点经常坏，故障是常态而不是异常。
GFS 的核心思路：接受故障，拥抱追加，靠副本保可用。
核心设计
- Master + ChunkServer：Master 只管元数据；ChunkServer 管真实数据块。
- 大块（Chunk）：默认
64MB，减少元数据规模和客户端寻址次数。 - 多副本：通常
3副本，跨机器/机架放置。 - Lease 主副本机制：Primary 负责给写入排序，避免并发写冲突。
- Record Append：提供“原子追加”语义，适合日志流。
写入路径（简化）
MapReduce：把“写复杂分布式程序”变成“写 map/reduce 函数”
编程模型
你只需要定义两个函数：
map(k1, v1) -> list(k2, v2)reduce(k2, list(v2)) -> list(v3)
系统自动完成：任务切分、调度、失败重试、数据重分布（Shuffle）、结果落盘。
执行流程
为什么它改变了行业？
- 大幅降低分布式门槛：业务侧只写函数，不再手搓容错框架。
- 天然弹性：慢节点、坏节点通过重试和推测执行被吸收。
- 吞吐优先：适合离线批处理（索引构建、日志统计、特征生成）。
Bigtable：建立在 GFS 之上的分布式稀疏多维有序映射
数据模型（直观理解）
Bigtable 可以看成：
$$ (row\ key,\ column\ family:qualifier,\ timestamp) \rightarrow value $$
特点：
- 按
row key字典序存储，天然支持范围扫描。 - 列是动态的，空值不占空间（稀疏）。
- 单行事务语义强，跨行事务弱（换取横向扩展）。
架构角色
- Client Library：定位 tablet 并发起读写。
- Master：分配 tablet、负载均衡、故障恢复。
- Tablet Server：服务具体 tablet 的读写。
- Chubby：分布式锁/命名服务（协调组件）。
- GFS：持久化底层存储。
三者如何协作（工程视角）
一个典型闭环：
- 业务日志实时写入
GFS。 - 每小时跑一轮
MapReduce做清洗与聚合。 - 结果回写
Bigtable，支撑在线查询和推荐特征读取。
这就是“离线计算 + 在线服务”的经典分层。
与今天技术栈的映射
GFS对应：HDFS、S3/OSS + 元数据层。MapReduce对应：Spark、Flink Batch、Hive批处理。Bigtable对应：HBase、Cassandra、Cloud Bigtable。
虽然具体实现迭代很多代，但底层思想仍然没变：
- 存储和计算解耦。
- 数据局部性优先。
- 用简单编程模型换规模化工程能力。
- 以故障常态为前提设计系统。
Hadoop / Spark 对应的设计（落地版）
上面讲的是 Google 原始论文体系；在开源世界里，最经典的两条实现路线是 Hadoop 和 Spark。
Hadoop：把 Google 三件套“开源复刻 + 工程化”
大致对应关系：
GFS→HDFS：NameNode + DataNode，块存储 + 多副本。MapReduce→Hadoop MapReduce：Job/Task + Shuffle + 容错重试。Bigtable→HBase：RegionServer + HFile，按 row key 有序存储。
再加上 YARN 负责统一资源调度（CPU/内存队列），就形成完整平台。
Hadoop 的设计倾向：
- 磁盘友好：中间结果大量落盘，稳定但链路更重。
- 离线吞吐优先：适合 TB~PB 级批处理。
- 组件边界清晰：存储、计算、资源调度、NoSQL 分层明显。
Spark：在同样分布式目标下，换成“内存 + DAG”执行引擎
Spark 不是替代 HDFS 的存储系统，而是替代“以 MapReduce 为中心的计算模型”。
核心对应：
MapReduce的两阶段模型 →Spark DAG多阶段流水。磁盘中间结果→RDD/DataFrame可缓存到内存。一次作业一次 pipeline→统一引擎同时支持 SQL、流处理、ML。
Spark 的设计倾向：
- 低延迟迭代计算：多轮计算（如机器学习）优势明显。
- DAG 优化：减少不必要落盘与网络搬运。
- 生态统一：
Spark SQL、Structured Streaming、MLlib共享执行框架。
Hadoop 与 Spark 的关系（不是二选一）
在多数生产环境里更常见的组合是：
- 用
HDFS/S3/OSS做统一数据湖存储。 - 用
Spark做主力计算引擎（离线 + 准实时）。 - 需要超大规模长批任务时，仍可能保留
Hadoop MapReduce。 - 在线 KV/宽表查询层仍可用
HBase/Bigtable一类系统。
一句话总结：Hadoop 更像“完整的数据操作系统”，Spark 更像“高性能通用计算引擎”；现代平台通常是二者融合而不是互斥。
总结
如果把大数据系统比作工厂：
GFS是仓储与物流系统。MapReduce是流水线加工系统。Bigtable是可快速检索的成品仓与索引系统。
它们共同回答了一个核心问题：如何在不可靠的大规模机器集群上，持续、稳定、低成本地生产数据价值。