MCAPについて整理してみた

背景・目的

MCAPについて、触れる機会がありましたので基本的な知識を整理します。

まとめ

下記に特徴を整理します。

特徴	説明
概要	MCAPは、マルチモーダルログデータ用のオープンソースのコンテナファイル形式 タイムスタンプ付きのシリアル化済みデータを複数チャネルでサポート pub/subやロボット工学アプリケーションでの使用に最適
MCAPの特徴	・Pub/sub logging ・Serialization-agnostic ・High-performance writing ・Self-contained ・Efficient seeking ・Optional compression ・Broad language support ・Flexible ・Production-grade
Benefits	・Heterogeneous data ・Performant writing ・Efficient seeking ・Self-contained files

概要

下記を基に整理します。

MCAP (pronounced "em-cap") is an open source container file format for multimodal log data. It supports multiple channels of timestamped pre-serialized data, and is ideal for use in pub/sub or robotics applications.

• MCAPは、マルチモーダルログデータ用のオープンソースのコンテナファイル形式
• タイムスタンプ付きのシリアル化済みデータを複数チャネルでサポート
• pub/subやロボット工学アプリケーションでの使用に最適

Pub/sub logging

Store multiple channels of timestamped log data, such as pub/sub messages or multimodal sensor data.

• pub/sub メッセージやマルチモーダル センサー データなど、タイムスタンプ付きのログ データの複数のチャネルを保存する

Serialization-agnostic

Record and replay binary messages in any format – like Protobuf, DDS (CDR), ROS, JSON, and more.

• Protobuf、DDS (CDR)、ROS、JSON など、あらゆる形式でバイナリ メッセージを記録および再生する

High-performance writing

MCAP uses a row-oriented, append-only design to minimize disk I/O and reduce the risk of data corruption during unclean shutdowns.

• MCAP は行指向の追加専用設計を使用して、ディスク I/O を最小限に抑え、異常なシャットダウン時のデータ破損のリスクを軽減する

Self-contained

MCAP stores message schemas alongside data, so your files remain readable in the future even as your codebase evolves.

• MCAP はメッセージ スキーマをデータと共に保存するため、コードベースが進化してもファイルは将来も読み取り可能な状態を保つ

Efficient seeking

MCAP files contain an optional index, allowing for fast, efficient reading, even over a low-bandwidth internet connection.

• MCAP ファイルにはオプションのインデックスが含まれており、低帯域幅のインターネット接続でも高速で効率的な読み取りが可能

Optional compression

Choose between LZ4 or Zstandard for chunk-based compression, while still supporting efficient indexed reads.

• 効率的なインデックス読み取りをサポートしながら、チャンクベースの圧縮には LZ4 または Zstandard を選択する

Broad language support

Native reader and writer libraries are available in C++, Go, Python, Rust, Swift, and TypeScript.

• ネイティブ リーダーおよびライター ライブラリは、C++、Go、Python、Rust、Swift、TypeScript で利用できる

Flexible

Configure optional features like chunking, indexing, CRC checksums, and compression to make the right tradeoffs for your application.

• チャンク、インデックス作成、CRC チェックサム、圧縮などのオプション機能を構成して、アプリケーションに適切なトレードオフを行う

Production-grade

MCAP is used in production by a wide range of companies, from autonomous vehicles to drones, and is the default log format in ROS 2.

• MCAP は、自律走行車からドローンまで、幅広い企業の生産現場で使用されており、ROS 2 のデフォルトのログ形式

Introduction

下記を基に整理します。

Benefits

MCAP works well under various workloads, resource constraints, and durability requirements.

• MCAP は、さまざまなワークロード、リソース制約、耐久性要件の下で適切に機能

Heterogeneous data

• Store messages encoded in multiple serialization formats in a single file
• Include metadata and attachments

• 複数のシリアル化形式でエンコードされたメッセージを1つのファイルに保存する
• メタデータと添付ファイルを含める

