# OTel-Arrow ## 定義 OTel-Arrow は [[OpenTelemetry]] の SIG（Special Interest Group）として開発されているサブプロジェクトで、[[Apache Arrow]] のカラム型インメモリフォーマットをテレメトリデータ(トレース・メトリクス・ログ)の転送・処理に応用する。Phase 1 では [[OTAP]]（OpenTelemetry Arrow Protocol）ワイヤプロトコルを定義し、Phase 2 では Arrow をパイプライン全体の内部表現として採用した Dataflow Engine（Rust 実装）を構築する。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ### Phase 1 と Phase 2 | Phase | 内容 | 到達点 | |---|---|---| | Phase 1 | [[OTAP]] をワイヤプロトコルとして定義 | 効率的なトランスポート | | Phase 2 | Arrow をパイプライン全体の内部表現として採用 | Dataflow Engine（インキュベーション段階） | ### Dataflow Engine の設計原則 - **NUMA-フレンドリー・スレッドパーコア・シェアードナッシング**アーキテクチャ - 有界チャンネル(bounded channel)による明示的なバックプレッシャー - 同期処理のホットパス回避 - 飽和時にメモリ使用量を有界に保つ（既存 Collector OTLP パスとの主な差別化点） ### コストモデルの変化 行指向の OTLP ベースパスでは、テレメトリデータはヒープ割り当てされたオブジェクトグラフとして実体化され、ガベージコレクションが必要となる。OTel-Arrow では Arrow のカラム型表現をパイプライン全体で維持することで、「デコード・オブジェクトウォーク・アロケーション・エンコード」にかかるシリアライゼーションオーバーヘッドを大幅に削減できる。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ### ベンチマーク結果（抜粋） - 単一コア: OTAP 2.47M logs/sec 対 OTLP 121K logs/sec（**20× スループット**） - 16コア OTLP: 14.6× のスピードアップ（理想値 16× に対してほぼ線形） - 変換処理（200K logs/sec）: OTAP は CPU 6.4〜6.6%、Collector OTLP は 92.5% (Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) ## 横断的知見 - 現時点では単一ソース（[[@2026__OTelBlog__OTel-Arrow-Phase-2]]）のみ。複数ソースとの突き合わせによる横断知見は今後蓄積する。 - バッチサイズが大きいほど OTAP の CPU 効率が向上する（256 → 4096 で CPU 21% → 7.8%）。これはカラム型フォーマットの圧縮特性と一致しており、[[Apache-Arrow]] のバッチ処理設計原則と整合する。 ## 未解決の問い - Phase 2 の Dataflow Engine はいつ本番安定版になるか？設定フォーマット・API のロードマップはどこに記載されているか？ - OTAP を採用するにあたり、既存の OpenTelemetry Collector 設定からの移行コストはどの程度か？ - 他のテレメトリ処理フレームワーク（例: OpenTelemetry Collector、Apache Flink 等）と比較した場合のトレードオフは？ - ログ以外のシグナル（トレース・メトリクス）でも同様のスループット向上が見込めるか？ ## 関連 - プロトコル: [[OTAP]] - エンティティ: [[OpenTelemetry]] / [[Apache-Arrow]] - 概念: [[テレメトリ]] / [[オブザーバビリティ]] - ソース: [[@2026__OTelBlog__OTel-Arrow-Phase-2]] ## 出典 - [[@2026__OTelBlog__OTel-Arrow-Phase-2]]