Colossus：元数据塞进 Bigtable 之后，单个文件系统做到 10 EB、读 50 TB/s

Colossus 是什么

Colossus 是 Google 的集群级文件系统，也是 Google File System（GFS）的继任者。它支撑 Google Cloud 的存储服务（Cloud Storage、Firestore），同时也是 YouTube、Drive、Gmail 这些自有产品底下的存储层。

Google 的所有存储服务建立在三块基石上：

• Colossus：集群级文件系统，GFS 的后继
• Spanner：全球一致的可扩展关系数据库
• Borg：可扩展作业调度器，Kubernetes 的重要前身

一次存储访问拆开来看是这样的：Borg 供给资源，Spanner 存访问权限和数据位置元数据，Colossus 负责管理并存储数据本身。

它和对象存储的差别在架构层面：Colossus 把 GFS 的编程模型简化成了 append-only 存储系统，对外保留文件系统的编程接口，同时具备对象存储级的规模与管理能力。下面涉及的元数据子系统、数据放置与缓存，都是文件系统侧的设计。

三份原始材料：

• A peek behind Colossus, Google's file system（Google Cloud Blog，2021-04-19，Dean Hildebrand / Denis Serenyi）
• How Colossus optimizes data placement for performance（Google Cloud Blog，2025-03-26，Larry Greenfield）
• Cluster-Level Storage @ Google（Denis Serenyi，PDSW-DISCS 2017 keynote）

GFS 为什么不够

GFS 的 master 是单台机器，问题很直接：一台机器不够大，所有元数据操作都要过这一个瓶颈，系统容错但谈不上高可用，性能也没有延迟保证。GFSv2 / Colossus 的目标写在纸面上就是三件事：更大、更快、尾延迟更可预测。GFS master 被 Colossus 取代，GFS chunkserver 被 D 取代。

最初的 Colossus 定位是「为 Bigtable 做一个更简单的文件系统」：append-only、单写多读、没有 snapshot 和 rename、不需要目录。

元数据往哪放，当时摆在桌面上的选项有四个：

• GFS：缺数据库特性
• 分片 MySQL：负载均衡差、复杂
• 本地 KV 存储：不扩展
• Bigtable：可自动分片、语义易用、点查与扫描效率高

最终选了 Bigtable。文件系统元数据放在 Bigtable 的一个内存 locality group 里，CFS 的 curators 直接跑在 Bigtable tablet servers 上，Bigtable 的一行对应一个文件，stripes 则是复制组，分为 open / closed / finalized 三种状态。单个文件的记录长这样：

/cfs/ex-d/home/denis/myfile
  is-finalized? / mtime / ctime / encoding r=3.2

用 Colossus 存元数据时，元数据量大约只有数据量的 1/10000，因此可以递归分层，最终落到 Chubby 上。

这个改动的收益是规模：把文件元数据放进 Bigtable 之后，Colossus 相比最大的 GFS 集群规模提升超过 100 倍。当初做 Colossus 的动机，就是解决 GFS 在承载 Search 相关元数据时遇到的扩展瓶颈。

五个组件

Client library：应用/服务与 Colossus 交互的入口，也是整个文件系统里最复杂的部分。客户端集成了 software RAID 等功能，应用可以用多种编码（encodings）来权衡性能与成本。

Colossus Control Plane：核心是可扩展的元数据服务，由许多 Curators 组成。客户端直接与 curators 做控制操作，比如创建文件，这一层可以水平扩展。

Metadata database：Curators 把文件系统元数据存在 Google 的高性能 NoSQL 数据库 BigTable 里。

D File Servers：数据直接在客户端与「D」file servers（网络附加磁盘）之间流动，减少网络跳数。

Custodians：后台存储管理器，负责数据持久性与可用性、整体效率，承担磁盘空间均衡、RAID 重建等任务。

数据路径和控制路径是分开的：客户端先与 curators 交互拿元数据，再直接把数据写到挂着 HDD 或 SSD 的 D servers 上。

规模数字

