# OTAP ## 定義 OTAP（OpenTelemetry Arrow Protocol）は [[OTel-Arrow]] SIG が定義したワイヤプロトコルで、[[Apache Arrow]] のカラム型フォーマットを用いてテレメトリデータ（トレース・メトリクス・ログ）を転送する。[[OpenTelemetry]] の既存プロトコルである OTLP（OpenTelemetry Protocol）が行指向のProtobuf エンコーディングを使うのに対し、OTAP はカラム型バッチ転送により大幅なスループット向上を実現する。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ### OTLP との比較 | 項目 | OTLP | OTAP | |---|---|---| | データ形式 | 行指向（Protobuf） | カラム型（Apache Arrow） | | 単一コアスループット | 121K logs/sec | 2.47M logs/sec（**20× 差**） | | 変換時 CPU（200K logs/sec） | 92.5%（4 操作後） | 6.4〜6.6% | | バッチサイズ依存性 | 比較的フラット | 大バッチほど効率的 | | 内部表現 | ヒープ割り当てオブジェクトグラフ | コンパクトなカラム型 | ### バッチサイズ特性 OTAP はバッチサイズが大きいほど CPU 効率が向上する。400K logs/sec 処理時の例: - バッチサイズ 256: CPU 21% - バッチサイズ 4096: CPU 7.8% これは Arrow のカラム型圧縮の効果がバッチサイズの増大とともに強まるためと考えられる。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ### Phase 1 における位置づけ OTAP は OTel-Arrow Phase 1 の成果物として定義されたワイヤプロトコルである。Phase 2 では OTAP を利用しつつ、Arrow をパイプライン全体の内部表現として維持する Dataflow Engine を構築することで、転送だけでなく処理段階でもシリアライゼーションオーバーヘッドを排除する。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ## 横断的知見 - 現時点では単一ソース（[[@2026__OTelBlog__OTel-Arrow-Phase-2]]）のみ。複数ソースとの突き合わせによる横断知見は今後蓄積する。 - OTAP のスループット優位性（20×）は、プロトコル変換コストではなく「Arrow のカラム型インメモリ表現をパイプライン全体で維持することによるシリアライゼーション削減」に由来する。これは単にワイヤフォーマットを変えるだけでは不十分であることを意味し、Phase 2 の Dataflow Engine（OTel-Arrow 全体内部表現）との一体設計が重要である。 ## 未解決の問い - OTAP の仕様はどこで公開されているか？RFC や正式ドキュメントは存在するか？ - OTAP は gRPC / HTTP の上に乗るのか、独自のトランスポート層を持つのか？ - 既存の OpenTelemetry Collector は OTAP をレシーバ・エクスポータとしてサポートしているか？ - OTAP と OTLP の相互変換コストはどの程度か？（ゲートウェイで変換する場合のオーバーヘッド） ## 関連 - 上位概念: [[OTel-Arrow]] - エンティティ: [[OpenTelemetry]] / [[Apache-Arrow]] - 概念: [[テレメトリ]] / [[オブザーバビリティ]] - ソース: [[@2026__OTelBlog__OTel-Arrow-Phase-2]] ## 出典 - [[@2026__OTelBlog__OTel-Arrow-Phase-2]]