一边是 20 亿条已治理存量，一边是单批 1500 万条 查询向量。当多模态数据进入十亿乃至千亿级规模，真正棘手的问题已不只是“能不能存下来”，而是数据能否在持续写入、补列、建索引和多种查询之间保持可管理、可复用。
9 月 12 日，在 Lance 开发者沙龙（Lance Meetup）上海站现场，火山引擎数智平台技术工程师 马进、孙鑫 围绕 多模态数据湖 的产品演进与规模化实践展开分享，系统介绍了 以 Lance 为统一数据底座，打通数据工程、模型训练 与 检索链路，让持续演进的数据保持可管理、可观测和可复用的实践路径。
以下内容摘自演讲实录。
AI 数据链路为何越来越重：
三类 负载 ，三套系统
典型的 AI 数据流水线包含三类工作负载：
第一类是 数据预处理，包括清洗、加工、打标和数据集筛选，通常由 Spark、Ray 等计算引擎和传统湖格式承担。
第二类是 索引与搜索，既包括面向 RAG 等场景的在线服务，也包括通过标量、全文和向量索引完成样本回捞、语义去重与正负样本生产。
第三类是 训练，尤其面对图像、视频等数据时，需要高效随机采样和高吞吐读取。
三类 负载 对系统能力的要求不同，过去往往对应三套技术栈。 同一批数据需要在不同格式和系统间反复搬运，团队既要维护多份数据，也要处理版本、接口和任务调度之间的复杂关系。
Lance 提供了另一种思路： 将结构化字段、图像、视频、音频、文本和向量放在同一个数据底座中，同时支持随机读取，以及标量、全文、向量等多类索引。上层连接 Spark、Ray、LanceDB 和 ByteHouse，让 ETL、训练、离线检索与在线分析尽量围绕同一份数据展开。
而统一格式只是起点，进入生产环境后，分区、碎片、索引维护和失败恢复等问题仍需解决。
火山引擎 LAS ：
AI 数据湖 服务解决方案
构建逻辑分区
传统数据湖主要依靠物理分区：根据时间、地域等字段把文件放入不同目录，查询时跳过无关分区。这种方式直观，但一张表很难同时采用多套分区规则，也容易因数据倾斜和微批写入产生小文件。
而 Lance 面对的问题更加复杂，BTree、全文索引和 IVF 类向量索引各有自己的组织方式，并不存在一种 Partition Spec 能同时适配数据文件和所有索引。
火山引擎 LAS 的处理方式是基于 ZoneMap 构建逻辑分区， ZoneMap 将 Fragment 中的数据划分为连续 Zone，并记录指定字段的最小值、最大值和空值数量。查询到来时，系统先判断谓词与这些值域是否相交；确定不可能命中的区域直接跳过，剩余候选数据再做精确过滤。
逻辑分区不再要求物理文件严格按某个目录边界切开，同一份数据也可以针对来源、入湖时间等字段分别建立 ZoneMap。在千亿级数据工程案例中，Spark Driver 同时加载 Source 和 Ingest Time 两组 ZoneMap，再对候选集求交，将 Candidate Fragments 从 12个 裁剪到 4个，随后才把扫描任务交给 Executors。
这套机制也有明确边界：ZoneMap 是保守过滤器，剪枝效果仍取决于数据局部性。如果相关字段在文件中分布过于离散，能够跳过的数据自然有限。
增量维护闭环
数据持续入湖，会不断新增 Fragment；在质量审核和打标模型迭代环节，又会通过新增或更新列在同一 Fragment 内产生更多 Data File。横向的列碎片与纵向的行碎片叠加，最终会推高 Manifest 的规模，增加数据集打开、内存占用和提交压力。
更棘手的是，数据与索引虽然独立存储，却并非互不相关——数据文件一旦被重写或合并后，索引覆盖也需要同步恢复。这意味着 Compaction 和索引优化不能各自独立运行，需要协同调度。
为了更好的协同，火山引擎 LAS 将维护过程组织成一个增量闭环：
1.状态感知： 评估表的健康状态，记录文件、索引和版本等可观测指标。
2.增量规划： 判断是否需要 Compaction、版本清理或索引优化，并梳理任务依赖。
3.分段提交： 把超大任务拆成可执行的小任务，逐段完成、逐段提交。
4.故障恢复： 单个任务失败不影响已经提交的结果，恢复后继续推进后续依赖。
其中，ZoneMap-aware Compaction 不只追求减少文件数量，还要保护数据局部性。值域相同的 Fragment 可以合并，值域不同的数据则避免强行拼接。Compaction 完成后，再由独立索引任务恢复新 Fragment 的索引覆盖。进度、成本、覆盖率和失败状态都进入统一的可观测体系。
Lance 规模化落地实践案例：
从千亿级工程到在线检索
千亿级 AI 数据工程实践
在千亿级 AI 数据工程中，数据变化同时发生在行和列两个方向：图片、文本等新批次持续形成新行，质量分和审核结果则不断回填为新列。
Lance Dataset 在这里承担统一逻辑视图，数据来源、入湖时间、样本主键、Caption、OCR、质量和审核结果可以共存，但不同字段按查询需求建立不同索引：ZoneMap 用于训练集筛选，BTree 支持按 Sample ID 回捞异常样本，全文索引用于关键词复核。
数据与索引可以独立迭代，而训练任务通过 Tag 固定到指定版本。即使入湖和索引维护仍在继续，训练期间看到的数据也能保持一致。
十亿级图像增量治理闭环实践
图像去重不能只看文件 Hash，裁剪、放大、加水印或调色之后，文件已经变化，但表达的内容可能仍然相同。传统基于文件哈希的去重无法识别这类近似重复。
火山引擎的做法是先生成图像向量，再通过近似检索找出候选。新增数据先完成批内检索，再与历史存量进行分布式批量检索；两类候选汇总后，由业务逻辑完成最终判断。有效数据重新写回同一个 Lance Dataset，补齐增量索引并发布新版本，成为下一批数据查询时的基线。
这一闭环面对的是 20 亿条已治理存量和单批 1500 万条 Query。存量索引被拆成 20 个 Segment，每个 Segment 约承载 1 亿条数据。Ray 中的 Segment Actor 与分片固定绑定，使每个 Worker 只需加载并反复复用自己的热索引。每个 Actor 计算 Local Top-K，再由 Driver 对 20 路结果做增量归并，得到全局 Top-K。
进一步的性能问题出现在 Lance Core 内部。优化前，每个 Query 都独立生成扫描与检索计划；同一批查询即使命中相同的 IVF Partition，也会重复加载和准备数据。
Batch Query 优化将“Query 到 Partition”的映射反转为“Partition 到 Queries”：一个 Partition 只加载、准备一次，再为不同 Query 保留独立的计算缓冲区和 Top-K Heap。检索语义没有改变，减少的是重复调度与数据准备。
在相同数据、参数和预热索引条件下，IVF_RQ、1 亿条数据、768 维向量、Batch Size 16 的测试结果显示：
1.单并发 QPS 从 1317.5 提升到 2050.0，增幅 55.6% ；
2.八并发从 3372.8 提升到 3888.7，增幅 15.3% 。
这说明批量检索的优化重点不只是增加并行度，还包括让并行任务共享可复用的准备工作。
ByteHouse 在线检索方案
除离线检索之外，同一份 Lance 数据还需要服务在线请求。ByteHouse 可以直接读取 TOS 对象存储上的 Lance 湖表，为向量检索、全文检索和标量过滤提供统一的 SQL 入口。
其上层 Coordinator 负责 SQL 解析、固定数据版本、加载 Manifest 与索引信息，并结合节点拓扑生成执行计划；下层 Worker 与索引 Segment 绑定，通过内存缓存复用 Lance Index，再用磁盘缓存减少对象存储读取。各 Worker 的局部结果返回 Coordinator，继续完成排序、聚合和结果合并。
至此，离线生产、Ray 分布式批量检索和 ByteHouse 在线检索，不再依赖三份彼此割裂的数据，而是共享同一份持续演进的 Lance 版本数据。
统一底座 、持续演进
Lance 解决的是底座统一问题，火山引擎 LAS 补上的则是规模化运行所需的管理能力：逻辑分区、智能 Compaction、版本清理、索引维护、任务依赖、故障恢复和可观测性。火山引擎 LAS 后续还计划引入 Liquid Clustering，并把增量 Embedding、特征工程以及 UDF、AI Function 等能力纳入管理流程。这些仍属于规划方向，但目标已经很清楚：让数据、索引、算子和训练链路围绕同一底座持续演进。
从三套系统走向统一数据底座，最难的不是完成一次格式迁移，而是让数据在不断增长、更新和被查询的过程中，仍然能够稳定维护、持续复用。只有做到这些，统一底座才会从架构设想变成可持续的数据工程能力。