大模型的迭代正在把数据推到舞台中央。当训练语料从整齐的结构化行表，变成图像、视频、音频、文本与 Embedding 混杂的资产，传统数据湖在存储格式、访问模式与计算引擎上都面临新的挑战。百舸多模态数据湖要回答的是：如何让多模态数据像结构化数据一样被高效地存、算、管。
1. 多模态数据湖面临的 3 个变化
1.1 数据主体：从「结构化行表」到「多模态资产」
先看一条样本本身。过去做推荐或风控，一条样本通常就是这几列标量：id / user_id / item_id /label / ts，整行不过几十字节，一个 Parquet 文件装得下千万条。
今天一条训练样本要同时携带图像或视频 blob、caption 文本、1024 维 Embedding、质量分、标签与版本号：仅 Embedding 一列就是 4 KiB（1024 × float32），一张 1024×1024 的 JPEG 压缩后通常在数百 KB 量级，「一行」从字节级涨到了 MB 级。
具体到场景：多模态预训练语料里，一条样本 = 图片 + 网页 alt 文本 + CLIP 相似度 + NSFW / 水印分，LAION-5B 的原始发布规模约为 58.5 亿条经 CLIP 过滤的图文配对记录，公开内容主要包括图片 URL、文本和相关元数据，图片本体通常需要另行获取。自动驾驶里，一条样本 = 多路摄像头视频片段 + 激光雷达点云 + CAN 时序 + 3D 标注框；具身智能里，一条样本 = 多视角 RGB 视频 + 机器人状态、动作与语言指令。Open X-Embodiment 汇集了覆盖 22 种机器人本体的 100 万条以上真实机器人轨迹，并采用统一的 RLDS 数据封装。RT-X 中常见的 7 维表示是末端执行器动作，不等同于七个关节状态。
但真正的麻烦不只在「大」，还在「散」。图像存在对象存储、标注存在数据库、Embedding 存向量库、版本号记录在实验平台，四个系统靠文件名与 ID 互相指认，没有一件事务能跨系统保证一致，删一条样本要记得删四处，漏一处就会留下长期的存储开销与脏读。多模态湖要做的第一件事，就是把这些字段收回同一行。
1.2. 算力形态：从 CPU-only 的 ETL，到 CPU / GPU / 推理混部
传统 ETL 的形态是筛、连、聚：Spark 在 CPU 上跑 join 与 group by，瓶颈在磁盘和网络 I/O，加机器、换 SSD 通常就能获得较好的收益。多模态加工不一样，管线里直接嵌进了模型：CLIP 算 Embedding、Qwen-VL 生成 caption、NSFW 模型做安全过滤、YOLO11 做目标检测。这些算子的耗时主体在 GPU，CPU 只负责解码、缩放、切片这类搬运与预处理。
这一变化因此提出两个硬要求：异构调度，让 CPU 批处理与 GPU 推理在同一集群混部、各自弹性；以及供给稳定，数据读得足够快， GPU 不因等数据而停顿。
1.3. 价值重心：决定上限的变量回到数据质量
当算力与模型结构逐渐趋同，实验之间的差距越来越多来自「用了哪一版数据」。数据由此从一次性输入变成需要长期经营的资产：
- 版本让训练任务绑定到具体某一版，三个月后回看两版模型的差距，能确定地归因到某个版本的高质量样本，而不必靠回忆；
- 血缘让一条进训练的样本可回溯到原始视频、算子版本与模型 Checkpoint，反过来某批素材出了版权或质量问题，也能精确圈出所有受影响的派生版本，而不必全量重跑；
- 可检索性让「从 58 亿条里取相似于某 query、或美学分高于阈值的子集继续训练」这类操作可以在数据侧完成，减少跨系统导出和关联。
数据主体变得更复杂，算力形态变得更多样，数据质量变得更重要。它们共同推动数据湖从单纯的数据存储仓库，走向一个需要格式、版本、索引与计算调度协同支撑的数据基础设施。
2. 与传统结构化数据湖的差异
把两者放在一起看，差异是系统性的，而且每个维度都对应一条明确的实现路径。
传统结构化和文本数据湖，主要面向行数庞大的轻量级数据，典型工作负载是 SQL 查询、批量扫描和聚合分析。而面向 AI 的多模态数据湖，数据形态和使用方式都发生了变化，对底层架构提出了新的要求。
首先是数据单元的变化。传统数据湖中，一行数据通常只有几十到几百字节，数据规模主要由行数决定。而在多模态场景中，一行数据可能包含 MB 甚至 GB 级的图片、视频和音频等大对象，还有与之关联的 Embedding 和标注，行数不再能直接反映数据规模。这要求存储架构能够区分数据的冷热访问特征，由对象存储承担全量数据的持久化存储，由并行文件存储承接训练期工作区和热数据，兼顾海量数据的存储成本和训练过程中的读取效率。
其次是 Schema 与访问模式。传统数据湖的 Schema 以业务字段演进为主，也支持加列和更新，但变化相对低频。而在 AI 场景中，模型实验会持续产生新的 Embedding、质量评分和标注字段，Schema 因此呈现出实验驱动、频繁演进的特点，底层格式需要支持新增字段而不重写整个数据集。与此同时，数据的主要使用方从 SQL 分析变成了模型训练：训练任务通过 DataLoader 随机读取样本，每次只读取其中部分字段，随机访问与列投影同时存在。这要求存储格式既具备列式布局，又要支持高效随机访问。
数据的计算和检索方式也随之变化。传统数据湖主要依赖 Spark、Trino 等引擎执行批量 SQL，而 AI 数据处理更多需要 Python 原生计算、模型调用和 GPU 推理等能力，Daft、Ray 等引擎更适合这类工作负载。在检索层面，除了传统的 SQL 条件过滤和 Join，还需要把向量检索、全文检索与 SQL 过滤结合起来使用。这要求数据湖既能对接 Daft、Ray 等面向 AI 的计算引擎，又能把向量数据及其索引与其他数据字段统一组织，让检索和筛选在同一份数据上协同完成。
最后，数据的生命周期也从传统的 ETL 加工和报表分析，延伸到数据入湖、模型训练、模型评估、推理应用和数据回流。数据会在这一过程中持续产生、更新和派生。这要求数据湖不只管理数据存储，还要具备数据集版本管理能力，并由湖管理层托管文件合并、过期数据清理和 TTL 等日常维护工作。
可以看到，多模态数据湖并不是简单地在传统数据湖中增加图片、视频和向量等数据类型，而是单元粒度、Schema、访问模式、计算引擎、检索能力和生命周期都发生了系统性变化。
百度百舸多模态数据湖的产品设计与技术选型，围绕这些变化展开。
3. 百度百舸多模态数据湖
百舸多模态数据湖的整体架构，最底层的存储底座里，对象存储 BOS 负责全量数据的低成本持久化，文件存储 CFS / PFS 承接训练期的热数据与高频随机读。其上的开源湖格式层支持 Lance 等主流格式，既覆盖结构化场景，也支持多模态的随机访问。
再往上的百舸湖管理层提供统一元数据、自动合并、自动清理与成本优化，降低业务侧的运维负担，并以数据集市的形式提供数据集的分享、下载与管理。
百舸算子广场把包括视频、文本、图像、具身、音频、多模态、文档等各种类别的数据处理能力封装成开箱即用的算子。
最顶层的百舸工作流则把这些算子编排成具体管线，例如「视频截帧 → 图片理解 → 人脸打码」「PDF 解析 → 文本清洗 → 切片」。百舸算子广场基于 Daft 开发，分布式运行由 Ray Job 承接，平台同时支持 Spark 等计算引擎。
计算侧则依赖百舸把异构算力抽象出来的资源池：AI 工程提供加速与推理部署能力，AI 资源管理负责分布式任务、弹性队列、开发机与节点运维，算力底座统一供给 GPU、CPU 与 RDMA 网络。湖内的 CPU / GPU 混合计算建立在这一层之上。
4. 面向多模态数据的湖格式 Lance
Lance 是一个在 Apache 2.0 下开放的列式数据格式。与 Parquet 这类面向数仓分析的格式不同，它从设计之初就面向机器学习的读写模式：高频随机采样、大对象与元数据共存、向量检索、频繁的 Schema 变更、实验版本与派生。
4.1. 列式存储与随机访问：兼顾批量分析和单条读取
列式存储擅长批量读取某一列的数据，但在读取单条记录时，可能面临读放大问题：实际只需要一个值，却需要读取和解码包含该值的数据块。Lance 通过调整数据组织方式，改善了这一问题。
以 Parquet 为例，其数据按照 Row Group（行组）、Column Chunk（列块）和 Page（数据页）组织。读取一条记录时，需要先定位到对应 Row Group 中的列块，再找到包含目标数据的 Page。由于数据经过编码和压缩，实际读取和解码的粒度可能大于所需数据，带来额外开销。
Lance 则取消了 Row Group 这一层级，以 Page 作为数据组织的基本单元，并支持对 Page 进行部分读取。这样，读取数据时不必总是加载整个 Page，还可以按照行边界切分数据，让多个读者并行读取不同的数据范围，提升随机访问和并行读取效率。
此外，Lance 还通过 Page 内部的行定位机制，以及 Mini-block、Full-zip 等编码布局，进一步优化数据的定位与读取方式，使其在保留列式存储优势的同时，也能更高效地支持按行随机访问。
4.2. 大对象列：多模态数据统一组织、按需读取
在多模态数据集中，一条样本往往不只有文本、标注和 Embedding，还包含图片、视频、音频等体积较大的二进制数据。如何将这些大对象与其他关联信息统一组织，同时避免读取一条记录时就加载整个媒体文件，是多模态数据管理需要解决的问题。
Lance 为此提供了 Blob（Binary Large Object，二进制大对象）类型。Blob 是一种用于表示二进制大对象的数据类型，在 Lance 表中，可以将 Blob 作为一列，即大对象列，用来存储图片、视频、音频等媒体数据。这样，原始媒体数据就能与文本描述、标注信息、Embedding 和质量评分等字段共同存储在一条记录中，形成完整的多模态数据样本。
将大对象纳入数据表，并不意味着读取一行数据时就要加载整个文件。Lance 在存储层将 Blob 转换为紧凑的描述符（Descriptor），读取时默认返回描述符，而不是直接加载文件内容。只有在真正需要访问大对象时，才调用 take_blobs() 获取数据。该接口返回类文件对象，支持 seek 和 read 操作，可以定位并读取指定位置的数据。例如，处理视频时，可以按需读取关键帧附近的字节，而不必每次都将整个视频文件读入内存。
这种设计兼顾了数据组织的完整性与读取的灵活性。原始视频、标注信息、Embedding 和质量评分等，可以统一存储在同一行中，不再需要分散在对象存储、关系数据库、向量数据库和其他表格之间，再依赖文件路径进行关联。这样，一行记录就能承载一份完整的多模态资产，相关字段也可以通过一次提交原子地更新，使同一样本的各个字段始终保持一致。
4.3. 向量检索与数据筛选：无需跨库关联
在多模态数据集中，Embedding 是连接数据与语义检索的重要桥梁。传统方式通常需要将 Embedding 从数据仓库中导出，再导入独立的向量数据库建立索引。向量检索得到结果后，还要根据返回的 ID 回到原始数据表，关联图片、文本、标注等信息。数据存储与检索分属不同系统，增加了数据流转和关联管理的复杂度。
Lance 将 Embedding 作为普通的定长列表列存储，可以直接在这一列上构建向量索引，支持 IVF_FLAT、IVF_PQ、IVF_SQ、IVF_HNSW_PQ、IVF_HNSW_SQ 等多种索引类型。同时，同一张表的其他字段也可以建立相应索引，包括用于数值和条件过滤的 B 树、位图，用于文本检索的 N-gram 和倒排索引（支撑全文检索），以及 Zone Map、布隆过滤器、R 树等索引。
这意味着，向量检索可以与标量过滤、文本检索在同一份数据上协同完成。例如，要从指定数据集的样本中，筛选质量分高于 0.8、且与给定图片最相似的 100 条记录，可以先通过标量索引缩小候选范围，再进行向量检索；也可以先进行向量检索，再根据其他字段过滤。先过滤还是后过滤由调用方指定：先过滤能保证在符合条件的样本里返回足够的结果，后过滤则可能因为部分结果被条件筛掉，返回少于 100 条。
对于难例挖掘、语料去重、跨模态检索等场景，这种设计减少了在数据仓库和向量数据库之间反复导出 Embedding、导入向量库、查询 ID、回表关联的操作，将原本分散在多个系统中的检索与数据关联，统一到一张表中完成。
4.4. Schema 演进：新增数据字段，无需重写整个数据集
随着模型和实验不断迭代，多模态数据集也需要持续增加新的信息。例如，使用新模型重新计算一版 Embedding、增加质量评分维度，或补充合规标记等。这些操作都会改变数据表的 Schema（结构定义）。对于 TB 级数据集而言，如果每增加一个字段都需要重写整个数据集，将带来很高的存储和计算开销。
Lance 通过独特的数据组织方式降低了这一成本。一个片段 Fragment 由多个数据文件组成，每个文件只存储部分字段。因此，新增字段时，add_columns 不需要修改已有数据文件，而是为每个 Fragment 追加一个存储新字段的数据文件。原有文件保持不变，新增字段的写入成本主要取决于该字段自身的数据量，而不再与整个数据集的规模成正比。
这让多模态数据集能够更灵活地适应模型实验中的变化：无论是重新生成 Embedding、增加质量评估维度，还是补充新的合规信息，都可以在现有数据集上追加字段，而不必重新构建整套数据。相比之下，传统文件目录式管理往往需要为每次实验新建一份数据集。随着实验版本不断增加，容易出现数据目录越来越多、版本关系难以追踪的问题。Lance 的 Schema 演进能力，则让数据集能够在原有基础上持续扩展，降低实验迭代中的数据管理成本。
4.5. 版本化与零拷贝派生：让实验数据可复用、可追溯
在模型训练和数据实验中，同一份原始数据往往需要衍生出多个版本：训练集与验证集的切分、按质量分筛选出的高质量子集，以及不同实验专用的数据集。如果每次派生都要复制一份完整数据，不仅会带来大量重复存储开销，也会让数据版本越来越难以管理。
Lance 通过版本化机制，避免了每次提交都复制整个数据集。除本次变更新写入的数据文件外，每次提交只需再写入事务记录和清单文件两个对象，记录本次变更及当前版本的数据组织信息，已有数据文件无需重复写入。清单文件采用基于版本号补数的命名方式，使最新版本能够通过对象列举快速定位，打开一张表只需一次列举和一次读取。
在并发控制方面，Lance 默认采用基于条件写入的比较并交换（CAS）机制：只有目标键不存在时，提交才能成功。如果多个任务同时提交，发生冲突时对象存储服务端会返回 HTTP 412。百度智能云对象存储 BOS 的 PutObject 支持 If-None-Match: * 条件写入，对象已存在时返回 412，因此 Lance 的提交可以在 BOS 上完成并发控制，无需额外部署外部锁服务。
在此基础上，Lance 还提供 shallow_clone，支持从指定版本、标签，或分支与版本号的组合派生出新的数据集。与完整复制数据的深拷贝不同，shallow_clone 只复制元数据和文件引用，不重写底层数据文件。派生出的训练集、验证集或实验数据集各自独立且可写，但在物理存储上仍然可以共享父版本的数据文件。即使需要删除数据，也不必修改原始文件，而是为每个受影响的 Fragment 生成一个轻量级的删除向量对象，记录被删除的数据。
这意味着，多个实验可以基于同一份底层数据派生出各自的数据集，而不必产生多份完整副本。同时，每次训练使用的数据都可以通过版本号或标签明确标识。当需要复现实验或排查问题时，可以准确定位到对应的数据版本，追溯当时使用的数据集状态。
4.6. 开放格式与生态，打通数据处理和模型训练流程
一种数据格式能否真正进入 AI 生产流程，不仅取决于自身的存储和处理能力，也取决于能否与现有计算引擎、机器学习框架和开发工具协同工作。
Lance 采用 Apache 2.0 开源许可，并提供 Python、Rust、Java SDK，以及与 Apache DataFusion 的集成，降低不同开发语言和计算引擎接入的门槛。在数据处理和查询层面，DuckDB、Polars、Spark、Ray、Daft 等工具可以通过相应接口或连接器使用 Lance 数据；在模型训练层面，Lance 也提供 PyTorch、TensorFlow 等数据加载支持，使开发者能够将 Lance 数据集接入现有的数据处理和模型训练流程。
今年 10 月，面向机器人学习的开源项目 LeRobot 也集成了 Lance 格式，LeRobotDataset 可以直接读取 Lance 数据集，并沿用原有的数据集接口和训练工具链。借助 Lance，机器人训练团队可以直接从对象存储读取数据，按需获取训练所需的数据内容，并在整个数据集范围内执行全局随机打乱（Global Shuffle），不必先将完整数据集下载到本地。据 LanceDB 的 lerobot-lancedb 基准，在训练读取场景下（每个样本读取 8 帧），以视频格式存储的 Lance 数据集，读取吞吐是 LeRobot 原始格式（Parquet + MP4）的 2 到 3.8 倍 。
同时，团队还可以在同一份数据上进行搜索、筛选和特征扩展，无需为数据挖掘、数据整理和模型训练分别维护多份数据副本。目前该后端用于读取，数据录制和编辑仍使用 LeRobot 默认格式，完成后再转换为 Lance。
这一实践也展现了 Lance 在具身智能场景中的应用价值：面对视频、动作、状态等多模态数据，数据存储、检索、加工和模型训练可以围绕同一份数据集展开，减少数据在不同系统之间的搬运与重复管理，让数据更顺畅地进入模型训练和迭代流程。
5. 百舸湖管理层：让多模态数据从「存得下」走到「用得上」
Lance 解决了多模态数据的格式问题，让图片、视频、音频等数据能够以统一的方式存储、读取和检索。但对于一个长期运行的数据湖来说，仅有开放的数据格式还不够。
随着数据集不断增长，数据表会持续产生新的版本，频繁的数据写入也会带来小文件堆积。实验结束后，需要回收不再使用的历史数据。模型效果出现问题时，还需要追溯它究竟使用了哪一批数据。这些工作都需要持续的元数据管理、自动运维、访问控制和数据血缘能力，而这些并不是开放数据格式本身能够提供的。
百舸多模态数据湖为此构建了湖管理层。其核心设计原则是：**数据面开放，控制面托管。 ** 数据始终以标准 Lance 表的形式存储在对象存储中，兼容的计算引擎可以直接读取。与此同时，百舸湖管理层统一管理数据表的状态、维护策略、访问权限和使用记录，让数据保持开放的同时，也具备长期运行所需的管理能力。
5.1. 元数据自动托管，记录数据表的「现在」和「过去」
数据湖中的表不仅需要存储数据，还需要有稳定的身份和完整的状态记录。百舸湖管理层提供 Catalog、Database、Table 三级命名空间，为每张表建立稳定的身份标识，不再仅仅依赖容易写错或移动的对象存储路径。
注册一张表时，只需提供它在对象存储中的位置，平台便会自动采集和维护相关元数据。其中，版本索引记录每次提交的时间、操作类型和数据量变化，Schema 缓存保存不同版本的字段结构，标签索引支持使用 v1-cleaned、pretrain-2026Q3 等易于理解的名称管理版本，文件级清单则记录当前版本引用的数据文件及其空间占用，为后续的数据治理和成本分析提供依据。
这些信息不需要使用者手工维护。新建表时，平台会先进行轻量级 Schema 预读，让使用者在建表前了解数据结构。建表之后的数据扫描、治理后的元数据回灌，以及手动触发的刷新，都由后台执行流程自动完成。
元数据服务本身不需要读取实际的数据内容，只需读取 Lance 的清单文件和事务记录。因此，元数据托管的开销并不直接取决于数据表中实际存储的字节数。一张百 TB 的视频表和一张百 MB 的标注表，不需要因为原始数据体量相差巨大，就付出同等比例增长的元数据读取开销。
5.2. 表自治：自动运维，优化存储成本与读取性能
多模态数据湖长期运行后，容易出现两个问题：频繁写入产生的小文件越来越多，实验过程中产生的历史版本也不断累积。小文件过多会增加训练读取时的 I/O 开销，历史版本长期保留则会占用额外存储空间。传统方式通常需要工程师编写脚本、配置定时任务，再根据运行情况手动排查和处理。
百舸湖管理层将这些工作转化为表级自动运维策略。使用者只需为数据表配置一次策略，平台便可以持续执行相应的治理任务。
其中，小文件合并会将零散的数据片段整理为更合适大小的数据文件，减少随机 I/O，并清理累积的删除标记。合并通过 Lance 的事务提交机制完成，对正在运行的读取任务保持透明，不需要专门设置停写窗口。与其他写入发生并发冲突时，由事务检测并重试。
快照回收负责清理超过保留期限的历史版本，释放实验过程中产生的中间版本所占用的空间。带标签、仍被训练任务或派生表引用的版本受保留策略保护，不会被回收，几个月后仍能复现当时的实验。孤儿文件清理则负责回收另一类容易被忽略的存储浪费，例如中断写入或失败合并留下的、已经不被任何版本引用的文件。
对于冷热数据，百舸湖管理层还可以通过分层存储和冷热驱逐策略，将长期不访问的历史版本和冷数据迁移到成本更低的存储层级，同时让训练所需的热数据保留在高性能介质上。下沉到低频或冷存储的数据访问路径不变，但会产生取回费用，并受最短存储时长约束；下沉到归档存储的数据需要先恢复才能读取。因此策略需要结合访问频率、取回费用和恢复等待时间来配置。
此外，数据合并和增量写入可能改变数据分布，进而影响索引和查询效率。平台还可以自动重建向量索引、采集统计信息，让检索能力随着数据变化持续得到维护。
5.3. 权限与凭证：数据保持开放，访问有边界
Lance 的开放性让不同引擎可以直接读取数据，但在企业环境中，开放访问并不意味着所有用户都应该拥有相同权限。百舸湖管理层通过统一的权限管理和凭证代发机制，在保持数据开放性的同时控制访问范围。
权限模型直接复用企业已有的 IAM 身份，用户、用户组和角色都可以参与授权，不需要在数据湖中重新建立一套账号体系。授权可以作用于 Catalog、Database 或 Table，并向下继承。平台提供管理、开发、查看、只读等角色，也支持设置授权有效期。
在实际访问数据时，使用者不需要获取长期有效的存储密钥，而是通过平台获取一份有明确有效期、访问范围限定到具体表存储位置的临时凭证。凭证也可以固定在某个特定版本上：按该版本清单文件所引用的数据文件逐个授权，使用者就只能读到这一版的内容，而不会随着表的更新读到新的数据。凭证中包含 Lance 可直接使用的访问参数，使用者拿到后即可交给 DataLoader 或其他兼容引擎读取数据。
这样，数据仍然可以被不同工具直接使用，但每一次凭证签发都留下完整的审计记录。签发记录说明谁在什么时间、以什么身份获得了哪张表的访问权限，实际读取情况可以结合对象访问日志和作业记录核查。元数据侧的变更操作也会留痕。
5.4. 数据血缘：从模型结果追溯到具体数据版本
在多模态场景中，数据问题往往会沿着训练和推理链路影响模型。线上效果出现回退，需要确认是哪一批语料导致的。某批数据被发现存在合规问题，需要知道哪些模型受到了影响。复现过去的实验，则需要准确还原当时使用的数据状态。
百舸血缘将数据血缘精确到「表和版本」。Lance 的事务记录提供每次提交的表内变更信息，百舸工作流、训练和推理服务等环节补充输入表版本、加工代码、算子参数和输出产物，不依赖使用者手工登记。
在此基础上，血缘管理还覆盖数据之外的实体，包括数据集、模型、Checkpoint、评估结果和推理服务。这些实体由各个环节上报，并通过开放的实体类型描述，便于后续扩展新的数据和模型产物。
连接这些实体的是具体的执行节点。例如，一次百舸训练作业或一次推理服务发布，都可以成为血缘关系中的节点。向上，它关联训练所使用的数据表版本和基础模型。向下，它关联产生的 Checkpoint、模型和评估结果。
这样，既可以从一个模型向上追溯它使用的数据版本，也可以从一张数据表向下查询它影响过的模型和其他产物。百舸湖管理层还与百舸训练链路打通，百舸数据集可以直接绑定到数据湖中的表，两者支持一键互转。
5.5. 开放兼容：托管不等于锁定
百舸湖管理层提供 Lance Namespace 标准接口，将平台的元数据管理能力通过社区标准协议开放出来。已经支持 Lance Namespace 的客户端和计算引擎，只需将访问地址指向百舸湖管理层，就可以接入，不需要专门开发百舸适配代码。
同时，托管元数据并不意味着数据必须依赖平台才能读取。即使不通过元数据服务，底层数据仍然是对象存储中的标准 Lance 表。使用者拿到数据路径，就可以通过 pylance、Daft、Ray、DataFusion 等工具直接访问。
百舸托管的是数据湖的管理与治理能力，而不是封闭数据本身。使用者既能获得统一的元数据管理、自动运维和权限控制，也能保留数据格式和计算引擎选择上的开放性。
6. 百舸算子广场和数据管线：让多模态数据处理可复用、可调度
数据有了合适的格式，有了托管的元数据，接下来的问题是：怎么把几百万个原始视频变成能训练的样本？
这件事在结构化数据世界里早有成熟答案，就是 SQL 加一套批处理引擎。但在多模态场景下，传统批处理的很多假设都不再成立。
一行数据可能是几百 MB 的视频，而不是几十字节的记录。相邻两个处理步骤的单位成本可能相差三个数量级，解析一次视频元数据只需毫秒，运行一次 7B 视觉语言模型却可能需要数秒。处理过程既要 CPU 也要 GPU，而且往往要在同一条链路里交替出现。更重要的是，很多算子的主体是需要常驻显存的深度学习模型，加载一次就要几十秒。
把这样的负载硬塞进为结构化数据设计的批处理引擎里，很难解决模型加载、异构资源分配和任务管理等问题。很多团队的现状是：每个人都用 Python 脚本加多进程池自己搭一套，模型加载、失败重试、GPU 分配、断点续跑各写一遍，换个数据集又要重写一遍。任务能跑起来，但处理能力难以复用，经验也沉淀不下来。
百舸算子广场要解决的就是这件事。它把多模态数据处理中反复出现的操作，固化成一组契约统一、可以自由组合、能在百舸异构资源池上被正确调度的算子。开发者不必每次从零编写处理脚本和运行管理逻辑，可以直接组合算子广场中的算子，用百舸工作流快速搭建面向不同数据集的处理流程，并将调试通过的流程沉淀为可重复执行的数据管线。
这样，原本分散在各个团队、需要反复开发和维护的数据处理任务，就能转化为可共享、可复用的处理能力。团队可以更快完成海量原始数据的清洗、筛选、标注和模型推理，将更多精力投入数据质量优化和模型迭代，而不必反复解决底层工程问题。
6.1. 标准化算子与异构调度：让数据处理能力沉淀下来
百舸基于 Daft 打造算子广场，将算子与数据湖打通，支持直接读取和写入湖表。百舸工作流统一管理数据处理任务的生命周期，分布式 Ray Job 承接运行，百舸异构资源池完成弹性扩缩容和 CPU / GPU 混合调度，数据处理、模型推理与训练共用百舸的资源管理体系。故障恢复分为三层：任务失败后按配置重试；百舸工作流记录已完成阶段的产物，供后续步骤复用；需要步骤内部恢复的算子，再保存相应进度与 Checkpoint 状态。
目前，算子广场已经积累了 200 多个算子，覆盖视频、文本、图像、具身智能、音频、多模态和文档等不同类型的数据处理任务。
这些算子可以根据实际业务需求自由组合。开发者不必重复实现每一种数据处理能力，而是可以围绕具体任务编排处理流程，并利用平台的异构资源调度能力执行。
6.2. 数据管线：从单个算子到可重复执行的处理流程
单个算子解决的是一个具体的数据处理问题，而真实业务往往需要多个操作串联起来。例如，一批原始视频需要经过场景切分、关键帧提取、质量筛选、模型推理和格式转换，才能成为可供训练的数据集。
百舸工作流将这些操作组织成一条完整的处理流程（DAG）。开发者可以根据业务需求组合算子，定义各处理步骤之间的依赖关系，并将调试通过的流程沉淀下来。后续面对新的数据集时，可以复用已有管线，而不必重新编写和维护整套处理逻辑。
算子广场目前在具身智能场景积累最为深入，已经沉淀了十条数据处理管线，覆盖视觉清洗、格式转换、异构数据合并、视频 Curation 等多类典型任务。这些管线将具身智能数据准备过程中反复出现的处理逻辑沉淀下来，团队可以基于已有管线快速构建自己的数据处理流程，减少重复开发。
6.3. 与数据湖一体设计：让数据准备过程可追溯、可复现
算子广场不是一个独立于数据湖之外的数据处理工具，而是与多模态数据湖一体设计的。数据处理任务可以直接读取湖中的数据表，处理结果也可以写回数据湖，并与相应的数据版本关联起来。
每次处理的输入和输出都对应数据湖中的确定版本，后续训练可以直接消费这些版本。结合百舸数据湖血缘，平台不仅能够记录追溯多模数据表本身的版本变化和链条，还能将数据处理工作流、训练任务等关联起来。
数据准备由此不再是一个难以追溯的黑盒。一次训练使用了哪个版本的数据，这批数据经过了哪些处理，使用了哪些算子和管线，都能够沿着版本和血缘关系追溯，其中算子版本、模型权重和参数由百舸工作流记录。需要复现实验时，可以定位到当时的数据版本和处理流程。
从数据格式、元数据管理，到算子复用和管线调度，百舸多模态数据湖将数据存储、管理与加工连接起来。数据不仅能够被统一组织和长期管理，也能够在持续加工中形成可复用、可追溯的训练数据资产。
7. 案例：把人类视频变成可持续迭代的训练数据
具身智能模型的训练离不开大量真实世界的操作数据，但依赖机器人进行真机采集，不仅成本较高，数据获取效率也受到硬件和场地条件的限制。能否利用人类日常操作视频，为机器人训练提供新的数据来源？
一家具身智能客户正在探索这条路径。通过第一视角相机记录人的操作过程，例如一个人拿起杯子并将它放到盘子里，视频中包含了操作过程、手部运动和任务意图。如果能够从视频中还原手部的三维运动，再经过动作解算、轨迹处理和格式转换，把它变成机器人能够使用的动作数据，人类视频就有机会成为 VLA（视觉语言动作）模型的训练样本。在该项目中，人类视频的采集成本估计比真机采集低一到两个数量级。
但从原始视频到机器人训练数据，并不是简单的格式转换。团队手上是几十 TB 分散在不同采集批次中的视频文件，要串联起一条包含八个环节的处理链路：场景切分、相机标定、人体姿态估计、三维手部重建、动作解算、轨迹平滑、原子动作切分和格式导出。其中三个环节需要调用 GPU 上的深度学习模型。
更麻烦的是，这条链路并不是开发一次就不再变化。随着模型后端和处理参数不断调整，手部重建、轨迹平滑等环节的结果也会跟着变。每次处理的输入和输出怎么管理，某次训练用的到底是哪一批数据、哪一版处理结果，最终数据集能不能直接交给训练任务，这些问题决定了整条数据生产流程跑不跑得起来。
百舸多模态数据湖把这条链路接成了一条完整的数据生产流程。
这家客户的研发团队先把原始视频按采集批次上传到对象存储 BOS，建一张 Lance 数据表。每行对应一个视频素材，视频本体作为 Blob 大对象列存储，采集批次、拍摄时间、场地、标注人和任务描述作为关联字段，一行就是一条完整的数据记录，不必再把视频、元信息和标注分散在几个系统里靠文件名对应。数据表注册到百舸湖管理层的命名空间后获得稳定标识，表的空间占用、数据行数和字段结构由平台自动采集，团队在百舸控制台上直接就能看到，不需要自己维护一份台账。训练和加工要频繁读取的数据，可以按需加载到并行文件存储 PFS。
随后，团队在百舸工作流里把八个环节编排成一条 DAG，每个节点直接调用百舸算子广场中的算子，不必自己实现模型加载、失败重试和 GPU 分配。姿态、手部轨迹这类保持行粒度的结果，以新增列的方式写回素材表。场景切分、原子动作切分这些会改变行粒度的环节，产出写入新的片段表，并保留源素材 ID 与时间区间的映射，随时可以追回原视频。
-
新增特征列，不必重写几十 TB 的原始视频（Lance）。 姿态估计、手部重建这些环节算完之后，结果作为新列追加到各个 Fragment 上，原始视频列原样不动。计算时仍然要读视频，但保存结果时不会再复制一份。整条管线跑完，磁盘上多出来的主要是特征数据和片段产物。
-
某一步出了问题，从这一步重跑，不用回到原始视频（Lance）。 每一步写入都会形成新的表版本，团队可以按版本单独检查各步骤的产出，发现问题就回到它之前的版本接着跑。百舸工作流同时记录每一步用的算子版本、模型权重和参数，模型后端或处理参数一变，团队能分清哪批数据是哪一版加工出来的。
-
不用安排人盯着小文件和历史版本（百舸湖管理层）。 管线长期运行会不断产生新文件和历史版本，小文件变多会拖慢训练读取，旧版本堆积会占住存储。团队只需为数据表配置一次表自治策略，合并和清理由平台执行，训练任务和派生数据仍在引用的版本与文件会被保护下来。
-
导出即可训练，不用再写一层转换脚本（百舸工作流）。 管线产出的数据直接是 Lance 格式的 LeRobot 数据集，可以交给训练任务消费，也可用于遥操作与策略回放，以及按原子动作边界做轨迹对齐与成功率评测。百舸工作流记录导出配置与加工版本的关联，最终训练数据能追溯到原始素材和各阶段结果
-
换一个后端，能说清楚新旧结果差在哪（百舸数据血缘）。百舸血缘把各阶段产出与湖表版本关联起来，训练作业记录实际消费的数据版本与训练配置。更换手部重建后端或调整平滑窗口之后，团队可以直接比较新旧阶段结果，并沿依赖关系只重跑受影响的下游步骤，不必从原始视频重新处理一遍。
对这家客户来说，百舸多模态数据湖把素材、加工结果和训练输入连接成一条可追溯的链路。模型与参数每调整一次，团队都可以复用已有素材和阶段产物，只重新生成受影响的数据，并查清每次实验用的是哪批数据、经过了哪些处理。
