具身智能数据平台架构：开源与自研的边界与落地实践

我见过不少具身智能团队第一波 Demo 都在机械臂、模型架构、仿真环境上卷等到数据攒了几万条才发现真正卡住迭代速度的不是模型而是那堆散落在各台机器上的 ROS Bag、MP4、JSON 标注文件。具身智能的数据平台架构说起来简单做起来全是细节哪些层可以直接用开源哪些层必须自己写第一行代码到底该落在哪一层很多人根本想不清楚就直接上了 Kubernetes最后两个月过去数据还是靠 U 盘拷。这篇文章写给正在做具身智能算法、机器人数据闭环或者想给团队搭一套数据基础设施的工程师和技术负责人。我会从数据平台要解决的核心问题出发把开源和自研的边界划清楚给出按层拆分的选型逻辑再讲我认为最合理的实施顺序以及我在真机采集和训练回流过程中踩过的坑。全程不扯玄乎的概念就讲怎么落地。1. 动工之前先回答数据平台究竟解决了谁的什么问题很多团队把数据平台当成数据集管理工具来规划这是一个很贵的误解。具身智能的数据平台本质上是一套让真实采集、仿真生成、标注清洗、模型训练、仿真评估、困难样本回流持续运转的管道系统。它不是给程序员看文件列表的地方而是给算法工程师供给高质量训练数据、给数据标注团队提供协同流水线、给技术负责人提供数据资产可见性的业务系统。1.1 数据来源和形态的多样性是第一个复杂度来源具身智能的数据来源远比纯 CV 或 NLP 复杂。一次机械臂插拔插头的操作可能同时产生 RGB 视频、深度图、点云、关节角度、关节力矩、力传感器读数、IMU 数据外加一条自然语言指令或者遥操作员的操作记录。这些数据的时间轴必须对齐到毫秒级空间坐标系必须统一缺失帧和延迟必须能被检测出来。更麻烦的是这些数据来源的采样率各不相同——相机可能 30HzIMU 可能 200Hz机械臂控制周期可能 500Hz存储时如果不做统一的时间基准后面做模型训练时要对齐数据成本会翻好几倍。除了真机采集仿真环境也是重要的数据来源。Isaac Sim、MuJoCo、Genesis 生成的带完美标注的合成数据可以和真实数据混合训练但仿真数据和真实数据的分布差异、域随机化参数、仿真场景的版本信息都需要作为元数据记录。如果平台设计时没有把这些异构来源当成一等公民后面做数据混合比、域迁移分析时就会发现信息缺失只能回炉补采集。1.2 数据平台的价值来自闭环而不是存储容量判断数据平台做得好不好的标准不是存了多少 T而是模型迭代一个版本需要多久拿到一份合格数据集。这里必须引入数据飞轮的概念真机和仿真采集的数据经过清洗和标注后进入训练集模型在仿真器里或真机上评估发现失败案例再把失败案例重采样、回流到标注队列补充采集或仿真生成形成新一批训练数据。这个闭环越快模型进步越快。很多团队做数据平台时只盯着存储和标注忽略了评估结果反馈到数据筛选这一环导致数据平台成了单向管道越存越多但模型一直用同一批老数据。我的建议是在设计第一版架构时哪怕评估回流的逻辑还没有落地也要在数据结构里留出评估任务 ID模型版本 ID困难样本标记这些字段否则后期加会非常痛苦。1.3 别把团队边界和技术边界混为一谈自研和开源的取舍首先要看团队人员结构。一个 8 人算法团队硬去自研微服务数据平台结果就是数据工程师还没招到算法迭代已经被基础设施拖死了。反过来一个几十人的数据团队如果为了省事全盘照搬通用开源平台不做场景语义抽象就会发现开源平台解决不了具体问题还得二次开发。所以开篇第一件事是冷静评估团队的工程资源。数据平台是典型的投入周期长、见效慢、但一旦缺失所有下游都痛苦的基础设施它需要有人持续维护不是搭完就能跑。拼多多式省钱的团队可以考虑多用开源、少自研、外包标注预算充裕、数据规模大到必须深度定制的团队才有资格谈自研 PaaS。这个判断不做后面所有选型都是空中楼阁。2. 开源与自研的分界线用一张表管住造轮子的手我的选型原则很简单能被社区广泛验证的开源组件绝对不自研只有业务语义强、开源组件覆盖不到的地方才值得投入自研。具体到具身智能数据平台可以按照以下几个关键域来划分。2.1 能直接使用开源组件的环节环节推荐开源方案用途说明数据采集与报文封装ROS 2 / MCAP 格式统一多传感器数据的时间戳和序列化MCAP 比传统 ROS Bag 更适合大数据流原始数据存储MinIO / Ceph / AWS S3 协议兼容存储存放原始 MCAP、视频、点云等大文件对象元数据管理PostgreSQL / MongoDB存任务、场景、传感器参数、时间范围、标签不存二进制数据本身向量检索Milvus / Qdrant / pgvector对视频片段和动作轨迹做语义向量检索支持自然语言找数据数据标注Label Studio / CVAT / SAM2D 框、分割、分类标注3D 点云可配合 Open3D 工具链数据版本与血缘DVC / LakeFS / Delta Lake数据集版本控制、回滚、多版本并存工作流调度Apache Airflow / Argo Workflows / Prefect定时或事件驱动的采集、清洗、标注任务编排训练数据读取PyTorch WebDataset / FFCV高吞吐、流式读取数据集避免把所有数据加载进内存这些组件不是选完就完事关键在于是否愿意花时间读源码。比如 MCAP 格式本身很简洁但很多团队只是会用 ros2 bag 的命令行去录包遇到需要自定义 schema 压缩、按 channel 切分数据时就不会了。我的经验是凡是列在开源选型表里的组件团队里至少要有一人读过它的核心源码否则出了问题就是黑盒。2.2 必须自研的四个地方第一是场景语义和任务定义。开源工具不懂什么是抓取红色杯子抽屉归位双机械臂协作这些任务 schema、场景描述、动作轨迹的语义层级必须由团队自己设计。一套灵活的 scene/task/action 三级标注结构是具身智能数据平台区别于通用 CV 平台的灵魂。第二是多传感器标定和时间同步的流程编排。标定算法本身有现成的比如相机内参标定用棋盘格相机到机械臂的手眼标定用 OpenCV但采集标定数据 → 计算外参 → 写入设备配置 → 验证精度的完整流程以及标定失效检测需要自己写管道。第三是数据血缘与闭环追踪。模型训练用的是哪个数据集版本这批数据来自哪些采集任务、哪些传感器坏了、哪些标注员做的标注评估后发现模型失败是否回溯到了具体数据样本。这种数据血缘关系通用数据目录工具只能覆盖部分场景还得结合具身领域的数据结构自研。第四是自动化数据质量规则。比如丢帧率超过阈值就告警、机械臂关节数据跳变异常、时间戳单调性校验、传感器外参是否正常。这些规则每个团队都不一样没有开源方案能直接套用。2.3 判断自研投入的量化标准我习惯用四层标准来卡自研边界能用 10 行脚本解决的不封装成框架能用 100 行代码接进开源组件的不引入额外依赖能用 1000 行代码调好的开源项目不买商业产品需要写 10000 行以上领域代码时才值得严肃评估自研一个小平台。很多团队的失败在于数据量只有几百 G就开始设计微服务架构自研了采集服务、元数据服务、标注服务、API 网关一搞就是半年。实际上第一版用一个单体 Python 服务加几张 PostgreSQL 表就能跑通等数据量和团队规模上来了再按需拆服务这个节奏才是对的。3. 分层架构拆解每一层选型的底层逻辑具身智能数据平台从下往上大致可以分为采集接入层、数据存储层、数据处理与标注层、数据消费与闭环层。每一层都有它的核心矛盾选型和自研都围绕核心矛盾展开。3.1 采集接入层关键是时间同步与完整性问题采集接入层的职责是把真机或仿真器产生的一堆异构数据流整理成带有统一时间戳和元数据的标准化文件。它最核心的矛盾不是数据录下来而是录下来的数据能不能用于训练。比如同时开 3 个相机、1 个力传感器和机械臂控制器的数据如果某个相机驱动启动慢了几秒又或者系统时钟发生跳变录出来的数据在时间轴上就是错位的。推荐的做法是真机采集使用 ROS 2 生态录包格式选 MCAP。MCAP 的好处是支持 stream 写入、index 优化而且通道 schema 版本化管理做得好非常适合长时间录包。对于不走 ROS 的传感器比如某些工业相机 SDK可以写一个适配层把数据统一封装成带单调时钟时间戳的通道。仿真数据则尽量直接导出为与真机相同的 MCAP 格式保持后续链路一致。这层需要自研的是采集启动编排和完整性检查。包括多传感器预热检查、数据头尾对齐、录包前检查磁盘空间、录包后校验文件大小和通道完整性以及把采集过程写成可复现的 recipe 配置这样每次采集的参数都有据可查。严格来说这些不是高深技术但好的采集编排能节省大量清洗时间。3.2 数据存储层格式选型决定你未来三年的数据管理效率存储层有两个维度原始二进制文件存在对象存储里元数据存在关系型数据库里。很多人把两件事混在一起比如把所有标注结果塞进 MongoDB 的一个超大 JSON后面做检索时性能极差。文件格式选型是这层最重要的决定。我对比过几种常用格式格式优点缺点适用场景MCAP流式写入、支持多通道、索引高效、压缩可选生态较新老工具兼容性弱真机多传感器采集首选ROS 1/2 Bag社区使用广泛工具链成熟大数据量读写慢跨版本兼容差老项目维护、复用现成工具HDF5适合多维数值数据训练读入方便多路流式写入困难损坏恢复差纯算法实验、回放分析普通视频/JPEG直观、便于人类查看丢失传感器时间戳和高频数据仅作辅助可视化我个人推荐把 MCAP 作为原始数据的标准格式因为它的通道化结构天然适配多传感器而且能存储任意类型的附件比如机械臂状态、自然语言指令等。不过要注意MCAP 本质上是一种封装格式不是压缩算法录包时要用合理的压缩配置比如视觉压缩成 H.264 或 HEVC点云用 zstd才能控制存储成本。元数据数据库用 PostgreSQL 就够了。关键设计思路是元数据表记录的是数据文件的基本信息比如任务 ID、采集时间、传感器列表、文件路径、文件大小、文件 checksum、状态标记。不要把点云内容或图像像素存进去那是对象存储的活儿。为了让元数据表可扩展可以预留一个 JSONB 字段存自定义字段配合 GIN 索引做查询。这个设计既灵活又不失性能。向量检索用于语义查询比如找出所有机械臂抓取马克杯的片段。做法是把视频片段或轨迹用多模态模型抽成 embedding存入 Milvus。需要特别提醒的是embedding 抽取的模型版本会直接影响检索效果元数据里必须记录 embedding model 的版本否则换了模型后新旧特征混在一起检索结果会变得不可复现。3.3 数据处理与标注层开源工具负责标注自研负责流程数据处理层包含清洗、对齐、去重、标注、质检、版本化。这里最大的误解是以为安装了 Label Studio 就搭好了标注系统。实际上开源标注工具只是画框画点的工具壳真正的标注流程管理——任务发布、工作量均衡、一致性评测、抽检仲裁、数据回流——全部需要自研。具身智能与普通 CV 标注最大的区别在于动作轨迹标注。想象一下标注机械臂把螺丝拧进去这个操作标的不只是视频里的一帧而是一整段时间序列上的关节角度、力矩、夹爪状态和对应的指令。逐帧标注的成本是灾难级的。所以现在的常见做法是用遥操作的专家轨迹作为近似 ground truth通过剪枝、平滑、分段后生成动作标注人工只负责修正关键节点。这个半自动标注管道是具身智能数据平台最有价值、也最需要自研的部分。清洗逻辑上我建议把规则和代码分离。写一个数据质量规则引擎用 YAML 定义规则比如通道 A 丢帧率不能超过 1%时间戳单调递增关节速度不能超过物理极限平台定期跑规则把异常样本标记出来。这样数据清洗不只依赖工程师临时写脚本可以让标注员和算法工程师共同维护规则库。3.4 数据消费与闭环层给算法工程师提供的不是文件是数据 API数据消费层直接决定算法工程师的效率。很多平台做成了网盘 下载链接算法工程师要写一堆脚本自己拉数据、合并标注、切分训练集这完全错了。好的平台应该提供一套数据集 API算法工程师输入场景 抓取物体 马克杯时间范围 最近一个月排除状态 低质量就能拿到一个迭代器流式读取训练样本而不是把数据拷贝到本地。这里可以用 PyTorch WebDataset 或 FFCV 实现高吞吐流式读取原始文件放对象存储元数据和索引放数据库。切片时不要把所有小文件打散成百万个碎片而是先物化成 shard 文件一个 shard 包含若干个训练样本。数据集的每个版本包括样本清单、预处理参数、生成脚本的哈希值都要可追溯。闭环层则是把模型评估结果写回数据平台。仿真器或真机评估得到失败样本后平台自动创建一条数据补充请求回到采集队列或者标注队列。这种 Negative Mining 机制比每次都从头随机采数据高效得多。架构上可以把评估结果存成一个独立的表与数据集版本关联推荐给下游训练形成正向循环。4. 优先级排序为什么第一个迭代只做查得到不做存得好很多团队搭数据平台第一个冲动是搭一个巨大的分布式存储集群买服务器装 Hadoop再把所有数据导入。这个决策几乎注定会烂尾。正确的优先级是先把数据能查到、能取到打通在跑通第一个闭环前不要追求存储系统的完美。4.1 第一步用一周时间定义数据 schema 和采集规范在写任何代码之前先定义元数据 schema。这项工作看起来不起眼但直接决定后续所有工具的互通性。至少要有这几张表采集任务表task_id、robot型号、场景、采集员、开始结束时间、传感器列表、数据文件表file_id、task_id、channel、文件路径、时长、文件大小、checksum、状态、样本标注表task_id、时间戳范围、动作类别、指令文本、物体列表、标注员、质检状态。这个 schema 设计得越稳定后面的接缝就越少。注意字段命名和枚举值要统一比如动作类别用 snake_case 还是中文标签必须在第一天定下来。元数据是给程序读的不是给人看的建议全部用英文字段和枚举值展示层再做国际化。4.2 第二步两到三周打通最小数据管道第一版系统不需要微服务不需要 K8s一个 Python 单体服务加 PostgreSQL 就够了。采集端按照 schema 录制 MCAP 文件上传到 MinIO然后在 PostgreSQL 注册一条元数据记录。再写一个简单的 Web 界面能按任务列表、按时间范围、按标签筛选文件并且提供数据集导出 API输出 file list 给 PyTorch DataLoader。这个小系统可能写得比较糙但它能帮团队回答三个关键问题采集的数据能不能稳定落到存储元数据建模是否满足查询需求算法工程师拿到数据后能不能顺利开训这三件事没跑通后面一切优化都无从谈起。4.3 第三步加上自动质量评估和人工标注最小管道打通后就可以把数据质量规则加进去了。对每条 MCAP 文件自动跑质量检查比如时间戳单调性、丢帧率、通道完整性质量不达标的直接标记为待补充采集不进入标注队列。然后接入 Label Studio把标注结果回填到 PostgreSQL生成可训练的数据集版本。这里的核心目标是让数据平台第一次产生业务价值算法工程师不再需要手动整理文件标注团队有了协同工作的界面。按我的经验这个阶段大约需要六到八周一个 3 到 5 人的小团队完全可以完成。做完这一步再考虑向量检索、数据血缘、多模态自动标注这些进阶功能。4.4 数据版本化为什么可以晚点再上数据版本化确实是好功能但第一版就做容易陷入工具链泥潭。比如接 DVC 需要给数据文件加 remote、接 Git 还要搞 CI 流程对一个小团队来说反而增加负担。建议第一版用最简单的方式每次生成训练集时把样本清单和预处理脚本的 commit hash 记录到一张 dataset_version 表里。这已经能保证可复现性了。等团队真的需要对比多版数据对模型效果的影响再引入 DVC 或 LakeFS 不迟。5. 预算与人力怎么算从模型迭代反推存储和标注规模数据平台的资源规划不能拍脑袋。正确的做法是先想清楚模型要达到目标需要多少有效训练样本再反推采集规模、存储容量、标注人力和带宽需求。5.1 从训练目标倒推存储容量假设你的目标是让机械臂学会 10 种基础操作每种操作需要 5000 条有效演示总共 5 万条演示样本。每条演示时长平均 10 秒真机遥操作采集每秒产生大约 50MB 的数据3 路 1080P 视频 高频关节数据 点云一条就是 500MB5 万条就是 25TB加上压缩率按 3:1 计算实际原始存储约 8TB 到 10TB。如果做版本化再保留 3 个版本就是 30TB 左右。这个量级用一台高配服务器配几块大容量 NVMe 加对象存储软件MinIO就能扛住完全不需要上真正的分布式存储集群。真正需要上 Ceph 或者云上对象存储的时候是数据量超过几百 TB而且团队有专门的存储运维人力。很多团队在 10TB 级别就上了 5 节点 Ceph纯粹是浪费钱。5.2 标注成本是最容易低估的预算项5000 条演示的标注成本取决于标注内容的复杂度。如果只是检查时间线、打动作标签、质量筛选每条可能只需要 3 到 5 分钟如果要逐帧精修轨迹、语义分割点云每条可能几十分钟。按平均每条 15 分钟算5 万条就是 1.25 万小时一个人每天 8 小时需要 1500 人天等于 7 个全职标注员干 7 个多月。这就是为什么前面说半自动标注管道必须自研——用遥操作专家轨迹做预标注能把人工成本降到原来的五分之一甚至十分之一。预算规划上建议按自动化程度分三档纯人工标注、半自动预标注加人工修正、全自动/弱监督方案。第一版通常用第二档。人员上小团队可以先走外包加内部抽检但要有人专门维护标注规范annotation guideline否则标注一致性会失控。5.3 磁盘和带宽的隐藏消费点对象存储里存的不只是原始 MCAP还有标注导出的中间文件、可视化用的抽帧缩略图、仿真生成的合成数据、模型评估回放的日志。这些衍生数据往往比原始数据还占空间。建议在第一天就把存储路径按数据类型统一规划raw/、preprocessed/、annotated/、eval/然后对不同目录设置不同的生命周期策略比如评估日志保留 30 天原始数据保底一年预处理数据可以每次数据集生成时重新算没必要长期保留。带宽也要提前留。算法工程师训练时需要并发读取几个 TB 数据如果存储服务器的网络只有千兆一个训练任务就能把带宽吃满。第一版至少上 25GbE 内网服务器本地 NVMe 缓存也建议保留训练集热数据副本避免每次迭代都从 MinIO 拉全量数据。6. 落地过程中最容易翻车的四个细节架构选型和技术栈都定好了真正让人头疼的往往是细节。我在这部分把实操中踩过的坑集中列出来按重要性排序。6.1 时间同步多传感器数据的隐形杀手数据错位最隐蔽的来源就是时间同步。不同传感器设备都会有自己的时钟漂移如果各设备不等时基录出来的数据即使名义上都是系统时间戳实际采样时刻也可能偏了几十毫秒。对于机械臂控制这种毫秒级敏感的操作几十毫秒的偏差足以让视觉和力觉数据对不上。解决思路分三层第一层是硬件同步优先支持 PTP 或外部触发线同步的传感器这样各设备使用同一时基精度高第二层是在软件里做时间同步校正比如用 ROS 2 的 time synchronizer 组件对齐时间戳同时记录每个传感器的时钟漂移量第三层是录包时不管三七二十一每个通道加一个精确到纳秒的采集时戳后面通过重采样对齐。第一版不要求做到完美同步但必须把同步状态记录进元数据让算法工程师知道哪些样本是硬件同步的、哪些是软件对齐的避免把有问题的数据混入训练。6.2 文件不可变metadata 可更新对象存储上的原始数据文件应该当成不可变对象来处理别在原文件上做修改。文件命名用 UUID 而不是语义化命名比如 task_20250401_xxx 这种看似友好的命名很容易因为重复采集同名文件而覆盖。正确做法是文件 UUID 防重所有语义信息都放元数据表。这样对象存储是一堆不可变数据块元数据层负责描述它们任何修改都是新增版本。注意数据完整性校验不能省。上传完成后计算 checksum 存到元数据表定期巡检比对对象存储上的文件 checksum 是否一致。我遇到过云存储偶发静默损坏的情况如果不用 checksum 校验坏数据会悄悄进入训练集追查起来非常痛苦。6.3 标注工具不等于标注流程标注工具解决的问题只是把标注结果画出来而标注流程是从任务发布到结果验收的完整闭环。除非团队只有一个人标注否则必须有一个最小流程任务分行、标注员认领、完成提交、随机抽检、仲裁冲突、回流修正。具身智能的轨迹标注还有一个特殊性很多标注动作无法逐帧独立完成必须看连续上下文。标注员很容易因为疲劳产生前后标准不一致。我建议在流程里加入一致性检查环节挑选 5% 的任务做重复标注计算标注间一致性指标一旦低于阈值就退回全部任务。这个机制看上去增加了 5% 的额外工作量但长期看能避免整个数据集质量崩塌。6.4 先定义删除策略再扩容数据不是越多越好。具身智能数据里大量存在高度重复的相似场景如果全量保存存储成本膨胀检索效率也会下降。建议在采集层就做初步筛选自动检测相似度过高的片段并标记为冗余候选人工定期确认后删除或归档。更重要的是一开始就设计数据生命周期策略。原始数据、预处理数据、标注中间文件、评估日志分别设置保留时间。比如原始数据永远保留除非质量极差预处理数据在数据集重新生成后可覆盖评估日志保留 90 天。没有删除策略的存储三个月就会变成一片垃圾海。7. 三种团队画像的选型路线图最后按团队现状给三套直接可用的选型路线图你可以对号入座。7.1 十人以下的算法团队无专职数据工程师这种团队的目标是快速跑通数据闭环架构尽量简单。推荐技术栈ROS 2 MCAP 作为采集前端MinIO 单机或云对象存储存原始数据PostgreSQL 存元数据Label Studio 做标注Python FastAPI 写一个一百行左右的数据集注册与导出 API训练侧直接用 PyTorch DataLoader 加 WebDataset 流式读取。这个方案不需要微服务也不需要消息队列。任务状态变更用 PostgreSQL 表加状态机字段就够了。如果团队连后端工程师都没有先别做 Web 界面写一个交互式 Jupyter Notebook 封装数据查询算法工程师也能用。7.2 有三四个人但懂数据工程缺具身领域经验的团队这类团队容易犯一个错误把互联网日志分析的大数据体系直接搬过来上 Kafka、Spark、Hadoop最后发现这些组件跟传感器数据流的契合度很差。我建议适当收敛消息队列只在需要实时告警时引入而且优先考虑轻量级的 RabbitMQ 或 Redis Stream不要一上来就 Kafka。存储底座可以考虑 Iceberg 作为表格式原始传感器数据还是存 MinIO元数据用 Iceberg 的 manifest 管理。这个组合能保留数据湖的扩展性又不至于把系统搞得过于复杂。这类团队最大的优势是工程能力强自研采集适配器、清洗管道、标注流程管理都能做最大的盲区是传感器领域知识比如时间同步、坐标变换、标定。建议在团队里引入一名有机器人背景的工程师或者聘请顾问专门负责数据语义设计。7.3 五十人以上、有专门数据平台组的大团队当团队规模足够大数据平台就需要上升到内部产品级别。这时可以考虑 Kubernetes 加内部开发者平台的方式提供自助式数据集发布和监控面板。底层存储可以用 Ceph 或云对象存储元数据层可以拆成多个服务比如采集管理服务、标注流程服务、数据集 API 服务、质量监控服务服务间通过 HTTP 或 gRPC 通信。但即使是大团队我仍然不建议全部自研组件。数据版本化用 LakeFS向量检索用 Milvus工作流编排用 Argo Workflows这些都可以省下大量人力。自研的部分集中在三个领域传感器接入协议、场景语义建模、数据闭环策略。这三样才是核心竞争力和护城河。最后再分享一下我的个人感受。数据平台这种东西最大的投入不是服务器和云费用而是持续的治理成本。你永远在跟无效数据、格式漂移、标注不一致、血缘断裂这些看不见的敌人斗争。如果让我重新搭一遍我会先用一张纸把一条数据从真机传感器到模型 loss的路径完整画出来再决定用什么工具。画不出这张图之前不要碰任何代码。