Google Colossus vs Facebook Tectonic：两大 EB 级分布式文件系统架构深度对比

本文深入剖析 Google Colossus 和 Facebook（Meta）Tectonic 两大 EB 级分布式文件系统的设计哲学，从架构演进、元数据管理、存储引擎、数据编码到多租户策略进行全方位对比分析。

一、背景：为什么需要新一代文件系统？

在 EB（Exabyte，百亿亿字节）级数据规模下，传统的分布式文件系统设计已经力不从心。Google 和 Facebook 分别面临着不同但本质相似的挑战：

Google 的困境：GFS（Google File System, 2003）的单 Master 架构在文件数量达到数亿级别时遭遇了严重的扩展瓶颈——所有元数据必须驻留在单机内存中，而 3 副本策略在 EB 级规模下的存储成本也难以承受。

Facebook 的困境：各业务线（照片/视频的 Blob Storage、数据分析的 HDFS 集群、AI 训练存储）各自为政，形成了”烟囱式”架构，导致严重的资源碎片化——某些集群资源紧张，另一些却大量闲置。

两家公司给出了不同但殊途同归的答案：Google 构建了 Colossus，Facebook 构建了 Tectonic。

二、Google Colossus：GFS 的继任者

2.1 架构总览

Colossus 大约从 2010 年开始服务，是 GFS 的下一代继承者，为 YouTube、Gmail、Google Cloud Storage 等所有 Google 服务提供统一的底层存储。其核心设计理念是控制平面与数据平面的彻底分离。

Colossus 由五个核心组件构成：

┌─────────────────────────────────┐
│      Application / Service      │
└──────────────┬──────────────────┘
               │
┌──────────────▼──────────────────┐
│   Client Library（客户端库）      │
│   软件 RAID / 编码策略选择        │
└──────┬───────────────┬──────────┘
       │ 控制操作        │ 数据读写
┌──────▼──────┐  ┌──────▼──────┐
│  Curators   │  │ D File      │
│ （控制平面） │  │ Servers     │
│  无状态/可   │  │（网络附加   │
│  水平扩展   │  │  磁盘）     │
└──────┬──────┘  └─────────────┘
       │
┌──────▼──────┐  ┌─────────────┐
│  BigTable   │  │ Custodians  │
│（元数据存储）│  │（后台维护） │
└─────────────┘  └─────────────┘

Client Library（客户端库）：应用与 Colossus 交互的接口。支持软件 RAID 等高级功能，客户端可根据工作负载选择不同的编码策略来平衡性能与成本。关键在于——客户端直接与 D Server 通信传输数据，绕过控制平面。

Curators（控制平面）：Colossus 的可扩展元数据服务。Curator 是无状态服务，可以水平扩展到任意数量，彻底解决了 GFS 单 Master 的瓶颈。客户端需要创建文件、查询文件位置等元数据操作时，与 Curator 通信。

Metadata Database（BigTable）：Curator 将文件系统元数据存储在高性能 NoSQL 数据库 BigTable 中。这使得 Colossus 的扩展能力比最大的 GFS 集群高出 100 倍以上。

D File Servers（数据服务器）：本质上是”网络附加磁盘”。数据直接在客户端和 D Server 之间流动，最大限度减少网络跳数。D Server 只负责数据块的存取，不参与元数据逻辑。

Custodians（后台管理器）：独立运行的后台服务，负责数据持久性维护、磁盘空间均衡、RAID 重建、垃圾回收等任务。

2.2 核心设计亮点

控制平面与数据平面分离

这是 Colossus 最核心的架构原则。元数据操作和数据传输走完全不同的路径：客户端从 Curator 获取数据位置信息后，直接与 D Server 通信进行数据读写，中间不再经过任何中心化节点。

这种设计的效果是惊人的：Colossus 最大的文件系统定期超过 50 TB/s 的读取吞吐量和 25 TB/s 的写入吞吐量，最繁忙的集群读写合计可提供超过 6 亿次 IOPS。

Reed-Solomon 纠删码：从 3x 到 1.5x

GFS 使用 3 副本策略，存储开销为 3 倍。Colossus 引入 Reed-Solomon 纠删码，将存储开销降低到约 1.5 倍。更重要的是，编码和复制由客户端驱动——客户端库根据应用需求选择编码策略：热数据可用多副本保证低延迟，冷数据用纠删码降低成本。

L4 自动化数据分层

Colossus 混合使用 SSD 和 HDD。Google 开发了名为 “L4” 的自动化数据分层系统，智能地在两种介质之间迁移数据。最频繁访问的数据放在 SSD 上实现低延迟，大部分数据保留在 HDD 上控制成本。