Performant writing

• Append-only structure
• Recover partially-written files when data recording is interrupted

• 追加専用の構造
• データ記録が中断されたときに部分的に書き込まれたファイルを回復する

Efficient seeking

• Extract data without scanning the entire file
• Fast access to indexed summary data

• ファイル全体をスキャンせずにデータを抽出
• インデックス化された要約データへの高速アクセス

Self-contained files

• Embed all message schemas in the file
• No extra dependencies needed for decoding

• すべてのメッセージスキーマをファイルに埋め込む
• デコードに追加の依存関係は不要

History

We evaluated many existing data storage formats in the industry and identified a clear need for a general-purpose, open source data container format – specifically optimized for robotics use cases. Designing this format would solve an industry-wide problem and make it easier for teams to leverage third-party tools and share their own tooling.

• 業界の既存の多くのデータストレージ形式を評価し、汎用性の高いオープンソースのデータコンテナ形式の必要性を明確に認識した
• ロボットの使用事例に特化して最適化されてる
• このフォーマットを設計することで、業界全体の問題が解決され、チームがサードパーティのツールを活用したり、独自のツールを共有したりすることが容易になる

Before MCAP

Many robotics companies spend valuable in-house resources to develop custom file formats, only to create future work and complicate third-party tool integrations. We built MCAP to allow teams to focus on their core robotics problems and avoid wasting precious time making commodity tools.

• 多くのロボット企業は、カスタム ファイル形式の開発に貴重な社内リソースを費やしているが、その結果、将来の作業が増え、サードパーティ ツールの統合が複雑化している
• MCAP は、チームがロボット工学の核となる問題に集中し、貴重な時間を汎用ツールの作成に無駄にせずに済むように構築された

Before MCAP, the format that robotics teams used to store their log data depended mainly on their framework. Those using ROS 1 defaulted to the .bag format; those on ROS 2 defaulted to a SQLite-based format. Companies that don’t use ROS often employed a custom in-house binary format, such as length-delimited Protobuf, or stored their messages as opaque bytes inside existing file formats such as HDF5.

• MCAP 以前は、ロボットチームがログ データを保存するために使用していた形式は、主にフレームワークに依存していた
  • ROS 1 を使用している場合はデフォルトで .bag 形式
  • ROS 2 を使用している場合はデフォルトで SQLite ベースの形式になる
• ROS を使用していない企業では、長さで区切られた Protobuf などのカスタムの社内バイナリ形式を採用したり、HDF5 などの既存のファイル形式内に不透明なバイトとしてメッセージを保存したりすることがよくある

These existing storage options have several shortcomings. Custom in-house formats lack interoperability and require developing corresponding libraries in multiple languages to read and write files. The ROS 1 bag format is challenging to work with outside of the ROS ecosystem, while the ROS 2 SQLite format is not fully self-contained, making it difficult for third-party tools to read.

• これらの既存のストレージオプションにはいくつかの欠点がある
• 社内で独自にカスタマイズした形式は相互運用性が欠けており、ファイルの読み取りと書き込みを行うには複数の言語で対応するライブラリを開発する必要がある
  • ROS 1 bag 形式は ROS エコシステムの外部で操作するのが困難
  • ROS 2 SQLite 形式は完全に自己完結的ではないため、サードパーティのツールで読み取ることが困難

After MCAP

As a container format, MCAP solves many of these issues. It is self-contained, can embed multiple data streams encoded with different serialization formats in a single file, and even supports metadata and attachments. MCAP files are optimized for both high-performance writing and efficient indexed reading, even over remote connections.

• コンテナ形式として、MCAP はこれらの問題の多くを解決する
• 自己完結型で、異なるシリアル化形式でエンコードされた複数のデータ ストリームを 1 つのファイルに埋め込むことができ、メタデータや添付ファイルもサポートしている
• MCAP ファイルは、リモート接続でも、高パフォーマンスの書き込みと効率的なインデックス読み取りの両方ができるように最適化されている

