4、录制工具选型：ROS Bag、Kafka、自定义录制脚本、开源录制框架（如 MCAP）
好，咱们进入第四章。这一章聊的是「选型」，说白了就是——你手里有活，该用哪把刀？
数据录制这件事，听起来简单：把数据存下来嘛。但真到实战中，你会发现不同场景下，工具的选择直接决定了你后续能不能顺利回放、能不能做分布式、能不能做长周期录制。我见过不少团队，一开始随便选了个工具，结果数据量一上来，回放时各种踩坑，最后不得不重写录制模块。嗯，咱们今天就把这事聊透。
4.1 ROS Bag：自动驾驶领域的「老大哥」
如果你做自动驾驶或机器人相关，ROS Bag 你肯定不陌生。它几乎是 ROS 生态里的标配录制工具。
优点很明显：
- 与 ROS 深度绑定，直接录制 topic 数据，回放时几乎零配置
- 支持时间戳同步，多传感器数据天然对齐
- 社区成熟，工具链完善（rosbag play、rosbag info、rosbag filter 等）
但缺点也让人头疼：
- 文件格式是 .bag，非标准格式，跨平台兼容性差
- 不支持分布式录制，单机瓶颈明显
- 大文件处理能力弱，我遇到过录制 2 小时的数据，bag 文件超过 50GB，回放时内存直接爆掉
4.2 Kafka：分布式录制的「工业级选手」
Kafka 本身是消息队列，但很多人用它来做数据录制。为什么？因为它天然支持高吞吐、持久化、分布式。
我曾在某个项目中，需要同时录制 50 路摄像头数据，每路 1080p 30fps。ROS Bag 直接跪了，但 Kafka 扛住了。说白了，Kafka 的设计就是为这种场景准备的。
Kafka 做录制的优势：
- 高吞吐、低延迟，适合大规模传感器数据
- 数据持久化到磁盘，支持回溯消费
- 分布式架构，水平扩展无压力
但要注意：
- Kafka 不是为「录制-回放」设计的，你需要自己写消费者来模拟回放逻辑
- 时间戳管理需要额外处理，否则回放时数据顺序可能乱
- 运维成本高，需要维护 Kafka 集群
4.3 自定义录制脚本：灵活但「坑多」
有些团队喜欢自己写录制脚本，用 Python 或 C++ 直接订阅数据源，然后写入文件。好处是灵活，想怎么录就怎么录。
但说实话，我不太推荐。除非你团队有很强的工程能力，否则自定义脚本很容易出现以下问题：
- 数据丢失：网络抖动或磁盘 I/O 瓶颈时，脚本可能丢数据
- 时间戳不准确：多线程环境下，时间戳容易错乱
- 回放困难：自己定义的格式，回放时还得自己写解析器
我见过一个团队，自己写了个录制脚本，用 JSON 格式存数据。结果数据量一大，JSON 解析成了瓶颈，回放速度比录制慢 10 倍。最后不得不重写。
4.4 MCAP：新一代开源录制框架
MCAP 是近年来比较火的一个录制格式，由 Foxglove 团队推出。它试图解决 ROS Bag 和自定义脚本的痛点。
MCAP 的核心特点：
- 基于 protobuf 的二进制格式，体积小、解析快
- 支持索引，随机访问数据，不用从头读到尾
- 跨平台、跨语言，C++、Python、Rust 都有 SDK
- 支持压缩，节省存储空间
我最近在一个项目中尝试用 MCAP 替代 ROS Bag，效果不错。录制 10 分钟的数据，MCAP 文件比 .bag 小了 30%，而且回放时随机跳转几乎无延迟。
4.5 选型对比：一张表说清楚
| 工具 | 适用场景 | 优点 | 缺点 | 我的推荐指数 |
|---|---|---|---|---|
| ROS Bag | ROS 生态、小规模数据 | 与 ROS 无缝集成、工具链完善 | 单机瓶颈、大文件处理弱 | ⭐⭐⭐ |
| Kafka | 大规模、分布式录制 | 高吞吐、可扩展、持久化 | 运维复杂、回放需额外开发 | ⭐⭐⭐⭐ |
| 自定义脚本 | 特殊协议、快速原型 | 灵活、可控 | 易出错、回放困难 | ⭐⭐ |
| MCAP | 通用场景、跨平台 | 体积小、支持索引、跨语言 | 社区相对年轻 | ⭐⭐⭐⭐⭐ |
4.6 核心逻辑图：录制工具选型决策流程
下面这张图是我自己总结的选型决策流程，帮你快速判断该用哪个工具。
4.7 我的最终建议
说了这么多，其实选型没有银弹。我个人习惯是：
- 小团队、快速原型：用 ROS Bag，省心
- 大规模、分布式：上 Kafka，但要做好运维准备
- 通用场景、追求性能：试试 MCAP，它可能是未来的趋势
- 特殊需求：自定义脚本，但一定要做好异常处理和回放兼容性
嗯，这一章就到这里。工具选对了，后面录制和回放才能顺风顺水。下一章咱们聊聊具体的录制流程和最佳实践。