前言

本文据原文整理而来，有不当之处欢迎联系我们指出

原文链接：https://mcap.dev/files/evaluation.pdf

本文回顾了时空数据记录格式的理想特性，这里包括了在机器人和自动驾驶等含多种传感器数据的应用场景，当然也包括 ROS 2 开发过程中考虑的特性。

根据这些数据的特点和其所需要的特性评估了现有的数据存储格式方案。

读者可以关注之前发布的系列文章，了解 MCAP 为什么可以作为时空数据的最佳数据存储格式。

数据记录的目的

记录机器人数据的目的是存储、分析或回放这些数据，以便理解机器人所观察到的环境输入、所采取的行动，以及内部状态的某些粒度，从而理解所做出的决策及其原因。

此目标通常通过将多个数据流记录为带有高分辨率时间戳的分组消息来实现。示例数据流包括相机图像、激光雷达扫描、姿态估计、规划决策和执行器命令。数据流在大小、频率、压缩和模式复杂性方面差异很大。

记录格式的理想特性

以下理想特性来自 Karsten Knese 关于 rosbag2 的设计提案和访谈。

01 序列化无关性

机器人领域尚未在单个消息序列化格式上达成标准。ROS1 包含其自己的序列化格式，而 ROS2 使用 CDR 作为默认格式，但包含一个可插拔的中间件层以支持其他序列化。非 ROS 机器人可能使用 Protocol Buffers、CBOR、JSON 或专有格式。

所以通用记录容器必须包含对不同序列化格式的支持，以支持当今使用的消息序列化选择的广度。

02 确定性

回放记录应该是一个确定性的过程。

记录中有许多不同的时间概念：消息最初发布的时间、发布者发送消息的时间（对于在队列中保留并重放的消息，这可能非常不同）、数据记录进程接收到它的时间，或记录器将其写入磁盘的时间。

为了实现确定性，单个流和跨流消息的顺序必须明确定义。这种顺序通常通过将高分辨率时间戳与每条消息关联起来实现，并在回放期间按时间戳顺序同时遍历所有流。

03 自描述性

机器人系统的设计往往是不断演变的。数据流会增加、减少，消息频率会调整，数据格式也会改变……

为了使记录文件作为长期存储有用，它必须是自描述的。即，它本身就包含了所有必要的信息，不需要额外的解释。

这意味着：

• 文件格式本身可以被识别：文件格式本身应该包含可以被识别的信息，例如文件签名。

• 数 格式可以被理解：就像通过文字和符号就能理解一本书的内容一样，数据格式应该可以被直接理解，例如使用 JSON 或 CBOR 等自描述格式，或者在记录中包含数据模式信息。

04 大数据和小数据

一些传感器流每秒可以产生千兆（GB）字节的数据。虽然始终可以沿时间轴分割文件，但记录容器应该至少支持数百吉（PB）字节，然后再强制进行文件分割。每条消息的开销应该足够低，以支持 1 kHz+ 频率的小消息，并且应该支持大型单个消息以支持未压缩的视频馈送。

05 写入优化

写入优化意味着要尽可能快地将数据写入文件，就像高速公路一样，让数据快速流动。

针对性能、启用流式传输数据以及崩溃安全等方面，追加文件格式是十分可取的。它能够通过在写入时压缩数据或写入未压缩数据来进行 I/O 和 CPU 和内存权衡。

需要注意的是，以下情况会降低写入速度，应尽量避免：昂贵的索引创建、昂贵的工作内存要求，以及写入时的昂贵转码。

06 无先验通道知识

机器人系统通常使用发布-订阅机制来传递信息，就像广播电台一样，不同的频道会发送不同的内容。问题是，我们可能无法事先知道所有需要记录的频道，或者每个频道的具体格式。

为了解决这个问题，记录器需要支持“追加”功能，也就是说，它可以在记录过程中随时添加新的频道或修改频道信息，就像在广播电台里，可以随时增加新的节目一样。

这样，即使在运行过程中，我们也能记录下所有需要的信息，而不用担心事先不知道所有频道。

07 抗损坏性

机器人工作环境复杂多变，可能会发生碰撞或系统故障等意外情况。这些意外事件可能导致记录文件损坏，无法保证数据的完整性。

为了应对这种情况，我们可以采取一些措施来提高记录文件的抗损坏性：

• 将数据分成更小的块：就像把一本书分成多个章节一样，这样即使某个章节损坏，其他章节仍然可以正常使用。

• 添加块级校验和：就像给每个章节添加一个指纹一样，可以用来验证数据是否完整。

• 提供恢复数据的文档：就像提供一份说明书一样，告诉用户如何从损坏的记录中恢复部分数据。

  
  

08 读取优化

为了让机器人数据既能快速记录，又能方便读取，我们需要在写入优化和读取优化之间找到平衡。

读取优化需要考虑以下几点：

• 无需加载整个文件：就像阅读一本书时，不需要把整本书都翻一遍才能找到想要的内容一样，读取数据时，也应该能够快速定位到需要的数据，而不用加载整个文件。

• 跨平台兼容：就像一本书可以在不同的设备上阅读一样，机器人数据应该能够在不同的环境（桌面、服务器、网络）中读取和解析。

• 高效的随机访问和范围请求：就像在书的目录中快速找到想要的内容一样，应该能够快速访问特定数据，或者读取特定范围的数据。

如果文件格式能够兼顾高写入吞吐量和高效读取，这将大大简化开发过程。就像大家都用一种格式写书，就能方便地阅读和分享书籍一样，统一的文件格式可以促进工具的开发和使用。

09 标准兼容性