Evaluation of robotics data recording file formats

下記のPDFを基に整理します。

The transition from ROS 1 to ROS 2 involves switching recording file formats from the classic
“rosbag” (.bag) file format to a new serialization format. The rosbag2 recording software
includes a pluggable interface to support different serialization methods, with the current default
using SQLite (.db3) files. Non-ROS robotics frameworks each use their own recording format,
leading to further fragmentation. This document reviews desirable properties of a robotics data
recording format (including those considered during ROS 2 development) and evaluates
existing and proposed solutions against those requirements.

• このドキュメントでは、ロボティクスデータ記録形式の望ましい特性（ROS 2 開発中に検討されたものも含む）をレビューし、既存のソリューションと提案されているソリューションをそれらの要件に照らして評価する

Problem Statement

The goal of recording robotics data is to store and analyze or replay the data later to understand
what environmental inputs were observed, what actions were taken, and some granularity of the
internal state to understand what decisions were made and why. This goal is usually
accomplished by recording multiple streams of data as packetized messages with
high-resolution timestamps. Example data streams include camera images, LIDAR scans, pose
estimates, planning decisions, and actuator commands. The streams of data vary significantly in
size, frequency, compression, and schema complexity. The following desirable properties have
been collected from Karsten Knese’s rosbag2 design proposal and from interviewing robotics
companies using a variety of approaches to data recording and data storage.

• ロボットデータを記録する目的は、データを保存し、分析または後で再生することで、下記のような内容についてどのような決定が下され、その理由は何かを理解すること
  • どのような環境入力が観測されたか
  • どのような行動が取られたか
  • 内部状態の粒度を把握
• この目的は通常、複数のデータストリームを高解像度のタイムスタンプを持つパケット化されたメッセージとして記録することで達成される
• データストリームの例
  • カメラ画像
  • LIDARスキャン
  • 姿勢推定
  • 計画決定
  • アクチュエータコマンド
• データストリームは、サイズ、周波数、圧縮、スキーマの複雑さが大きく異なる
• 次の望ましい特性は、Karsten Knese氏のrosbag2設計提案と、データ記録およびデータ保存にさまざまなアプローチを採用しているロボット企業へのインタビューから収集されたもの

Serialization Agnostic

The robotics world has not standardized on a single message serialization format. ROS1
included its own serialization format, while ROS2 uses CDR as the default but includes a
pluggable middleware layer to support other serializations. Non-ROS robots may be using
Protocol Buffers, CBOR, JSON, or a proprietary format. A generic recording container must include support for different serialization formats to support the breadth of choices for message serialization in use today.

• ロボット工学の世界では、単一のメッセージシリアル化形式が標準化されていない
• ROS1 には独自のシリアル化形式が含まれていたが、ROS2 では CDR がデフォルトとして使用されいるが、他のシリアル化をサポートするためのプラグ可能なミドルウェア層が含まれている
• ROS以外のロボットは、Protocol Buffers、CBOR、JSON、または独自のフォーマットを使用している可能性がある
• 汎用記録コンテナーには、現在使用されているメッセージシリアル化の幅広い選択肢をサポートするために、さまざまなシリアル化形式のサポートが含まれている必要がある

Determinism

Playing back a recording should be a deterministic process. The ordering of messages in a single stream and across streams must be well defined to enable this. This ordering is generally achieved by associating high-resolution timestamps with each message and iterating across all streams concurrently in timestamp order during playback. There are many different concepts of time in a recording: the time a message was originally published, the time when it was sent by the publisher (this can be very different for messages that are held in a queue and replayed), when the data recording process received it, or when the recorder wrote it to disk. Using a consistent definition of time is the most critical requirement while storing multiple timestamps
can enable additional use cases.

