Apache DataFusion CometがIceberg Rustの検証とSpark高速化を両立

Apache Icebergプロジェクトは、Apache DataFusion CometがSparkの物理実行計画をRustへ移し、Iceberg Javaの計画機能とIceberg Rustの読み取りを組み合わせる取り組みを紹介しました。

要点

• CometはSparkの物理計画を横取りし、対応部分をApache DataFusionのRust実装で実行します。
• 3TBのTPC-DSで102/103クエリを高速化し、全体で約40%速くなったと報告しています。
• 書き込みは高速化の対象外で、Iceberg format v3など未対応機能はSparkへ戻します。
• Iceberg Javaの約1万件のSpark試験を差分試験に使い、Iceberg Rustとの互換性問題を見つけています。

今回のブログ記事で語られていること

CometはSpark SQLのすべてを置き換えるエンジンではありません。Sparkが作った物理実行計画を確認し、対応できる演算をApache ArrowとDataFusionのRust実装で処理します。Icebergテーブルについては、Iceberg Javaが担う計画やメタデータ処理を残し、データファイルの読み取りへIceberg Rustを使います。未対応の演算や形式ではSpark側へ戻るため、既存のSparkアプリケーションを保ちながら段階的に高速化できます。3TBのTPC-DSでは103本中102本が高速化され、全体で約40%短縮したと報告されています。

記事のもう一つの中心は、性能より互換性検証です。Apache Iceberg Javaには長年蓄積されたSpark向け試験が約1万件あります。Cometから同じ試験をIceberg Rust経由で実行し、Java実装と結果を比較することで、Rust側が仕様を正しく実装しているかを広い条件で確認できます。この差分試験からIceberg RustだけでなくIceberg Java側の問題も見つかり、40件を超える修正が上流プロジェクトへ還元されたとしています。新実装の検証を既存実装の試験資産へ接続する方法として価値があります。

制約も明確です。記事時点で書き込み処理はCometによる高速化の対象外で、format v3はSparkへ戻ります。読み取りが速くても、更新、削除、merge、comp操作を含む一連の処理が同じ速度になるわけではありません。導入時は自社のクエリでCometに移った演算とフォールバックした演算を確認し、結果の一致、メモリ、シャッフル、障害時の挙動を測る必要があります。ベンチマーク値は利用データ、クラスタ構成、キャッシュによって変わるため、約40%を一般的な保証として扱うべきではありません。

今回のブログ記事が関係する人

SparkとIcebergを運用するデータ基盤担当、Rust版Icebergへ貢献する開発者、DataFusionを使う実行エンジン開発者に関係します。

結局、今回のブログ記事をどう読むべきか

Spark高速化の報告であると同時に、成熟したJava実装の試験をRust実装へ再利用する品質改善の事例です。採用側は速度だけでなく、フォールバック範囲と結果一致を自社の読み書きパターンで確認してください。