具身智能的数据地基:从传感器带宽到湖仓、清洗、评测与回流闭环

具身智能真正的瓶颈,早已不在模型架构——VLA、Diffusion Policy、世界模型这些路线正在快速收敛——而在于数据基础设施:怎么把物理世界的交互数据高效地采上来、存下来、洗出来、训得动,再让推理结果回流形成飞轮。

国地中心在建设人形机器人训练场时就把问题归结为四点:PB 级多模态数据存不下、真实采集成本高昂、视觉/触觉/力觉/位姿格式各异治理困难、跨域流转受限;中国信通院的测算更直接:若要支撑 55B 参数级具身基座模型,需要约 2.12 万台机器人以 8Hz 控制频率连续工作一年,才能产出千万小时级有效数据,而当前全球可用高质量真实数据仅数十万至百万小时级。

这意味着,那套我们熟悉的大数据技术栈——数据湖表格式、Hadoop/Spark 生态、OLAP 引擎、gRPC/MQTT/WebRTC 通信协议——在具身智能场景里不是"能用",而是刚需。本文尝试把这条链路完整拆开:从一台机器人的传感器带宽算起,到湖仓选型、清洗管线、OLAP 评测、推理回流的闭环架构。

关联阅读:本文是数据基础设施视角的展开;VLA 训练栈与模型格式见 从 LLM Infra 到具身智能 Infra 与 为什么 VLA 训练选 FSDP 而不是 Megatron。

---

一、先算一笔账:为什么具身数据必须上湖仓

具身智能和 LLM 在数据侧有一个本质区别:互联网上没有物理交互数据可爬。文本和图文可以被动积累,而机器人需要的视觉、动作、关节扭矩、力触觉等多模态交互数据,此前从未被系统性记录,只能从零逐条生产。谷歌组织 16 人团队、花 17 个月、投入上千万美元,也只采集了 23 万条真机轨迹——这个量级连 LLM 预训练语料的零头都不到。

不妨做一次具身智能版的"数据规模测算"。以一台典型人形机器人为例:

• 视觉:头部 RGB-D × 2 + 腕部相机 × 2。每路 1080p@30fps H.264 压缩后约 4 Mbps,深度流压缩后约 15 Mbps,合计约 45 Mbps;
• 本体感知:以 40 个自由度计,每个关节 1kHz 上报位置/速度/力矩(3×float64 ≈ 24B),加上六维力传感器、IMU、触觉阵列,结构化数据流约 10-15 Mbps;
• 语音与其他:约 5 Mbps。

单台机器人原始数据率约 60-65 Mbps ≈ 8 MB/s。每天有效采集 8 小时就是 230 GB,一台机器人年采集 300 天约 70 TB(归档压缩后减半)。百台规模的训练场,一年就是 3-7 PB——这和国地中心"每次训练产生 PB 级多模态数据"的判断完全吻合。

这个量级带来三个工程硬约束:

1. 存得下:对象存储(S3/OSS/HDFS)是唯一经济的选择,但裸文件没有事务、没有版本、没有 schema 管理,很快会变成"数据沼泽";
2. 找得到:百万条轨迹里筛选"失败案例"“特定物体类别”"特定光照条件"的子集,需要元数据层的强过滤能力;
3. 训得动:训练框架要能流式读取任意 episode 切片,而不是每次全量拷贝。

这三点正是数据湖表格式(Iceberg/Delta Lake) 的用武之地。

---

二、技术选型总览:一张表看清全生命周期

在展开每个环节之前,先用一张表建立全局图景:

数据生命周期阶段	核心挑战	技术选型	选型理由
设备遥测上报	百台集群、低带宽/不稳定网络	MQTT(QoS 分级)	轻量发布/订阅,QoS 1/2 保证状态与告警可靠传输
服务间编排与策略下发	毫秒级控制指令、观测上传	gRPC 双向流	Protobuf 序列化 + HTTP/2 多路复用,LeRobot 多机通信即此方案
遥操作视频回传	<300ms 端到端延迟、NAT 穿透	WebRTC	内建 ICE/STUN/TURN,实测机器人监控延迟可压至 142ms
多模态数据落湖	PB 级、Schema 频繁演进、多引擎读写	Iceberg(主)/ Delta	元数据分层避免单点瓶颈,Spark/Flink/Trino 全平台支持
清洗与特征工程	亿级视频帧抽帧、去重、跨本体对齐	Spark + Daft	Daft 将 Image/Video/Tensor 视为一等公民,可嵌入大模型推理
训练数据集管理	Episode 级版本、流式读取	Iceberg + LeRobotDataset v3.0	分块 Episode 格式支撑 OXE 量级(>400GB)数据集
评测与报表分析	多表 Join、成功率统计、回归对比	Doris / StarRocks	Merge-on-Write 支持高频更新,复杂 Join 能力强
遥测明细监控	单表百亿级行为日志、高吞吐写入	ClickHouse	单机吞吐与压缩比优势,适合追加式日志分析
推理回流闭环	集群策略下发、真机 Rollout、数据筛选	gRPC + Kafka + Flink	星海图 G-Fleet 即此形态的完整实现

一个常见的认知误区是"湖仓 = 更大的数据库"。湖仓在具身场景要解决的不是 OLTP,而是让 PB 级多模态数据"存得下、找得到、训得动"——事务保证的是数据集版本可回溯(训练结果复现),快照隔离保证的是清洗任务与训练任务并发不冲突,schema 演进保证的是新增传感器通道不需要重写历史数据。

---

三、场景一:真机数据采集——三种协议各守一道关

具身智能的数据采集现场,三种通信协议不是互相替代,而是分工明确:

MQTT:设备遥测的毛细血管

训练场里几百台机器人的心跳、电量、关节温度、异常告警,走 MQTT 再合适不过。关键在 QoS 分级的使用策略:高频遥测(关节温度、电量)用 QoS 0,丢一帧无所谓,省流量;安全告警、急停状态同步用 QoS 1,至少送达一次;涉及计费或审计的关键事件才用 QoS 2,四次握手保证恰好一次。MQTT 的长连接机制也远比 HTTP 高效——一次 TCP 建连后异步收发,不用每条消息都重传头部。

gRPC:服务间编排的主动脉

LeRobot 的多机器人分布式控制系统就是用 gRPC 构建的:AsyncInference 服务处理观测数据上传和动作指令下发,LearnerService 负责模型参数同步和训练数据收集,通过 Protobuf 定义的消息状态机(TRANSFER_BEGIN → MIDDLE → END)管理大文件分片传输。Isaac Sim 的远程控制同样采用 gRPC——仿真端作为服务器流式推送机器人状态,客户端下发控制指令,sub_state 返回 stream JointState 实现订阅式状态同步。相比 ROS 的 DDS 广播分发,gRPC 的点对点模型天然适合跨网段、跨公网的分布式部署。

WebRTC:遥操作临场感的生命线

遥操作是当前真机数据采集的主流方式,而它的体验瓶颈完全在视频延迟。Pi0 机器人的实测数据很说明问题:MJPEG 流延迟 1.8 秒、RTMP+VLC 延迟 1.2 秒,而 WebRTC 原生方案延迟 142ms,接近人类视觉-运动反应的生理极限(约 100-150ms)。Phantom Bridge 的作者在选型时说得透彻:如果用 DDS 自己实现 NAT 穿透、媒体编码、浏览器解码,最后很可能是在重新发明 WebRTC——浏览器天然支持 WebRTC 硬件加速解码,这是 DDS 生态不具备的。

通信协议选型的本质,就是 WebRTC 保遥操作临场感、gRPC 保服务间毫秒级编排、MQTT 保百台集群设备接入——三者缺一不可。

---

四、场景二:数据湖存储与训练数据集管理

采集上来的多模态数据如何组织?这里有两条并行演进的路线,它们其实是互补关系而非竞争。

LeRobotDataset v3.0 定义了机器人轨迹的逻辑格式:分块式 Episode 结构(每个 episode 一个视频文件 + 一个 Parquet 元数据文件),支持流式读取,专门面向 OXE(Open X-Embodiment)这种 >400GB 量级的数据集做了效率优化。OXE 本身则是 34 个实验室、60 个数据集、超过 100 万条真实轨迹、覆盖 22 种机器人本体的统一格式尝试,是 RT-X/OpenVLA/Octo/π0 等模型的训练底座。