• 録音の再生は決定論的なプロセスである必要がある
  • これを可能にするには、単一のストリーム内およびストリーム間のメッセージの順序が適切に定義されている必要がある
  • この順序付けは通常、各メッセージに高解像度のタイムスタンプを関連付け、再生中にすべてのストリームをタイムスタンプ順に同時に反復処理することによって実現される
• 記録における時間の概念は多岐にわたる
  • メッセージが最初に公開された時刻
  • パブリッシャーによって送信された時刻 (キューに保持されて再生されるメッセージの場合は大きく異なる場合がある)
  • データ記録プロセスでメッセージが受信された時刻
  • レコーダーがディスクに書き込んだ時刻など
• 一貫した時間の定義を使用することは最も重要な要件だが、複数のタイムスタンプを保存することで、追加のユースケースが可能になる

Self-Describing

The design of robotic systems is often evolving. Data streams are added and removed,
message publishing frequencies are tuned up and down, and schemas change. For a recording file to be useful as long-term storage, it must be self-describing. That is, the decoding of the container itself must be understandable by looking at a file signature, and the serialization of individual messages must either be self-describing (such as JSON or CBOR) or described by a schema embedded in the recording for each stream. Parsing a recording should not require access to external schemas, a specific codebase revision, or any other external resources.

• ロボットシステムの設計は頻繁に進化している
• データストリームが追加または削除され、メッセージの発行頻度が調整され、スキーマが変更される
• 録音ファイルを長期保存に役立てるには、自己記述型である必要がある
• コンテナ自体のデコードはファイル署名を見るだけで理解可能でなければならず、個々のメッセージのシリアル化は自己記述的（JSONやCBORなど）であるか、各ストリームの記録に埋め込まれたスキーマによって記述されている必要がある
• 記録の解析には、外部スキーマ、特定のコードベースリビジョン、またはその他の外部リソースへのアクセスは必要ない

Big and Small Data

Some sensor streams can produce gigabytes of data per second. While splitting files along the time axis is always possible, the recording container should support at least hundreds of gigabytes before forcing a file split. The per-message overhead should be low enough to support small messages at 1kHz+ frequency, and large individual messages should be possible to support uncompressed video feeds.

• 一部のセンサー ストリームは、1 秒あたり数ギガバイトのデータを生成できる
• 時間軸に沿ってファイルを分割することは常に可能だが、ファイルの分割を強制する前に、記録コンテナーが少なくとも数百ギガバイトをサポートする必要がある
• メッセージごとのオーバーヘッドは、1kHz 以上の周波数で小さなメッセージをサポートできるほど低く、大きな個別のメッセージは非圧縮ビデオ フィードをサポートできる必要がある

Write-Optimized

For a file format to be suitable for recording, it must be optimized for write throughput. An append-only file format is desirable for performance, to enable streaming data as it is written, and for crash safety. It should be possible to make I/O and CPU/memory tradeoffs by either compressing data at write time or writing uncompressed data. Things to avoid: expensive index creation, expensive working memory requirements, and expensive transcoding at write time.

• ファイル形式を記録に適したものにするには、書き込みスループットを最適化する必要がある
• 追加専用のファイル形式は、パフォーマンス、書き込み時のストリーミングデータの有効化、およびクラッシュの安全性の点で望ましいもの
• 書き込み時にデータを圧縮するか、非圧縮データを書き込むかによって、I/O と CPU/メモリのトレードオフが可能になる
• 回避すべき事項:
  • コストのかかるインデックス作成
  • コストのかかる作業メモリ要件
  • 書き込み時のコストのかかるトランスコーディング

No A Priori Channel Knowledge

Most robotics frameworks use a publish-subscribe (pub/sub) messaging system to send
messages over channels, also known as topics. It is not always possible to know the complete list of channels that should be recorded ahead of time or the schemas for each channel before the channel starts publishing messages. For a recorder to support append-only, it must be possible to write new channel information and schemas midway through writing, after writing has already begun for other channels.

