数据生产体系重构：从人工三个月到自动七天

蔚来汽车 · 2022.10–2023.09 · 自动驾驶研发-云端工程部 · 数据生产团队负责人

团队规模大约 3 到 5 人，基本都是平台研发。我在负责团队管理的同时，也兼做数据生产和工具开发的实际工作。这个项目覆盖的是整个智驾研发体系的训练数据生产流程，当时整体训练数据规模大约 2 PB。

一、数据管理中心：让数据有身份

为什么需要重新设计

处境

智驾数据本质上是非结构化数据——原始传感器、标定信息、定位信息、模型二次修正数据、标注信息等组合在一起存放。随着数据量从几百 TB 增长到 PB 级，纯文件形式的管理模式开始撑不住：同一份数据在不同团队手里可能以不同格式存了好几份；训练代码里到处是"去某个路径找某个文件"的硬编码；数据和数据之间的关系只存在于 Excel 表格和工程师的脑子里；数据审计基本不可能——你不知道某个训练任务用了哪些数据，也不知道某份数据被哪些任务用过。

桌上的选项

一条路是在现有文件系统上叠加一层索引和元数据管理，不改底层存储方式。好处是改造小，坏处是解决不了格式不统一和重复存储的根本问题——索引层只能告诉你文件在哪里，不能保证文件内容是什么格式、是否重复。另一条路是从数据模型层面重新设计，建立统一的数据标准，从源头解决格式、粒度、存储和读取的一致性问题。

我的选择

我选了后者。设计了一套完整的数据标准化体系，包括四个层面：

数据格式标准化：定义了传感器数据、日志数据、真值数据、生成数据等每一类数据的标准格式，并支持同种数据在 h264/h265/mkv/jpgs、npz/pcd、pb/json/csv 之间的互相转换。目标是"拿到一份数据，不管它原来是什么格式，都可以直接使用"。

数据粒度标准化：把数据划分成时序单位数据和帧单位数据两种粒度，针对每个单位数据生成唯一 ID，同时支持两种粒度之间的互相转换。ID 成为数据在整个生命周期中的稳定锚点——只要 ID 在，后续的所有处理结果、生产关系、使用记录都不会丢。

存储方式标准化：离散化数据文件，在哈希化分布的基础上进行存储。哈希机制天然去重——相同内容的文件只存一份，从根本上消除"存多份"的问题。

读取接口标准化：针对训练数据生成统一的集合摘要，所有训练任务通过统一接口读取数据。这杜绝了训练代码对具体数据路径的依赖，训练效率不再因为数据接口的差异而下降。

我负责的是这套体系的架构设计、API 设计、数据结构设计和用户 SDK 设计。具体的实现代码由团队成员完成。

代价

所有现有的数据生产和消费流程都需要迁移到新标准上，迁移周期不短。团队和用户需要适应新的数据操作方式——从"直接操作文件"变成"通过标准接口操作数据"。

结果

数据管理中心上线后，正式接管了整个智驾研发体系的所有训练数据，成为训练数据生产的唯一通道。这不是一个团队内部工具，而是整个组织的数据基础设施。

更重要的长期影响是：这套数据标准在后续几年里成为了智驾数据的唯一认可形式。多个数据团队和算法团队之间传递数据的标准就是以这个格式模式进行的。大家逐步减少了通过 Excel 记录数据的习惯，开始依赖系统本身的数据管理能力。

回看

这件事的价值不在于"做了一套数据标准"，而在于这套标准真正成为了组织间数据交换的协议。技术上不复杂，难的是让几个团队都接受并迁移过来——这需要标准本身足够好用、迁移成本足够低、而且确实解决了他们的真实痛点。

二、数据生产中心：从人工串联到自动流水线

三个月变七天

处境

智驾数据的生产流程非常长——单条数据从原始采集到最终可以进入训练，一般要经过十几个处理环节，每个环节都是一个独立的服务或计算任务。在之前的模式下，每个环节之间的衔接完全靠人工：上一步跑完了，有人去检查结果，确认没问题后手动触发下一步。一条数据从提需求到完成训练准备，整个周期大约三个月。

桌上的选项

一条路是保持人工流程，通过工具减少每个环节的操作时间。这条路的天花板很低——即便每步都快了，环节之间的等待时间和人工协调成本还在。另一条路是把整个生产链路自动化——环节之间通过事件驱动自动串联，不需要人在中间盯着。

我的选择