Iceberg/Delta 提供的是物理管理层:ACID 事务(数据集版本可回溯)、快照隔离(清洗与训练并发)、隐藏分区与分区演进(按机器人 ID / 任务类型 / 采集日期分区,新增分区不影响旧查询)、时间旅行(对比两周前后的模型在相同数据切片上的表现)。LeRobot 格式的 Parquet 文件与视频文件完全可以注册为 Iceberg 表来管理,逻辑格式与物理管理层各司其职。

选型上:

• 如果计算引擎以 Spark 为主且深度绑定 Databricks,Delta Lake 集成成本最低;
• 如果是 Flink 写入 + Trino/StarRocks 查询的多引擎并存——这在具身场景很常见(实时回流用 Flink,离线训练用 Spark,评测查询用 StarRocks)——Iceberg 是更中立的选择;
• Hudi 则在需要高频 Upsert 的场景(比如机器人状态表的持续更新)有优势。

---

五、场景三:Spark 清洗管线——具身智能的"脏活累活"

原始采集数据里充斥着无效内容:静止画面、模糊镜头、空抓产生的虚假触觉信号、以及遥操作特有的"缓慢机械动作"(同一任务遥操作耗时是直接操作的 3-5 倍)。清洗管线的典型步骤:

1. 视频抽帧与关键帧筛选:数千小时视频解码后是数亿张图像帧,需要分布式抽帧并过滤静止/模糊帧;
2. 跨本体数据对齐(Retargeting):动捕采集的人体数据要重映射为不同构型机械臂的动作数据,需要一个可交互、可计算的物理环境做对齐、清洗和验证;
3. 多模态时间对齐:视觉 30fps、关节状态 1kHz、力觉 100Hz,要统一到模型训练所需的控制频率;
4. 数据增广与合成:用 Seedance 等视频生成模型基于第一视角生成第三视角视频、扩展不同桌面布局与光照条件、将裸手操作泛化为不同构型机械臂数据;NVIDIA GR00T-Mimic 更激进——11 小时生成 78 万条合成轨迹,相当于 6500 小时人工演示。

这些工作负载在 Spark 上的效率差异巨大。阿里云 EMR Serverless Spark 引入的 Daft 引擎值得单独一提:它把 Image、Video、Audio、Tensor 视为 DataFrame 的一等公民类型,一行表达式即可完成分布式视频解码与帧提取;更关键的是"数据处理即 AI 推理"——通过 UDF 将通义千问等大模型直接嵌入 Pipeline,图像理解和视频描述生成与数据清洗无缝衔接。这对具身场景太重要了:用 VLM 给每一帧打标签(物体类别、场景、任务阶段)本来就是清洗的必备步骤。

---

六、场景四:OLAP 引擎在评测与监控中的分工

OLAP 选型不是比谁跑分高,而是看评测报表和遥测监控哪个先把你逼疯。具身场景里这两类负载差异极大:

评测分析(Doris/StarRocks 的主场):每次模型迭代都要跑评测——按任务类型 × 物体类别 × 场景光照 × 机器人本体多维交叉统计成功率、平均耗时、失败模式分布。这是典型的多表复杂 Join + 高频更新负载:评测结果表要不断 Merge 新数据,任务元数据表、场景配置表、机器人信息表要频繁关联。Doris 的 Unique Key Merge-on-Write 模型支持毫秒级主键点查与秒级 CDC 可见,配合 Colocate Join 和 Runtime Filter,在这种混合负载下明显稳于 ClickHouse。

遥测明细监控(ClickHouse 的主场):百台机器人 × 1kHz 关节状态 × 30 天 = 数百亿行追加式日志。查询模式相对简单(按机器人 ID + 时间范围扫描),但写入吞吐和存储成本是核心矛盾。ClickHouse 的单机吞吐与列式压缩比在这里优势明显——OpenAI 也在大量使用它做可观测性分析。