• ほとんどのロボットフレームワークは、トピックとも呼ばれるチャネルを介してメッセージを送信するために、パブリッシュ/サブスクライブ（pub/sub）メッセージングシステムを使用する
• チャネルがメッセージの公開を開始する前に、事前に記録する必要があるチャネルの完全なリストや各チャネルのスキーマを常に把握できるとは限らない
• レコーダーが追加のみをサポートするには、他のチャネルの書き込みがすでに開始された後、書き込みの途中で新しいチャネル情報とスキーマを書き込むことができる必要がある

Corruption Resilient

Robots operate in chaotic environments. The most critical recording files are often associated with an unpredictable event such as a collision or system failure where data integrity cannot be guaranteed. Some possible mitigations are splitting the data into smaller chunks, adding chunk-level checksumming, and a documented process on how to recover partial data from a truncated or otherwise corrupted recording.

• ロボットは混沌とした環境で動作する
• 最も重要な記録ファイルは、衝突やシステム障害など、データの整合性が保証されない予期しないイベントに関連付けられることがよくある
• 考えられる軽減策としては、データを小さなチャンクに分割し、チャンク レベルのチェックサムを追加し、切り捨てられたり破損した記録から部分的なデータを回復する方法に関するプロセスを文書化することが挙げられる

Read-Optimized

There are many kinds of read-optimization, and often there is a direct tradeoff between read-optimization and write optimization. A recording format should be optimized for write throughput first and foremost. However, the generated files should be readable without loading the entire file into memory, parseable in different environments (desktop, server, web), and support efficient random access and range requests if possible. Although it is possible to use different file formats for recording and archiving with a transcoding process, if a file format can support high write throughput and speed up these read operations, it simplifies the development
ecosystem. Tooling can then converge around a single file format.

• 読み取り最適化にはさまざまな種類があり、読み取り最適化と書き込み最適化の間には直接的なトレードオフが存在することがよくある
• 記録フォーマットは、何よりもまず書き込みスループットを最適化する必要がある
• 生成されるファイルは、ファイル全体をメモリにロードすることなく読み取り可能で、さまざまな環境（デスクトップ、サーバー、Web）で解析可能であり、可能であれば効率的なランダムアクセスと範囲リクエストをサポートする必要がある
• トランスコードプロセスでは、記録とアーカイブに異なるファイル形式を使用することは可能だが、高い書き込みスループットと読み取り操作の高速化を実現できるファイル形式であれば、開発エコシステムを簡素化できる
• ツールは単一のファイル形式に集約できる

Standards Compatible

If a universal robotics recording file format is adopted, it should be eligible to become a standard. The standard could take the form of an Internet Engineering Task Force RFC or a normalized specification through another standards body. Typical requirements include real-world usage in multiple places, complete documentation, no patent encumberment, and at least two independent implementations.

• 汎用的なロボット記録ファイル形式が採用されれば、標準になる資格が得られるはず
• この標準は、インターネット技術タスクフォースの RFC または別の標準化団体による標準化された仕様の形をとる可能性がある
• 一般的な要件には、複数の場所での実際の使用、完全なドキュメント、特許の制約がないこと、および少なくとも 2 つの独立した実装が含まれる

Existing Robotics Recording Formats

We can compare this set of requirements and desirable properties against existing file formats designed as robot recording containers.

• この一連の要件と望ましいプロパティを、ロボット記録コンテナーとして設計された既存のファイル形式と比較することができる

rosbag1

The original ROS1 .bag file format meets several of our requirements. It is deterministic, self-describing, supports big and small data, somewhat write-optimized (although not append-only), does not require a priori channel knowledge, somewhat corruption resistant (no checksums, but data can be recovered at the chunk level and the index can be rebuilt), read-optimized via an index, and standards compatible. Its major shortcoming is that it is not serialization agnostic.