统一存储池

大多数 Google 数据中心只有一个 Colossus 文件系统，无论集群内运行多少工作负载。通过资源分解，低延迟工作负载（如 YouTube 视频）的峰值需求可以得到满足，同时批量分析工作负载填补空闲时间，实现更高的整体利用率。

三、Facebook Tectonic：统一的 EB 级文件系统

3.1 架构总览

Tectonic 发表于 USENIX FAST’21 会议，其核心设计理念是元数据分层解耦与原生多租户隔离。它将之前各业务线独立的存储系统统一到一个共享的文件系统中。

┌──────────────────────────────────────────┐
│  Blob Store / Data Warehouse / AI Training│
└──────────────────┬───────────────────────┘
                   │
┌──────────────────▼───────────────────────┐
│      Client Library（Per-Tenant 策略）     │
└──────┬───────────────────────┬───────────┘
       │ 元数据操作              │ 数据读写
       │                        │
┌──────▼──────────────┐  ┌─────▼──────────┐
│   Metadata Store    │  │  Chunk Store   │
│  ┌───────────────┐  │  │ （扁平化设计）  │
│  │  Name Layer   │  │  │  XFS × 36 HDD │
│  │ 目录→文件映射  │  │  │  RS 纠删码    │
│  ├───────────────┤  │  │  线性可扩展    │
│  │  File Layer   │  │  └────────────────┘
│  │ 文件→Block映射 │  │
│  ├───────────────┤  │
│  │  Block Layer  │  │
│  │ Block→Chunk映射│  │
│  └───────────────┘  │
│    (ZippyDB KV)     │
└─────────────────────┘
       │
┌──────▼──────────────────────────────────┐
│  Background: GC / Rebalancer / Repair    │
└──────────────────────────────────────────┘

3.2 三层元数据架构

Tectonic 最具创新性的设计是将元数据拆分为三个独立的层，每层存储在分布式 KV 存储（ZippyDB）中，可以独立扩展：

Name Layer（名称层）：存储目录到子目录/文件的映射关系，按目录 ID 分片。处理 ls、mkdir、rename 等目录操作。目录操作通常低频，这一层负载相对较轻。

File Layer（文件层）：存储文件对象到 Block 列表的映射，按文件 ID 分片。一个文件由一个或多个 Block 组成，处理文件的 open、stat 等操作。

Block Layer（块层）：存储 Block 到物理 Chunk 的映射，按 Block ID 分片。Block 是逻辑概念，Chunk 是实际存储在磁盘上的数据单元。这一层访问最频繁，因为每次数据读写都需要查询 Block 到 Chunk 的映射。

三层解耦的关键优势：不同层可以独立扩展。Block Layer 的访问量远大于 Name Layer，可以分配更多的分片和资源，避免了”一刀切”的扩展方式。

3.3 Chunk Store：扁平化的数据存储

Chunk Store 采用扁平化设计，对上层的 Block 和 File 完全透明。每个存储节点运行本地 XFS 文件系统，管理 36 块硬盘。Chunk Store 只关心 Chunk 的读写，不理解文件或目录的概念。

这种设计有两个关键优势：Chunk Store 可以线性扩展（只需添加存储节点）；存储层与元数据层完全解耦，可以独立演进。

Tectonic 支持 Reed-Solomon 纠删码，典型配置为 RS(9,6)（9 个数据块 + 6 个校验块），存储开销约 1.67 倍。

3.4 多租户设计

多租户是 Tectonic 最大的差异化特性：

Per-Tenant 配置：每个租户可定制缓存策略、预取逻辑、一致性模型和 I/O 调度优先级。Blob Storage 租户可能需要强一致性和高吞吐，Data Warehouse 租户更关注批量读取性能。

Traffic Shaping（流量整形）：通过 per-tenant 的速率限制和优先级队列防止”吵闹邻居”问题。某个租户请求量激增时，不会影响其他租户的服务质量。

资源共享效率：统一存储池消除了资源碎片化，不同租户的峰谷互补提高了整体资源利用率。

四、全方位对比分析

4.1 核心维度对比