我设计了基于 Event-Trigger 的服务调度流程：每个生产环节完成后自动触发下一个环节，形成多任务之间的自动串联调度。同时设计了统一调度接口，把不同形态的服务和任务（有的是长期运行的服务，有的是一次性的计算任务）用统一的方式接入调度体系。

数据血缘在这个架构中自然形成：以数据管理中心的数据集合作为中转，每个生产环节的输入和输出都是标准化的数据集，"产生一个新的数据集"就是一个生产环节的结束标志。这样每份数据在生产过程中经过了哪些环节、每个环节的输入输出是什么，都有记录。

需要诚实说一句：数据血缘的基础已经建立，但当时没有进一步做到"输入一个数据 ID，查询它完整的历史处理链路"的端到端查询能力。数据模型支持这种追溯，但查询界面没有做出来。

这部分是我和一名研发两个人从设计到开发共同完成的，整体设计由我主导。

代价

Event-Trigger 模式下，如果某个环节出了问题，错误会自动传播到后续环节。需要在每个环节加入状态检查和失败处理逻辑，比纯人工模式下的错误处理更复杂。

结果

生产周期从人工模式下的大约三个月，缩短到自动化模式下的大约七天。工厂数据生产流程不再需要有人在每个环节的节点去盯着，整体效率发生了量级变化。

回看

三个月到七天的变化听起来很夸张，但本质上就是把人工等待和协调的时间去掉了——计算本身的时间没有变，变的是环节之间的空转时间。这件事不需要多高深的技术，需要的是对整条生产链路的完整理解和足够细致的调度设计。

三、视频训练改造：行业首创的存储优化

背景：百 PB 存储即将打满

传统的 CV 训练普遍依赖图像。智驾的上千万份训练数据所依赖的高清 JPEG 图像，基本上占满了百 PB 级的存储空间。如果不做改变，后续的数据追加将没有空间可用。我和感知团队共同启动了存储优化项目。

项目面临三个硬约束：业内没有先例，需要完全自己摸索；两周内必须启动训练，不允许长期研发；数据格式极其复杂，I 帧间隔不统一，多种数据需要不同的解码方式，可用计算资源极其稀缺。

格式统一 vs 训练逻辑适配

处境

核心问题是：怎么让训练流程从"读 JPEG 图像"变成"读视频帧"。我把问题拆成了两个方向：一个是"数据格式统一"——在数据侧把视频处理成训练可以直接消费的标准格式；另一个是"训练逻辑适配"——让训练代码自己去处理视频格式的解码和帧提取。

桌上的选项

训练逻辑适配的好处是数据侧不需要做任何改动，让训练代码自己读视频。但评估后发现，非关键帧的解码会导致训练速度明显下降——视频的解码逻辑和训练的数据加载逻辑耦合在一起，每一帧的加载时间都会增加。而且更根本的问题是：我们是平台团队，不应该把基础设施层面的复杂度转嫁给用户侧的训练代码。训练团队不应该需要理解视频编码细节才能训练模型。

格式统一的做法是：在数据侧做预处理，把视频数据按照训练需要的方式重新组织好，训练代码只需要像以前读图像一样读数据，感知不到底层格式变化。

我的选择

我选了格式统一。按层级设计了数据统一格式定义：数据集 → 数据 → 传感器 → 文件和帧，以依赖的形式逐层拆解文件结构。在每一层数据维度都增加了缓存系统，加速训练数据的读取流程。

代价

数据侧需要承担大量的预处理工作——千万份数据需要在短时间内全部完成格式转换。这直接催生了下面的 MPI 高性能引擎。

结果

视频训练方式在行业内没有先例，我们是第一个做成的。改造完成后：数据加载效率相比原有 JPEG 图像训练方式提升了 110%；存储占用减少 95%；按存量数据计算，存储成本节省约三千万元。

回看

"平台不能把基础设施复杂度转嫁给用户"——这个判断在后来做数据管理中心、数据标准化的时候也反复被印证。平台的价值就是把复杂度吞进来，让用户侧保持简单。

MPI 高性能执行引擎

格式统一意味着千万份数据需要被重新处理。两周的时间窗口，可用计算资源又极其有限——不可能简单地"多开几台机器"来解决。

我设计并独立实现了一个基于 MPI 的高性能执行引擎。核心思路是：以任务队列的形式在单机内部调度任务，用多进程的方式极限压榨单机上的 GPU 和 CPU 算力。不是把任务分发到更多机器上（资源不够），而是把每一台机器的利用率从部分打满拉到极限打满。

格式改造部分大约花了一周，MPI 引擎的落地执行大约花了半个月到一个月。两部分都是我独立完成的。