• オリジナルの ROS1 .bag ファイル形式は、いくつかの要件を満たしている
  • 決定論的
  • 自己記述的
  • 大規模データと小規模データをサポート
  • ある程度書き込みが最適化されている (ただし追加専用ではない)
  • 事前のチャネル知識を必要とせず、ある程度破損耐性がある (チェックサムはないが、チャンク レベルでデータを回復し、インデックスを再構築できる)
  • インデックスを介して読み取りが最適化されている
  • 標準と互換性がある
• 主な欠点は、シリアル化に依存しないこと

rosbag2

Whereas rosbag1 refers to both a file format definition and two reference implementations (C++ and Python), rosbag2 is a C API with a plugin interface for implementations, plus a default implementation using SQLite as the on-disk format.
Since this document is focused on serialization formats, rosbag2 will be defined as the default SQLite implementation. This format is serialization agnostic, deterministic, but not (yet) self-describing, although there is ongoing work to address that. It does not require a priori channel knowledge, is corruption resistant, and is read-optimized except in the web use case. The significant shortcomings are around write-optimization (not append-only, the index is updated per row insert), lack of compression support at write time beyond the individual message level, and requiring the entire file to be read
into memory in the web use case (via sql.js). SQLite also poses challenges to standardization. The Internet Engineering Task Force, W3C, and other standards bodies require any specification to have two independent implementations to graduate to a standard. SQLite has only ever had a single implementation that is cross-compiled to different platforms, which caused the Web SQL Database proposal to reach an impasse.

• rosbag1 はファイル形式の定義と 2 つのリファレンス実装 (C++ と Python) の両方を参照するが、rosbag2 は実装用のプラグイン インターフェイスを備えた C API であり、さらにディスク上の形式として SQLite を使用するデフォルトの実装
• このドキュメントはシリアル化形式に焦点を当てているため、デフォルトのSQLite実装としてrosbag2を定義している
  • この形式はシリアル化に依存せず、決定論的だが、（まだ）自己記述的ではない。この点については現在作業が進められている
  • 事前のチャネル知識を必要とせず、破損耐性があり、Webユースケースを除いて読み取り最適化されている
• 大きな欠点
  • 書き込み最適化（追加のみではなく、行の挿入ごとにインデックスが更新される）
  • 個々のメッセージレベルを超えた書き込み時の圧縮サポートの欠如
  • Webユースケース（sql.js経由）ではファイル全体をメモリに読み込む必要があること
  • SQLiteは標準化にも課題をもたらす
• インターネット技術タスクフォース（IETF）、W3C、その他の標準化団体は、あらゆる仕様が標準規格として認められるためには、2つの独立した実装が必要であると規定している
• SQLiteはこれまで、異なるプラットフォームにクロスコンパイル可能な実装が1つしか存在せず、Web SQL Databaseの提案は行き詰まりに陥った

Length-delimited Protobufs

From interviewing various robotics companies, the most popular serialization format outside of ROS is to write protobuf messages to disk with a simple length delimiter or short message header. If timestamps are included in every message, this can be deterministic, but the initial .proto schemas must be bundled as well to meet the self-describing criteria. This approach does not require a priori channel knowledge and supports big and small data. It does not provide any explicit corruption resistance, although a truncated final message can sometimes be detected by a serialization failure. It is a write-optimized append-only approach, and compression can be
supported by piping the write output through a compressor. Protobufs have been submitted as an Internet-Draft (I-D) standard. The significant shortcomings are that by nature of defining around a single serialization format, it is not serialization agnostic, and that without a well-defined standard, the files produced by different implementations will be incompatible. The lack of read-optimization excludes its use in playback or analysis tools that require random seeking.

