📚 课程目录第3章数据格式概述

3. 数据格式概述

在多传感器系统中，数据格式决定了数据如何被组织、传输、解析和长期维护。摄像头输出图像帧，激光雷达输出点云，IMU输出高频姿态与加速度，GNSS输出定位与时间信息。它们的数据形态差异极大，如果格式选择不当，后续的融合、存储和回放都会变得困难。因此，理解结构化与非结构化、文本与二进制、自描述与紧凑格式这三组基本区别，是设计传感器数据链路的第一步。

一、结构化与非结构化：数据是否按固定模式组织

结构化数据具有明确、稳定的字段定义。例如IMU采样可以表示为时间戳、角速度三轴、加速度三轴，每个字段的类型和单位都固定。这种数据适合用表格、数据库表或固定结构体表达，解析时不需要猜测含义。非结构化数据则没有统一的字段模式，典型代表是原始图像、音频波形、点云二进制块和自由文本日志。它们的内部结构可能很复杂，但对外没有统一的“列”或“字段”语义。

需要强调的是，非结构化不等于无结构。一张JPEG图像内部有压缩块、量化表和熵编码结构，只是这些结构不由业务字段直接描述。工程上常把非结构化数据与元数据分离：图像像素作为非结构化载荷，采集时间、相机编号、曝光参数作为结构化元数据。这样既保留原始数据的完整性，又让检索和管理变得可行。

核心判断：如果数据能被稳定地映射为“字段名→类型→单位→取值范围”，它更接近结构化数据；如果必须依赖专用解码器或外部说明才能理解其内容，它更接近非结构化数据。

二、文本格式与二进制格式：可读性与效率的权衡

文本格式使用字符编码表达数据，常见的有JSON、XML、CSV、YAML和自定义的ASCII协议。优点是可直接阅读、便于调试、跨平台兼容性好，适合配置、日志和低频传感器数据。缺点是体积大、解析慢、浮点数精度和字节序需要额外约定。二进制格式直接按字节布局存储，常见于图像、点云、雷达原始采样和高速总线数据。它紧凑、解析快、适合高带宽场景，但可读性差，必须依赖格式说明或解码工具。

以一组IMU数据为例，文本JSON可能如下：

{
  "timestamp": 1710000000.123,
  "gyro": [0.01, -0.02, 0.00],
  "accel": [0.00, 0.00, 9.81]
}

同样的数据用二进制结构体表达时，通常按小端序连续存放：8字节double时间戳、3个4字节float角速度、3个4字节float加速度，共32字节。文本形式约90字节，二进制形式仅32字节，差距接近三倍。在1000Hz IMU、多路传感器并发的场景下，这种差距会直接反映为总线带宽和CPU解析开销。

三、自描述与紧凑格式：信息放在数据里还是放在外部

自描述格式把字段名、类型甚至单位写在数据内部，JSON和XML是典型代表。接收方即使没有额外文档，也能从键名推断含义。紧凑格式则把模式外置，数据体只保留值或极短的标签。Protobuf、MessagePack、FlatBuffers以及多数传感器二进制协议都属于这一类。它们依赖.proto文件、IDL或协议手册来还原语义。

自描述格式的代价是冗余。每个JSON对象都重复携带键名，字段越多、采样越密，冗余越明显。紧凑格式的代价是耦合：发送方和接收方必须共享同一份模式定义，模式变更需要版本管理。工程上常见的折中是“紧凑数据体+自描述元数据头”，例如在数据包头部写入模式版本、字段偏移和单位表，载荷仍按二进制紧凑排列。

四、方法流程：如何为传感器数据选择格式

格式选择不是一次性拍板，而是一个可复用的判断流程。建议按以下步骤推进：

识别数据语义：判断该传感器输出能否被稳定字段化。IMU、GNSS、电池状态通常可以；图像、点云、音频通常作为非结构化载荷。
评估带宽与频率：高频、多路、大数据量优先二进制；低频配置和日志可用文本。
确定模式归属：如果接收方经常变化或需要人工排查，倾向自描述；如果收发双方固定且追求极致效率，倾向紧凑格式。
设计元数据层：无论载荷是文本还是二进制，都建议附加结构化元数据，包括时间戳、传感器ID、坐标系、单位、模式版本。
验证与回放：用真实数据做解析耗时、包体积和回放一致性测试，确认格式在长期存储和跨平台场景下不会成为瓶颈。

五、案例与场景：同一组IMU数据的不同表达

假设一路IMU以200Hz输出，每帧包含时间戳、三轴角速度、三轴加速度。若采用JSON文本，单帧约120字节，200Hz下约24KB/s；若采用紧凑二进制，单帧32字节，约6.4KB/s。单路差距看似不大，但若系统同时接入4路IMU、1路GNSS和1路轮速，文本方案的带宽和解析开销会迅速放大。反过来，如果只是调试阶段临时查看数据，JSON的可读性优势又非常明显。因此，工程上常见做法是：采集与传输用二进制，调试与日志导出用文本。

对比维度	结构化数据	非结构化数据	文本格式	二进制格式	自描述格式	紧凑格式
典型代表	IMU采样、GNSS定位	图像、点云、音频	JSON、CSV、XML	Protobuf、FlatBuffers	JSON、XML	Protobuf、MessagePack
可读性	高	低	高	低	高	低
体积效率	中	取决于编码	低	高	低	高
解析开销	低	高（需解码）	中高	低	中	低
模式依赖	强	弱	弱	强	弱	强
适用场景	融合输入、监控	原始载荷、算法输入	配置、日志、调试	高频传输、存储	接口多变、人工排查	固定链路、极致效率

六、常见误区与复盘

误区一：把“非结构化”当成“无法处理”。图像和点云虽然不按字段组织，但可以通过元数据、索引和专用解码器纳入统一数据管线。关键在于把载荷与描述分离，而不是强行字段化。

误区二：认为二进制一定优于文本。二进制在带宽和解析上占优，但调试成本、模式耦合和版本管理成本更高。低频、小数据量、接口频繁变化的场景，文本往往更划算。

误区三：忽略单位与坐标系。无论选择哪种格式，角速度是rad/s还是deg/s、加速度是否包含重力、点云在哪个坐标系，都必须显式记录。格式只解决“怎么放”，不解决“放的是什么”。

复盘建议：在项目早期就建立格式清单，逐项标注结构化程度、文本/二进制、自描述/紧凑、单位、坐标系和模式版本。这样在传感器增加、链路升级或长期存储时，能快速判断哪些格式需要重构，哪些只需扩展元数据。

总结来看，结构化与非结构化决定数据能否被字段化管理，文本与二进制决定可读性与效率的平衡，自描述与紧凑决定模式信息放在数据内还是数据外。三组区别相互独立又彼此组合，实际工程中很少存在“唯一正确”的格式，只有与带宽、调试、存储和团队协作方式相匹配的选择。理解这些基本区别，才能在后续的格式转换、协议设计和融合管线中做出有依据的决策。