GooseFS+Lance:面向 AI 时代定义向量存储加速

01

从“IO 困境”到“原生加速”：腾讯云 GooseFS 如何与 Lance 协同，定义 AI 时代向量存储新范式

随着多模态与大模型应用的爆发式增长，面向 AI 的数据基础设施正在经历一场深刻的变革。以 Lance 为代表的新一代多模态数据格式，凭借其对向量的原生支持、高性能随机访问与零成本 Schema 演进等特性，正迅速成为 AI 数据栈的基石。

然而，当我们将目光投向云端，将 Lance 直接运行在裸对象存储（如腾讯云 COS）之上时，一系列新的挑战浮出水面。高昂的网络延迟、多写者场景下事务控制的缺失、对 List/Head 等元数据操作的重度依赖，以及更复杂的多表事务需求，共同构成了 Lance on Object Storage 的“IO 困境”。

如何破解这一困境，让云上数据湖充分释放 Lance 的潜力？来自腾讯云对象存储团队的 GooseFS 给出了一份系统性的答卷。本文将深入解读 GooseFS 如何通过一系列原生加速设计，与 Lance 深度协同，为 AI 时代的向量存储提供一套兼具性能、成本与可治理性的解决方案。

02

GooseFS 与 Lance 的相遇：从通用缓存到原生加速

GooseFS 最初为解决近计算端加速问题而生。它通过在靠近业务和计算集群的位置部署缓存，将热数据预热至本地，从而显著降低访问延迟、提升吞吐，已在 OLAP、湖仓、自动驾驶训练等多个场景中取得了 2 到 10 倍的性能提升。

当 Lance 出现后，团队敏锐地意识到，一个更深度的结合将产生远超通用文件缓存的价值。他们没有停留在简单地将 Lance 文件作为普通文件进行缓存，而是选择了一条更深入、更原生的融合路径——全面拥抱并扩展 Lance Namespace 规范。

Namespace 接入：协同的起点与宏图

选择接入 Lance Namespace 规范，是 GooseFS 实现原生加速的第一步，也是至关重要的一步。这意味着 GooseFS 不再仅仅是一个“透明”的缓存层，而是成为了 Lance 生态中一个有感知、可交互的“目录服务”（Catalog Service）实现。

其核心设计在于：

• 统一入口：所有来自上层计算引擎（如 Spark、Ray、DuckDB 等）的请求，都通过实现了 Lance Namespace 规范的 GooseFS Catalog Service 进行收口。

• 物理执行计划拆解与优化：Catalog Service 在收到请求后，不再是简单地透传，而是会对请求进行物理执行计划的拆解。例如，一个查询请求会被解析出其所依赖的所有数据文件（Datafile）路径。

• 主动预热的基石：正是基于这种执行计划的“洞察力”，GooseFS 得以为后续一系列主动、智能的优化（如数据预热）创造了可能性。

完成 Namespace 接入后，即使只配合基础的缓存能力，GooseFS 相对于裸对象存储也获得了约 3 倍的性能提升，这证明了方向的正确性。但真正的“原生加速”，远不止于此。

03

引擎协同：揭秘 GooseFS 原生加速架构的核心

GooseFS 的原生加速架构可以清晰地划分为两大层次：下层的文件缓存层与上层的目录服务（Catalog Service）。其中，Catalog Service 是整个加速体系的“大脑”，它通过两大核心机制——事件拦截与 Warm Cache 和 后台 Compaction 与水位治理——实现了对 Lance 数据生命周期的深度介入和优化。

1. 事件拦截与 Warm Cache：从被动缓存到主动预热

为了实现从“被动”到“主动”的跨越，GooseFS 在 Catalog Service 中实现了 TableEventHandler 的拦截机制。

• 请求感知：任何对表的查询、写入等操作，都会触发相应的 Event Handler。

• Datafile 路径解析：Handler 利用 Lance SDK 解析出操作所涉及的精确 Datafile 路径。

• 异步预热任务：解析出的路径被提交给一个名为 Job Service 的后台异步服务。Job Service 负责执行真正的预热操作，将这些即将被访问的数据提前从对象存储拉取到 GooseFS 的缓存层中，形成 Warm Cache。

如此一来，当计算引擎实际发起数据读取 IO 时，数据已在本地“恭候多时”，实现了极致的低延迟。

更进一步，GooseFS 还引入了基于访问统计（Statistics） 的预测性预热：

• 热度追踪：系统会持续统计表、分区乃至列的访问频次。

• 热点预测：根据统计数据，识别出高频访问的“热表”和“热列”。

