Skip to content

design.md

Latest commit

 

History

History
306 lines (204 loc) · 9.87 KB

design.md

File metadata and controls

306 lines (204 loc) · 9.87 KB

HugeSCM 的设计哲学

一、版本控制系统的演进与挑战

1.1 传统版本控制系统的局限性

在软件开发的长河中，版本控制系统（VCS）经历了从集中式到分布式的演进。Subversion 作为集中式版本控制的代表，采用客户端-服务器架构，所有版本历史存储在中央服务器。Git 作为分布式版本控制系统的典范，将完整仓库克隆到本地，支持离线操作。

然而，随着软件研发规模的急剧膨胀，特别是 AI 大模型研发、游戏开发等场景的兴起，传统 VCS 面临严峻挑战：

单一存储库体积巨大

现代 AI 模型训练产生的 checkpoint 文件动辄数十 GB 甚至上百 GB，一个存储库可能包含多个版本，总体积轻易突破 TB 级别。Git 的本地存储架构使得克隆和同步变得极其低效。

单一文件体积巨大

大型 AI 模型文件、游戏资源文件、二进制依赖包等单一文件可能达到数十 GB。Git 对大文件的支持有限，Git LFS 虽然缓解了这一问题，但引入了额外的存储开销和管理复杂度。

网络传输瓶颈

传统的 VCS 传输协议未针对大文件优化，在网络不稳定的环境下，大文件传输失败率高，重传代价大。

1.2 现有解决方案的不足

针对 Git 在大规模存储库场景下的问题，业界已有一些尝试：

Git LFS (Large File Storage)

Git LFS 将大文件存储在单独的服务器上，仅在仓库中保留指针文件。但这种方案存在明显缺陷：

  • 需要额外的存储空间存储 LFS 对象
  • 文件分割后仍需完整下载，无法增量同步
  • 与 Git 主仓库的集成不够紧密

Git + OSS/分布式文件系统

将 Git 对象存储到对象存储或分布式文件系统中，看似解决了存储上限问题，但：

  • 未经优化的架构导致性能严重下降
  • 频繁的小文件读写成为性能瓶颈
  • 无法从根本上解决 Git 设计的局限性

二、HugeSCM 的设计理念

2.1 数据分离原则

HugeSCM 的核心创新在于数据分离原则，将版本控制系统的数据分为两类：

元数据（Metadata）

包括提交对象（commit）、目录对象（tree）、分片对象（fragments）和标签对象（tag）。这些对象体积较小，但访问频繁，适合存储在分布式数据库中，支持快速索引和查询。

文件数据（Blob）

文件内容数据，体积可能非常大，存储在分布式文件系统或对象存储中。Blob 采用压缩存储，支持多种压缩算法（ZSTD、Brotli、Deflate 等）。

这种分离设计带来了显著优势：

+------------------+     +------------------+
|   元数据数据库    |     |   对象存储/OSS   |
|  (分布式数据库)   |     |  (分布式文件系统) |
+------------------+     +------------------+
        ↑                         ↑
        │                         │
   commit/tree              blob 数据
   fragments/tag            (压缩存储)
   (高频访问)               (大文件优化)

2.2 集中式与分布式的融合

HugeSCM 采用集中式架构，但并非传统意义上的集中式：

  • 服务端存储完整的数据集，支持巨型存储库
  • 客户端获取浅表副本，按需拉取数据
  • 支持单分支/单标签的数据获取，而非全量克隆

这种设计避免了分布式 VCS 的全量同步负担，同时保留了本地操作的灵活性。

2.3 高效传输协议

HugeSCM 设计了专门的传输协议，针对不同场景优化：

元数据传输

  • 支持增量获取，基于 deepen-from 或 deepen 参数
  • 支持稀疏获取，仅下载指定目录的元数据
  • 使用 ZSTD 压缩减少传输量

文件传输

  • 小文件批量下载，减少 HTTP 请求数
  • 大文件签名 URL 下载，支持断点续传
  • 支持外部加速器（Dragonfly、aria2）

2.4 巨型文件支持：Fragments 对象

HugeSCM 引入了 Fragments 对象，专门解决单一文件体积限制问题：

分片机制

将巨型文件切割成多个 Blob 存储，Fragments 对象记录每个分片的索引、大小和哈希值。

CDC 分片

支持 Content-Defined Chunking，基于文件内容动态确定分片边界：

  • 局部修改只影响附近的 1-2 个分片
  • 相同内容自动去重
  • 特别适合 AI 模型的增量更新场景

优势

  • 上传/下载可并行化，提高稳定性
  • 支持断点续传，网络抖动不影响整体
  • 增量传输，减少带宽消耗

三、架构设计

3.1 服务端架构

                    +------------------------+
                    |     Zeta Server        |
                    +------------------------+
                              │
            +-----------------+-----------------+
            │                 │                 │
    +-------v-------+ +-------v-------+ +-------v-------+
    |   元数据缓存   | |   元数据存储   | |   文件存储    |
    |  (内存/磁盘)   | |  (分布式DB)   | |   (OSS)      |
    +---------------+ +---------------+ +---------------+