维度 Google Colossus Facebook Tectonic
前身系统 GFS（2003） 多个独立 HDFS 集群 + 专用 Blob Storage
设计目标 解决 GFS 单 Master 瓶颈 统一多个专用存储系统，消除资源碎片化
存储规模 多个文件系统各达数 EB，最大超 10 EB EB 级，支撑 Facebook 全部业务
元数据架构 Curator（无状态）+ BigTable 三层分离（Name/File/Block）+ ZippyDB
元数据扩展 BigTable 自动分片，比 GFS 扩展 100x+ 三层独立分片，各层按需扩展
数据存储 D File Servers，HDD + SSD 混合 Chunk Store（扁平化），XFS × 36 HDD
数据编码 Reed-Solomon ~1.5x，客户端驱动 Reed-Solomon RS(9,6) ~1.67x
多租户 共享存储池 + Borg 调度 原生多租户，Per-Tenant 配置 + Traffic Shaping
后台服务 Custodians GC / Rebalancer / Repair
数据分层 L4 自动 HDD/SSD 调度 未公开专门机制
性能 读 50+ TB/s，写 25+ TB/s，6 亿+ IOPS 论文未公开具体吞吐数字
公开程度 无正式论文，仅官方博客和演讲 FAST’21 正式论文，细节详尽
依赖系统 BigTable / Borg / Spanner ZippyDB

4.2 写入流程对比

Colossus 写入流程：

  1. 应用通过 Client Library 发起写入请求
  2. Client 联系 Curator 获取文件元数据和 D Server 分配
  3. Client Library 根据配置对数据进行 Reed-Solomon 编码
  4. 编码后的数据块直接发送到对应的 D File Server
  5. 写入完成后，Client 通知 Curator 更新 BigTable 中的元数据

Tectonic 写入流程：

  1. 租户应用通过 Client Library 发起写入，携带租户标识
  2. Client 联系 File Layer 创建 Block，Block Layer 分配 Chunk 位置
  3. Client 直接将数据写入分配的 Chunk Store 节点
  4. Chunk Store 对数据进行 RS 编码并分布到多个节点
  5. Block 到 Chunk 的映射关系写入 Block Layer（ZippyDB）

核心差异在于：Colossus 的编码由客户端完成（客户端驱动），Tectonic 的编码在 Chunk Store 层完成（存储层驱动）。

4.3 各自的独特优势

Colossus 的独特优势：

  • 极致性能：50+ TB/s 读吞吐、6 亿 IOPS，可能是业界最强的分布式文件系统性能数据
  • 自动化数据分层：L4 系统智能调度 HDD/SSD，在成本和性能之间精细平衡
  • 深度生态整合：与 BigTable、Spanner、Borg 深度集成，是 Google 整个基础设施栈的存储基石

Tectonic 的独特优势：

  • 原生多租户：从设计之初就考虑多租户隔离，per-tenant 配置和 traffic shaping 机制成熟
  • 元数据三层解耦：Name/File/Block 三层独立扩展，比 BigTable 方案提供更细粒度的控制
  • 学术透明度：FAST’21 论文公开了完整设计细节，为业界提供了宝贵参考

五、设计启示

从这两大系统中，可以提炼出 EB 级分布式文件系统的六条核心设计原则：

1. 元数据是核心瓶颈。 两个系统都将元数据管理视为最关键的设计挑战。Colossus 用 BigTable 替代内存存储，Tectonic 用三层分离实现独立扩展。元数据的可扩展性直接决定了整个系统的上限。

2. 控制路径与数据路径必须分离。 客户端直接与存储节点通信传输数据，避免中心化节点成为数据传输瓶颈。这是 EB 级系统的必要条件。

3. 纠删码取代多副本。 在 EB 级规模下，3 副本的存储开销不可接受。Reed-Solomon 纠删码将开销从 3x 降低到 1.5x~1.67x，同时保持高数据可靠性。

4. 客户端智能化。 两个系统都将大量逻辑下沉到客户端库——Colossus 的客户端驱动编码选择，Tectonic 的 per-tenant 客户端策略，都体现了”胖客户端”思想。

5. 统一存储池提升效率。 一个统一的存储系统服务所有工作负载，消除资源碎片化，不同工作负载的峰谷互补提高整体利用率。

6. 后台维护独立运行。 数据修复、垃圾回收、空间均衡等后台任务作为独立服务运行，不影响前台读写性能。

参考资料

  1. Google Cloud Blog, A peek behind Colossus: Google’s file system, April 2021.
  2. Pan et al., Facebook’s Tectonic Filesystem: Efficiency from Exascale, USENIX FAST’21.
  3. Andrew Fikes, Storage Architecture and Challenges, Google Faculty Summit, July 2010.
  4. Ghemawat et al., The Google File System, ACM SOSP 2003.
  5. Google Cloud Blog, How Colossus keeps your data safe with automatic data tiering, 2024.

如果这篇文章对你有帮助，欢迎点赞收藏。有任何问题或补充，欢迎在评论区交流。

posted on 2026-03-13 16:43  vastdata  阅读(1)  评论(0)    收藏  举报

导航