# OTel-Arrow Phase 2: From Efficient Transport to Efficient Telemetry Pipelines **出典**: [OTel Blog 2026](https://opentelemetry.io/blog/2026/otel-arrow-phase-2/) ## 概要 [[Apache Arrow]] のカラム型フォーマットを、ワイヤ転送（Phase 1）だけでなくテレメトリパイプライン全体の内部表現として採用することで、大幅な効率化を達成できることを示したブログ記事。OTel-Arrow SIG が開発した Dataflow Engine (DFE) の設計と初期ベンチマーク結果を報告する。 ## Dataflow Engine(DFE)の設計 DFE は「NUMA-フレンドリー、スレッドパーコア、シェアードナッシング」アーキテクチャを採用する。有界チャンネル(bounded channel)、同期処理のホットパス回避、明示的なフロー制御を重視する。実装言語は Rust。 バックプレッシャー(back-pressure)によって飽和時のメモリ使用量を有界に保つ。これは既存の OpenTelemetry Collector の OTLP パスが飽和時にメモリ使用量が急増し、スループットが劣化するのと対照的である。 ## ベンチマーク結果 **テスト環境**: - 主システム: Intel Xeon Platinum 8581C（16コア、118 GiB RAM） - スケーリングシステム: 64コア Intel Xeon 8358（2ソケット、1 TB RAM） - OS: Debian GNU/Linux 12 **変換ベンチマーク（200K logs/sec、属性リネーム操作 1〜4 回）:** - [[OTAP]] ネイティブパス: CPU 6.4〜6.6% - DFE の OTLP パス: 初回変換後は増分コストが軽微 - Collector の OTLP パス: 4 操作後に CPU 92.5% **バッチサイズの影響（400K logs/sec）:** - OTAP: バッチサイズ 256 → CPU 21%、4096 → CPU 7.8%（大バッチほど効率的） **スケーリング（16コア）:** - OTLP スループット: 1.91M logs/sec（14.6× のスピードアップ、理想値 16×） **シングルコア比較:** - OTAP パス: 2.47M logs/sec - OTLP パス: 121K logs/sec（**20× 差**） ## Arrow がコストモデルを変える理由 行指向の OTLP ベースパスでは、テレメトリデータはヒープ割り当てされたオブジェクトグラフとして実体化され、ガベージコレクションが必要となる。Arrow バッチはコンパクトなカラム型表現でメモリ局所性に優れる。 **問題**: テレメトリ量の増大により、属性リネーム・フィールドエンリッチメント・ルーティング等の変換処理が増加している。現状の OTLP パスでは処理コストの大部分がシリアライゼーションオーバーヘッドに支配されており、変換ロジック本体よりも「デコード・オブジェクトウォーク・アロケーション・エンコード」にコストがかかる。 **解決策**: Arrow のカラム型表現をデータパイプライン全体で維持することで、実際の変換を囲む「デコード・オブジェクトウォーク・アロケーション・エンコード」の作業を削減できる。 ## Phase 1 と Phase 2 の整理 | Phase | 概要 | |---|---| | Phase 1 | OTel-Arrow を効率的なトランスポートとして活用（OTAP ワイヤプロトコル） | | Phase 2 | Arrow をパイプライン全体の内部表現として採用（Dataflow Engine） | ## 現在の成熟度 Dataflow Engine はインキュベーション段階(incubation-stage)。基本的な機能は利用可能だが、本番環境での安定性は保証されない。設定フォーマット・API・運用上のセマンティクスは変更される可能性がある。 ## 関連コミュニティ - GitHub ディスカッション - `#otel-arrow` Slack チャンネル - OpenTelemetry SIG-Arrow ミーティング ## 関連 - 概念: [[OTel-Arrow]] / [[OTAP]] / [[テレメトリ]] - エンティティ: [[OpenTelemetry]] / [[Apache-Arrow]]