单个 Colossus 集群可以扩展到 EB 级存储、数万台机器。示例里 Compute Engine VM、YouTube 服务节点、Ads MapReduce 节点共享同一套底层文件系统，这种资源解耦（disaggregation）提升利用率、压低成本：先给低延迟工作负载（比如 YouTube 视频）预留峰值，再让批处理分析负载填满空闲时段。

Colossus 是 zonal 产品：每个 cluster 一个 Colossus 文件系统，它是 Google Cloud zone 的内部组件；多数数据中心是一个 cluster、一个 Colossus 文件系统。许多 Colossus 文件系统承载多个 EB 存储，其中两个超过 10 EB。部分最大文件系统的读吞吐经常超过 50 TB/s、写吞吐超过 25 TB/s，按博客里的说法，足以每秒发送 100 多部完整 8K 电影。最繁忙的单个 cluster 提供超过 600M IOPS（读写合计）。

2017 年 PDSW 演讲里的典型集群还是另一个量级：数万台机器、PB 级分布式 HDD、可选多 TB 本地 SSD、10 GB/s bisection 带宽。

I/O 特征差异很大：

公开产品中的几处用法：Hyperdisk ML 用 Colossus SSD 支撑 2500 节点、1.2 TB/s 读取；Spanner 用 Colossus 在同一个文件系统里同时提供廉价 HDD 与极快 SSD，这是分层存储特性的基础；Cloud Storage 用 Colossus SSD 缓存提供低成本的同时支撑 AI/ML 密集 I/O；BigQuery 基于 Colossus 的存储为超大查询提供极快 I/O。

成本这件事，看的不是磁盘单价。存储 TCO 关注的是数据持久性、可用性和服务成本，把磁盘保持「满且忙」才能最小化 TCO。Colossus 把新写数据均匀分布到所有盘上，再把老的冷数据再平衡到更大容量的盘。

SSD 放置与 L4

为了拿到高吞吐，数据得放对位置。Colossus 有 SSD 缓存与 SSD 数据放置两项创新，由名为 L4 的系统驱动。SSD 放置有三种方式：

# 强制放 SSD：最简单、最贵，文件完全存 SSD
/cns/ex/home/leg/partition=ssd/myfile

# 混合放置 hybrid placement：只把一份副本放 SSD，更便宜
/cns/ex/home/leg/partition=ssd.1/myfile

混合放置的代价是：SSD 副本所在的 D server 不可用时，会退化到 HDD 延迟。Google 内部大部分数据用的是第三种——L4 分布式 SSD 缓存，由它动态选择最适合放进 SSD 的数据。

L4 读缓存的工作方式：L4 索引服务器维护分布式读缓存；读数据时先咨询 L4 索引服务器，命中就从 SSD 读，未命中（cache miss）则从 Colossus 放置数据的 HDD 读取；miss 时 L4 可以决定把访问的数据插入 SSD 缓存（通知 SSD 存储服务器从 HDD 服务器搬运数据），缓存满时淘汰。策略由机器学习算法按工作负载决定，可选写入即插入、首次读后插入、或短时间内第二次读后才插入三种。相关论文是 CacheSack。这套机制对反复读同一数据的应用效果很好，能大幅提升 IOPS 与吞吐，但弱点是新数据仍然写入 HDD。

对「写入-读取-快速删除」的数据，比如大批处理任务的中间结果，以及数据库事务日志这类大量小 append 的文件，更合适的做法是直接写 SSD、完全跳过 HDD，这就是 L4 writeback 的来源。

对使用者的启示

Colossus 抽象掉了硬件复杂性：数据中心里有各种规格的磁盘与闪存，应用对持久性、可用性、延迟的需求又各不相同。Colossus 提供多档 service tier，应用只要指定 I/O、可用性、持久性需求，就能把字节和 I/O 当作抽象的、无差别的单元来申请资源。

在 Google 的规模下硬件一直在故障——不是因为硬件不可靠，而是数量太多，故障属于常态，文件系统必须容错并透明恢复：绕开故障做 I/O，后台快速恢复。

存储效率的核心手段是按数据访问模式与频率区分冷热，混合使用闪存与磁盘。元数据扩展带来的资源解耦，则让同一个集群里可以混用不同大小的磁盘、承载性质完全不同的工作负载。