存储层次

  1. 内存缓存：最新元数据的缓存，加速热点访问
  2. 磁盘缓存：服务端本地磁盘缓存，减少 DB 查询
  3. 元数据数据库：持久化存储 commit/tree/fragments
  4. 对象存储：持久化存储 blob 数据

3.2 客户端架构

工作目录
├── .zeta/
│   ├── zeta.toml        # 存储库配置
│   ├── packed-refs      # 打包的引用
│   ├── refs/            # 松散引用
│   ├── index            # 工作区索引
│   ├── metadata/        # 元数据对象
│   └── blob/            # 文件对象
├── .zetaignore          # 忽略规则
└── .zattributes         # 属性配置

特点

  • 本地存储浅表副本，按需获取数据
  • 支持 --one 逐一检出模式，节省磁盘空间
  • 支持 --limit=0 空检出模式，按需获取文件

3.3 对象模型

HugeSCM 定义了完整的对象模型，使用 BLAKE3 作为哈希算法：

对象类型 说明 存储位置
Commit 提交对象，记录版本快照 元数据库
Tree 目录对象，记录文件结构 元数据库
Blob 文件内容对象，支持压缩 对象存储
Fragments 分片对象，管理大文件分片 元数据库
Tag 标签对象，兼容 Git Tag 格式 元数据库

四、核心特性

4.1 空间优化

逐一检出（One-by-One Checkout）

检出文件后立即删除 blob 对象，100GB 的存储库仅需 100GB+ 的空间，相比 Git LFS 节省 60% 以上空间。

按需获取（Promisor Object）

默认开启自动下载缺失对象，需要时自动从服务端获取。

空间管理策略

支持 core.optimizeStrategy 配置，自动清理不再需要的对象。

4.2 下载加速

加速器 说明 适用场景
direct 直接从 OSS 签名 URL 下载 AI 场景，高速内网
dragonfly 使用 Dragonfly P2P 加速 大规模分布式环境
aria2 使用 aria2c 多线程下载 个人开发环境

4.3 跨平台文件名处理

Windows/macOS 文件系统忽略文件名大小写，HugeSCM 利用稀疏检出机制：

  • 检测同名冲突文件
  • 将冲突路径标记为不可变、不可见
  • 避免数据丢失问题

4.4 稀疏检出

支持目录级别的稀疏检出，只检出需要的目录：

  • 减少本地存储空间
  • 加快检出速度
  • 支持忽略文件名大小写冲突处理

五、与 Git 的差异

5.1 架构差异

特性 Git HugeSCM
架构模式 分布式 集中式
全量克隆 必须 不支持，按需获取
哈希算法 SHA-1/SHA-256 BLAKE3
数据存储 本地文件系统 DB + OSS

5.2 命令差异

Git 命令 HugeSCM 命令 说明
git clone zeta checkout (co) 检出存储库，非全量克隆
git fetch zeta pull --fetch 仅获取数据，不合并
git pull zeta pull 拉取并合并
- zeta ls-tree -r HEAD 查看目录结构（含文件大小）

5.3 设计哲学差异

Git 的设计假设

  • 存储库可以完整克隆到本地
  • 本地操作优先，网络操作次要
  • 全量历史可用

HugeSCM 的设计假设

  • 存储库太大，无法完整克隆
  • 网络传输是核心瓶颈
  • 按需获取，最小化本地存储

六、适用场景

6.1 AI 大模型研发

  • 存储 checkpoint 文件
  • 模型版本管理
  • 增量更新传输
  • 多团队协作

6.2 游戏研发

  • 大型二进制资源管理
  • 美术资产版本控制
  • 跨团队协作

6.3 驱动开发

  • 二进制依赖管理
  • 多版本维护
  • 发布管理

6.4 数据集存储

  • 大规模数据集版本管理
  • 数据标注协作
  • 数据集分发

七、设计权衡

7.1 为何不支持 Delta 压缩

Git 的 Pack 文件使用 Delta 压缩减少存储空间，但 HugeSCM 选择不支持：

  • Delta 解压计算开销大
  • 大文件 Delta 效果有限
  • 集中式架构下可直接删除不需要的对象
  • 简化实现，提高性能

7.2 为何不支持多 Remote

HugeSCM 设计上不支持多 Remote：

  • 巨型存储库的多 Remote 管理复杂
  • 数据一致性难以保证
  • 集中式架构下单 Remote 足够

7.3 为何使用 BLAKE3

BLAKE3 相比 SHA-1/SHA-256：

  • 更快的计算速度（SIMD 优化）
  • 更强的安全性
  • 更短的哈希值（256 bit）
  • 现代密码学设计

八、总结

HugeSCM 是面向巨型存储库的下一代版本控制系统，通过数据分离、高效传输协议、分片机制等创新设计，解决了传统 VCS 在 AI 大模型、游戏研发等场景下的存储和传输瓶颈。

核心理念：按需获取，最小化本地存储，最大化传输效率。

设计目标：让版本控制不再成为大规模研发的瓶颈。