• 精准预热：与这些热点关联的数据集会被优先、主动地预热到缓存层，从而将缓存资源的利用效率最大化。

2. 小文件治理：自动化的后台 Compaction

频繁写入是数据湖场景的常态，这也无可避免地会产生大量碎片化的小文件，严重影响读取性能。GooseFS 通过一套基于“水位”的自动化治理机制来应对这一挑战。

• 水位监控：系统内部设有关于碎片文件数量或大小的“水位线”标识。

• 触发 Compaction：一旦某个表的小文件数量触及预设的水位线，系统会自动向 Job Service 提交一个 Compaction 任务。

• 后台合并：Job Service 在后台执行数据合并操作，将大量小文件聚合成少量大文件，并同步重建相关的元数据与索引缓存。

这个过程对上层应用完全透明，确保了数据表在长期运行后，其存储效率和查询性能始终保持在一个健康、平衡的状态。

3. 原生事务支持：告别 External Manifest Store

在多写者并发控制上，早期基于对象存储的方案往往依赖 Put-If-Not-Exists 语义，但这并非所有对象存储版本都支持。社区曾建议通过 External Manifest Store 机制来解决，但这无疑增加了架构的复杂性。

GooseFS 凭借其中心化的 Table Service，提供了一种更原生的解决方案：

• 中心化仲裁：所有与事务相关的元数据（如 _versions、_manifests、_transactions 文件）都由 Table Service 在内存中进行维护和管理。

• 内存级仲裁：当多个写入者并发提交事务时，所有的仲裁逻辑都在 Table Service 的内存中完成，无需依赖底层的原子操作。

这使得 GooseFS 能为 Lance 提供原生的、开箱即用的单表并发事务支持。目前，团队正在积极调研多表事务以及多 Worker 写入时的事务合并等更复杂的场景，旨在提供更完备的事务能力。

4. 极致点查加速：为 Mini Block 设计的“ Page 缓存”

Lance 相较于 Parquet 的一个革命性设计在于其 Mini Block 结构，它使得点查或小范围扫描不再需要解压整个大的 Row Group。为了将这一优势发挥到极致，GooseFS 在其缓存层进行了一项关键创新—— Page 缓存（Paged Cache）。

• 告别整块缓存：传统的缓存系统（如 HDFS Cache）通常以固定的大数据块（Block）为单位进行缓存。这意味着即使一次点查只涉及几 KB 数据，也可能需要从底层缓存一个完整的、数十甚至上百 MB 的大文件块，造成严重的读放大和缓存空间浪费。

• 小 Chunk 按需缓存：GooseFS 的配级缓存允许以更小的、可变大小的“配级（Page）”或“小块（Chunk）”为粒度进行缓存。当一次随机查询发生时，GooseFS 只需从对象存储中拉取并缓存其所需的、与 Mini Block 精准对应的极小数据块。

这一设计与 Lance 的文件格式形成了完美的共鸣。在基于 CLIP 模型（如 diffusiondb）的查询测试中，采用配级缓存的 GooseFS 展现了惊人的性能：

• 相对裸对象存储，性能提升近 3 倍。

• 相对传统的 Block 缓存模式，性能提升超 2 倍。

这证明了存储格式与缓存系统在设计理念上的深度协同，能够释放出巨大的性能潜力。

04

实践与展望：不止于存储，迈向存算一体

目前，GooseFS + Lance 的组合已在腾讯内部的 OpenCloud 记忆库等场景率先落地，为 Agent 应用提供了高效、可扩展的数据底座。

展望未来，团队的目光已从“存储加速”延伸至“存算一体”的更广阔图景：

• 原生查询能力：计划引入 Ray 等计算框架，使 GooseFS 本身具备轻量级的原生查询处理能力，让“存储”离“计算”更近一步。

• 与向量桶等产品深度融合：腾讯云存储近期发布的向量桶等产品，同样提供了原生的向量查询能力。未来，GooseFS 将与这些产品进行更深度的集成，共同构建一套从底层硬件到上层应用的全栈 AI 数据解决方案。

从最初应对 IO 困境的缓存系统，到如今与 Lance 深度协同的原生加速引擎，GooseFS 的演进之路，正是云原生存储拥抱 AI 时代的一个缩影。通过 Namespace 接入、事件驱动的预热、自动化的后台治理、原生的事务支持以及为 Lance 量身定制的配级缓存，GooseFS 不仅解决了对象存储上的性能瓶颈，更提供了一套完整的、面向未来的多模态向量存储加速范式。

点个在看你最好看

SPRING HAS ARRIVED