最终在两周内完成了千万份数据的处理，数据处理效率相比之前提升了 3 倍。

技术架构：视频训练数据处理流水线

原始训练数据（千万份 JPEG 图像，百 PB 级存储）
              │
              ▼
┌──────────────────────────────────┐
│  格式统一预处理（我独立设计，~1 周）│
│                                  │
│  层级数据格式定义：               │
│  数据集 → 数据 → 传感器 → 文件&帧 │
│                                  │
│  · 视频替代 JPEG 进入训练         │
│  · 每层增加缓存系统               │
│  · 训练代码无需感知格式变化        │
└──────────────┬───────────────────┘
               │
               ▼
┌──────────────────────────────────┐
│  MPI 高性能执行引擎（我独立实现）  │
│                                  │
│  · 基于任务队列的单机内调度        │
│  · 多进程极限压榨 GPU + CPU       │
│  · 不靠堆机器，靠打满每台机器     │
│                                  │
│  约束：                          │
│  · 两周交付窗口                   │
│  · 计算资源极其稀缺               │
│  · 千万份数据需要全部处理          │
└──────────────┬───────────────────┘
               │
               ▼
┌──────────────────────────────────┐
│  处理结果                         │
│                                  │
│  · 存储减少 95%                   │
│  · 数据加载效率 +110%             │
│  · 数据处理效率 3×                │
│  · 存储成本节省 ~3000 万          │
│  · 两周内完成千万份数据处理        │
└──────────────────────────────────┘

训练侧（感知团队）
┌──────────────────────────────────┐
│  训练代码                         │
│  · 像以前读 JPEG 一样读数据       │
│  · 无需理解视频编码细节           │
│  · 通过缓存系统加速读取           │
│  · 数据加载方式对训练团队透明      │
└──────────────────────────────────┘

四、大模型百万数据交付

蔚来计划训练"世界大模型"（NWM），需要多种不同形态、不同来源的数据集。

百万份无监督数据

算法团队从已有数据池中筛选出需要的数据之后，我负责将这约一百万份数据改造成指定格式并完成交付——包括视频和点云的解码、数据重构和组织。这里直接复用了之前设计的 MPI 框架，结合团队内基于 OpenCV 开发的视频解码工具，快速完成了百万份数据的处理。

海外数据获取：N-1-1 网络架构

为了从海外获取开源数据集，需要大带宽、低成本的跨境数据传输能力。直接搭建跨境专线成本极高。

我和 leader 共同设计实施了一套 N-1-1 的网络传递链路——不走海外专线，而是通过多台海外服务器分别拉取数据，经由公网传回国内汇聚节点，再进入内网。核心思路是突破"只能走专线或固定通道"的思维定式，重新从不同地区的出口带宽成本出发，通过多节点公网带宽的累加，硬拼出一条高带宽低成本的数据通道。技术上使用 Xray 做网络穿透。

最终海外回国带宽打满到 5 Gbps，平均每台海外设备成本 25 元/月，回源流量 0.25 元/GB——远低于跨境专线费用，总成本节省约 75%。

落地与团队

项目持续约一年（2022.10–2023.09），团队 3 到 5 人，主要是平台研发。

各部分的个人贡献边界：

核心结果数据：

• 生产周期：人工 ~3 个月 → 自动 ~7 天
• 覆盖范围：整个智驾训练数据生产流程，~2 PB
• 视频训练：存储 -95%，数据加载 +110%，处理效率 3×，成本节省 ~3000 万
• 海外数据：5 Gbps，成本节省 ~75%

回看这个项目

这个项目不存在一个"押中高风险决策"的戏剧性时刻。它的价值在于：在原有链路还能工作的情况下，持续识别效率、标准化和规模化的问题，然后把整条链路重构成了一套新的基础设施。

数据管理中心的长期影响超出了项目本身——这套数据标准在后续几年里成为了智驾数据的唯一认可形式，多个团队之间的数据交换都以此为基础。ID 成为了数据全生命周期的稳定锚点。这不是技术上多么精妙的设计，而是一个足够好用、迁移成本足够低、且确实解决了真实痛点的标准，最终被组织采纳并持续使用。

视频训练改造是这个项目里技术密度最高的部分——行业没有先例，时间窗口极短，计算资源稀缺，最终独立完成了从格式设计到执行引擎的全部核心工作。"平台不能把基础设施复杂度转嫁给用户"这个判断，在后来做其他基础设施项目时也反复被印证。

MPI 引擎后来在百万数据交付中被直接复用，证明了它不只是解决一次性问题的临时方案，而是一个可以持续使用的基础能力。