Lance Blob V2 零拷贝 Compaction 深度解析

Lance Blob V2 零拷贝 Compaction 深度解析代码版本: 基于 acking-you/lance fork, branch feat/static-flow 适用场景: 包含大型二进制数据（音频、图片）的 Lance 数据集 compaction导航 | 章节 | 一句话 | |---|---| | §1 | 从存储优化到 compaction 困境 | | §2 | Blob V2 核心概念：描述符、Schema 二象性、data_file_key | | §3 | 困境：官方两条 compaction 路径均失败 | | §4 | 方案演进：从 sidecar 拷贝到零拷贝 | | §5 | 实现详解：逐层构建零拷贝管线 | | §6 | 设计决策与权衡 | | §7 | 测试策略与 E2E 验证 | | §8 | Code Index |1. 引言：从存储优化到 Compaction 困境 StaticFlow 音乐模块需要存储 ~500 首歌 × 10MB/首的音频数据。最初使用 blob v1 模式，音频混在 .lance 列式文件里，导致磁盘膨胀到 27GB。迁移到 blob v2（data_storage_version=2.2）后，音频作为 .blob sidecar 文件独立存放，存储降到 4.7GB——但随之暴露了新问题：每首歌通过 append 写入产生一个独立的 fragment。500 首歌 = 500 个 fragment，查询性能线性下降。Compaction（合并小 fragment）是必须的，但 lance 上游不支持含 blob v2 列的 compaction（issue #4947）。标准路径要么直接拒绝，要么 schema 不匹配崩溃。关于 blob v1 → v2 的完整迁移过程、存储原理对比、和 fork 决策，详见 LanceDB Blob 存储演进实战。本文聚焦：如何在 lance fork 中实现 blob v2 零拷贝 compaction—— 让 compaction 过程中 .blob 音频文件一个字节都不拷贝，峰值磁盘开销从 2× 降到 ~0。 Blob v2 社区原始提案文档（参考）：Blob v2 Design Doc2. 前置知识：Blob V2 核心概念本文后续章节依赖几个 blob v2 的核心概念，此处精简介绍。完整原理见前序文章的第三、四章。2.1 BlobKind 与描述符 Blob V2 将数据与元数据分离：.lance 列式文件只存 30 字节/行的描述符，实际数据根据大小分到 4 种 BlobKind（datatypes.rs:434-446）： | BlobKind | 条件 | 数据位置 | |----------|------|----------| | Inline (0) | ≤ 64KB | 嵌入 .lance 文件末尾 | | Packed (1) | 64KB ~ 4MB | 多行共享一个 .blob sidecar | | Dedicated (2) | > 4MB | 独立 .blob sidecar（一行一文件） | | External (3) | 用户提供 URI | 不存储，只记录外部 URI | 每行描述符有 5 个字段（datatypes.rs:50-58），以一首 10MB MP3 为例：5-field 描述符 (磁盘格式): kind=2(Dedicated) position=0 size=10485760 blob_id=0 blob_uri="" 2.2 Schema 二象性用户侧看到的是 2 字段：Struct<data: Binary, uri: Utf8>。磁盘侧存储的是 5 字段：Struct<kind, position, size, blob_id, blob_uri>。 💡 Key Point — 这两套 schema 的不匹配，是写入管线适配（§5.2–5.3）的核心挑战。2.3 data_file_key 每个 .lance 数据文件有唯一标识 data_file_key（文件名去掉 .lance 后缀）。 Blob sidecar 路径由它构成：data/{data_file_key}/{blob_id}.blob。 ⏭️ 零拷贝方案的核心思路就是复用这个字段——把源 data_file_key 写进描述符的 blob_uri，让新 fragment 的读取路径指向旧目录的 .blob 文件。详见 §4.4。3. 困境：官方两条 Compaction 路径均失败 compact_files() 内部有两条已有的执行路径。对于含 b…