为了让通用机器人记录文件格式得到广泛应用，它应该具备成为标准的资格。

这意味着它需要满足一些标准化的要求：

• 在多个地方的实际使用：这个标准应该已经被实际应用在多个不同的项目中，证明它的实用性和有效性。

• 完整文档：这个标准应该有详细的文档说明，解释它的功能、使用方法和设计原理，方便其他人理解和使用。

• 没有专利限制：这个标准不应该受到任何专利保护，这样任何人都可以自由地使用它，而不用担心侵犯专利权。

• 至少两个独立的实现：这个标准应该至少有两个不同的团队或组织独立地实现它，证明它的可行性和可靠性。

流行的机器人数据记录格式

01 rosbag1

最初的 ROS1 .bag 文件格式满足了我们的几个要求。

它具有确定性，自描述性，支持大数据和小数据，在一定程度上进行了写入优化（虽然不是追加式的），不需要先验通道知识，具有一定的抗损坏性（没有校验和，但可以在块级恢复数据，并且可以重建索引），通过索引进行读取优化，并且符合标准。其主要缺点是它不是序列化无关的。

02 rosbag2

rosbag2 是一个 C API，具有用于实现的插件接口，以及一个使用 SQLite 作为磁盘格式的默认实现。

由于本文重点关注序列化格式，因此 rosbag2 将被定义为默认的 SQLite 实现。这种格式是序列化无关的，确定性的，但不是（目前）自描述的，尽管正在进行解决该问题的工作。它不需要先验通道知识，具有抗损坏性，并且除了 Web 使用场景外，还进行了读取优化。

它的主要缺点是：

• 写入优化不足：它不是追加式的，每次插入数据都会更新索引，导致写入速度较慢。

• 缺乏压缩支持：除了单个消息级别，它不支持压缩，导致文件体积较大。

• Web 使用场景限制：在 Web 环境中，需要将整个文件读入内存，效率较低。

• 标准化挑战：SQLite 只有一个跨平台实现，难以满足标准化要求。
  
  

03 Length-delimited Protobufs

从对各种机器人公司的采访中得知，除了 ROS 之外，最流行的序列化格式是将 protobuf 消息写入磁盘，并使用简单的长度分隔符或简短的消息头。如果每个消息中都包含时间戳，这可以是确定性的，但初始的 .proto 模式也必须捆绑在一起才能满足自描述性标准。

这种方法不需要先验通道知识，并且支持大数据和小数据。它没有提供任何明确的抗损坏性，虽然截断的最终消息有时可以通过序列化失败来检测。它是一种写入优化的追加式方法，并且可以通过将写入输出通过压缩器进行管道传输来支持压缩。Protobufs 已经作为互联网草案（I-D）标准提交。

具体来说，它有两个主要缺点：

• 序列化无关性不足：由于该格式的设计围绕着一种特定的序列化格式，它无法兼容其他序列化格式。这意味着，如果使用不同的序列化方法，生成的记录文件将无法互相理解，造成兼容性问题。

• 缺乏读取优化：该格式没有针对随机访问进行优化，这意味着如果需要在记录文件中查找特定数据，效率会很低。这使得它不适合用于需要快速检索数据的回放或分析工具。
  
  

04 Apollo Cyber RT

Cyber RT 包含它自己的记录文件格式。然而，格式本身的文档（与围绕它的软件 API 相反）很少。就本文而言，它可能类似于Length-delimited Protobufs。

流行的大数据记录格式

除机器人记录文件格式之外，我们再来评估一下常见的大数据记录格式是否适用于此。

01 Avro - Native Types

Avro 是一种基于行的存储格式，要求每行都遵循单个模式。这需要所有可能的消息模式的联合类型，这些模式需要在将新通道添加到容器中或将每个通道写入单独的文件时重新写入。对不同序列化格式的支持要么需要将每个序列化格式映射到 Avro 数据类型，这可能是一个有损过程。

02 Avro - Opaque Bytes

使用 Avro 格式的另一种方法是将模式定义为包含不透明字节数组的单个字段，这支持在通用容器中使用不同的序列化格式。这种方法满足了许多期望的要求，但它违背了使用现有容器格式的最常见的好处：能够将数据摄取到第三方系统中，并让该系统以类型化的方式理解数据。建立在 Avro 之上的记录格式仍然需要标准化如何以及在何处存储内容类型和每个通道信息，例如模式。无论如何，存储不透明字节消息的 Avro 可能是一种可能的解决方案。

03 HDF5

HDF5 早于 Avro，并且存在类似的限制，同时还缺少对通过模式进行深度嵌套数据的支持。将 HDF5 严格用作不透明字节消息的包装器将需要更复杂的文件格式，而不会带来额外的收益。

04 Parquet

Parquet 是一种列式数据存储，不适合随机访问消息，并且没有针对回放进行优化。虽然 Parquet 在机器人分析和长期存储方面可以发挥重要作用，但它不适合实时记录和消息回放，因此它不属于我们寻找记录文件格式的范围。

结论

通过将现有的机器人记录格式与通用大数据容器格式进行比较，为机器人设计一种专门的记录格式具有实践意义。然而，现有的记录格式中没有一种能够满足本文中提出的所有要求和理想特性。许多提出的方法（rosbag2 SQLite、带有不透明缓冲区的 Avro）遵循了一种反模式：即使用现有的基于模式的格式，但只存储不透明的二进制块，从而否定了使用现有格式带来的互操作性承诺。

鉴于此评估，我们建议设计一种专门针对机器人记录需求的文件格式。其目标是继续收集需求和理想特性，并共同打造一种由多个实现支持的行业标准。