一个务实的组合是:ClickHouse 吃遥测明细,Doris/StarRocks 做评测聚合与报表,两者通过物化视图或定时 ETL 衔接。

---

七、场景五:推理服务与数据回流——闭环的最后一公里

具身智能的完整链路是"环境感知输入 → 模型理解与任务决策 → 可执行动作生成 → 硬件本体执行 → 环境实时反馈 → 有效数据回流迭代"。星海图的 G-Fleet 系统把这个闭环做到了工程化:集群级策略下发、并行真机 Rollout、真实场景数据回流、人工干预校准、分布式强化学习训练、自动评测与版本发布全流程打通。

技术上,这一层的核心是 gRPC 双向流:机器人端持续上传观测(图像 + 本体状态),推理服务端流式下发动作 chunk。LeRobot 的实现里有几个值得借鉴的细节:观测数据多层过滤(时间步去重减少 30% 计算量、帧相似性检测节省 20% 带宽)、predict_action_chunk 批量动作预测优化推理效率。回流的轨迹数据经 Kafka 缓冲后由 Flink 实时打标(成功/失败/需人工复核),写入 Iceberg 表供下一轮训练筛选。

flowchart LR
    subgraph 采集端
        A[机器人集群
视觉/力觉/关节状态] -->|MQTT QoS分级| B[设备网关]
        A -->|WebRTC <300ms| C[遥操作工作站]
    end
    subgraph 边缘/服务层
        B -->|gRPC 双向流| D[推理服务
VLA/世界模型]
        C --> D
        D -->|gRPC 动作chunk| A
    end
    subgraph 数据平台
        D -->|Kafka| E[Flink 实时打标]
        E -->|写入| F[(Iceberg 数据湖
LeRobot Episode 格式)]
        G[Spark+Daft 清洗管线
抽帧/去重/Retargeting/合成增广] --> F
        F -->|流式读取| H[训练集群
GR00T/OpenVLA/π0]
        F -->|外表查询| I[Doris/StarRocks
评测报表]
        B -->|遥测明细| J[ClickHouse
监控分析]
    end
    H -->|新模型| D

---

八、落地建议与几点思考

起步阶段不必全套上齐。如果团队只有几台机器人,先用 LeRobot 格式 + 对象存储 + 单机 Spark 就能跑通闭环;等数据量过百 TB、或多引擎并发读写成为瓶颈时,再引入 Iceberg。OLAP 引擎同理:初期一个 Doris 就够,等遥测明细把磁盘吃爆了再拆 ClickHouse。

协议选型要克制。ROS2/DDS 在机器人内部通信(局域网、类型化消息、discovery)依然是合理选择,没必要为了"技术先进"强行替换成 gRPC;但如果涉及跨公网、跨 NAT、浏览器客户端,WebRTC/gRPC 的组合几乎是唯一解。

合成数据是必须项而非可选项。谷歌 17 个月 23 万条真机轨迹的成本曲线已经说明,纯真机路径在经济上不可持续。GR00T-Mimic、Cosmos Transfer、Seedance 这类合成数据管线应该尽早进入数据工厂规划——它们不是真机数据的替代,而是覆盖长尾场景(罕见物体、极端光照、危险操作)的唯一可行方式。

---

结语

回到开头那个判断:具身智能公司的核心竞争力,正在从"谁的模型架构更新颖"转向"谁的数据飞轮转得更快"。而数据飞轮的每一圈——采集、传输、存储、清洗、训练、评测、回流——背后站着的是一套经过十年打磨的大数据基础设施。

这套技术栈不是具身智能的"配套设施",它就是具身智能的地基。

---

参考

• 中国信通院《人形机器人产业级训练场建设指南》(数据规模测算)
• 国地中心人形机器人训练场建设(四点数据瓶颈)
• HuggingFace LeRobot Documentation(LeRobotDataset v3.0、OXE)
• Apache Iceberg / Delta Lake / Hudi 表格式文档
• 阿里云 EMR Serverless Spark + Daft 引擎
• NVIDIA Isaac Sim / GR00T-Mimic
• 星海图 G-Fleet 集群调度系统
• 本文姊妹篇:从 LLM Infra 到具身智能 Infra