• さまざまなロボット企業にインタビューした結果、ROS 以外で最も一般的なシリアル化形式は、単純な長さ区切り文字または短いメッセージ ヘッダーを使用して protobuf メッセージをディスクに書き込むことであることがわかった
• すべてのメッセージにタイムスタンプを含めることで決定論的な処理が可能になるが、自己記述基準を満たすためには、初期の.protoスキーマもバンドルする必要がある
• このアプローチは、事前のチャネル知識を必要とせず、ビッグデータとスモールデータの両方をサポートする
• 明示的な破損耐性は提供されないが、シリアライゼーションの失敗によって最終メッセージの切り捨てが検出されることがある。これは書き込みに最適化された追記専用のアプローチであり、書き込み出力を圧縮器にパイプすることで圧縮をサポートできる
• Protobufはインターネットドラフト（I-D）標準として提出されている
• 大きな欠点
  • 単一のシリアル化形式を定義するという性質上、シリアル化に依存しないこと
  • 明確に定義された標準がなければ、異なる実装で生成されたファイル間で互換性がなくなること
  • 読み取り最適化がないため、ランダムシークを必要とする再生ツールや分析ツールでは使用できない

Apollo Cyber RT

Cyber RT includes its own recording file format. However, the documentation of the format itself (opposed to the software APIs surrounding it) is scarce. It is likely similar to Length-delimited Protobufs for the purpose of this discussion

• Cyber​​ RTには独自の録音ファイル形式が含まれている
• しかし、形式自体に関するドキュメント（関連するソフトウェアAPIとは異なり）は不足している
• この議論の目的からすると、長さで区切られたProtobufsに類似していると考えられる

Existing Big Data Formats

Outside of robotic recording file formats, we can evaluate common “big data” containers for suitability to this problem.

• ロボット記録ファイル形式以外では、一般的な「ビッグデータ」コンテナがこの問題に適しているかどうかを評価できる

Avro - Native Types

Avro is a row-based storage format that requires each row to follow a single schema. This requires a union type of all possible message schemas that need to be rewritten as new channels are added into a container or each channel to be written to a separate file. Support for different serialization formats either requires mapping each serialization format to Avro data types, which may be a lossy process.

• Avro は行ベースのストレージ形式であり、各行は単一のスキーマに従う必要がある
• これには、新しいチャネルがコンテナーに追加されるか、各チャネルが個別のファイルに書き込まれるときに書き換える必要があるすべての可能なメッセージ スキーマのユニオン タイプが必要
• さまざまなシリアル化形式をサポートするには、各シリアル化形式を Avro データ型にマッピングする必要があるが、これは損失の多いプロセスになる可能性がある

Avro - Opaque Bytes

Another way of using the Avro format is to define the schema as a single field containing an opaque array of bytes, which supports different serialization formats in a common container.This approach meets many of the desired requirements, but it defeats the most commonly desired benefit of using an existing container format: the ability to ingest data into a third-party system and have that system understand the data in a typed way. A recording format built on Avro would still require standardizing how and where to store content types and per-channel information such as schemas. Regardless, Avro containers storing opaque byte messages may be one possible solution.

• Avro 形式を使用するもう 1 つの方法は、不透明なバイト配列を含む単一のフィールドとしてスキーマを定義し、共通コンテナー内のさまざまなシリアル化形式をサポートすること
• このアプローチは多くの望ましい要件を満たすが、既存のコンテナ形式を使用することで一般的に望まれる利点、つまりサードパーティ システムにデータを取り込み、そのシステムに型指定された方法でデータを理解させる機能が損なわれる
• Avro 上に構築された記録フォーマットでは、コンテンツタイプやチャネルごとの情報（スキーマなど）の保存方法と保存場所を標準化する必要がある
• いずれにせよ、不透明なバイトメッセージを保存する Avro コンテナは、一つの解決策となる可能性がある

HDF5

HDF5 predates Avro and suffers from similar limitations while also missing support for deeply nested data via schemas. Using HDF5 as strictly a wrapper around opaque byte messages would require a more complex file format for no additional gain.

• HDF5はAvroより古く、Avroと同様の制限を抱えているだけでなく、スキーマによる深くネストされたデータのサポートも欠いている
• HDF5を不透明なバイトメッセージのラッパーとしてのみ使用すると、追加のメリットがなく、より複雑なファイル形式が必要になる

Parquet

Parquet is a columnar data store that is not suitable for random access to messages and is not optimized for replay. While Parquet can play a valuable role in robotics for analysis and long-term storage, its lack of suitability for real-time recording and message playback excludes it from our search for a recording file format.

• Parquet は、メッセージへのランダム アクセスには適しておらず、再生用に最適化されていない列指向データ ストア
• Parquet はロボット工学において分析や長期保存に重要な役割を果たすことができるが、リアルタイムの記録やメッセージの再生には適していないため、記録ファイル形式の検索からは除外されている

Next Steps

By comparing existing robotics recording formats with generic big data container formats, we can see there are practical advantages to designing a recording format specific to the robotics use case. However, none of the existing recording formats meet all the requirements and desirable traits laid out in this document. Many of the proposed approaches (rosbag2 SQLite, Avro with opaque buffer) follow an anti-pattern of using an existing schema-based format but only storing opaque binary blobs, negating the promise of interoperability from using an existing format. In light of this evaluation, I would like to propose a file format tailored to the requirements of robotics recording. I will introduce this file format in a follow-up proposal. The
goal is to continue collecting requirements and desirable traits and collaboratively craft an industry standard backed by multiple implementations.

• 既存のロボット記録形式と一般的なビッグデータ コンテナ形式を比較すると、ロボットの使用事例に特化した記録形式を設計することには実用的な利点があることがわかる
• ただし、既存の記録形式のいずれも、このドキュメントに記載されているすべての要件と望ましい特性を満たしていない
• 提案されているアプローチの多く (rosbag2 SQLite、不透明バッファ付き Avro) は、既存のスキーマベースの形式を使用するものの不透明なバイナリ BLOB のみを保存するというアンチパターンに従っており、既存の形式を使用することで得られる相互運用性の約束を無効にしている
• この評価を踏まえ、ロボット工学の記録要件に適したファイル形式を提案したいと思う。
• 目標は、要件と望ましい特性を継続的に収集し、複数の実装に裏付けられた業界標準を共同で作成すること

Concepts

下記を基に整理します。

MCAP organizes its data via messages, channels, and schemas.

• MCAP は、メッセージ、チャネル、スキーマを介してデータを整理する

Message

The unit of communication between nodes in the pub/sub system.

• パブリッシュ/サブスクライブ システム内のノード間の通信の単位

Channel

A stream of messages which have the same type, or schema. Often corresponds to a connection between a publisher and a subscriber.

• 同じタイプまたはスキーマを持つメッセージのストリーム
• 多くの場合、パブリッシャーとサブスクライバー間の接続に対応します

Schema

A description of the structure and contents of messages on a channel, e.g. a Protobuf Schema or JSON Schema.

• チャネル上のメッセージの構造と内容の説明 (例: Protobuf スキーマまたは JSON スキーマ)

MCAP Format Specification

下記を基に整理します。

Overview

MCAP is a modular container file format for recording timestamped pub/sub messages with arbitrary serialization formats.
MCAP files are designed to work well under various workloads, resource constraints, and durability requirements.
A Kaitai Struct description for the MCAP format is provided at mcap.ksy.

• MCAP は、任意のシリアル化形式でタイムスタンプ付きの pub/sub メッセージを記録するためのモジュラー コンテナ ファイル形式
• MCAP ファイルは、さまざまなワークロード、リソース制約、および耐久性の要件で適切に機能するように設計されている
• MCAP 形式の Kaitai 構造体の説明は、mcap.ksy で提供されている

考察

今回は、MCAPについて基礎的な概念を整理してみました。次回以降は実際に触ってみます

参考