CPU で実行されるユーザー定義関数は、ほかの部分が GPU で高速化された Apache Spark クエリを中断させることがあります。cuDF プラグインは通常、任意の UDF コードを変換できません。列形式データを行に変換して CPU で関数を実行し、結果を列形式に戻します。 NVIDIA が 10 月 13 日に公開したガイド では、UDF を Spark SQL、列指向の RapidsUDF、または CUDA による RapidsUDF に書き換えるエージェントスキルを説明しています。データエンジニアが確認すべきなのは、書き換え後も同じ答えが得られ、該当する実行計画で GPU 上にとどまり、実際のジョブが改善するかどうかです。
これはドキュメントに基づくガイドです。BIG CHANGE はこれらのスキルを実行したり、UDF をテストしたり、Spark ワークロードを測定したりしていません。
大きな変化
- 何が変わったか： NVIDIA は、UDF テストの生成、関数の変換、変換結果の評価、CPU と GPU の実装のベンチマーク、必要に応じた cuDF 実装の最適化を行う段階的なエージェントワークフローを公開しました。
- 対象となる人： GPU 対応の RAPIDS/cuDF Spark パイプラインを使い、それを妨げている特定の CPU UDF があるエンジニア。
- 確認すべきこと： 代表的なエッジケースで出力が一致すること、対象の CPU フォールバックを含まない実行計画、そして実際のハードウェアで再現可能なジョブレベルの性能。
始める前に
コーディングエージェントに共有する権限がある UDF を 1 つ選びます。エージェントとその実行環境が承認済みでない限り、認証情報、機微な入力行、専有データセットをプロンプトに含めないでください。UDF のソース、登録と呼び出し箇所、関連スキーマ、期待される null とエラーの動作、小規模で許可されたテストデータを用意します。比較の基準として、既存 Spark ジョブの実行計画と所要時間も記録してください。
この スキルの README はワークフローのバージョン管理された出発点です。UDF のビルドには Maven と JDK が必要で、互換性のある Spark/RAPIDS/cuDF/CUDA 環境と GPU も必要だとしています。導入前に、 現在のプラグイン互換性ガイド を自分の Spark 配布版、Scala バージョン、ドライバー、CUDA ビルド、GPU と照合してください。クラウド GPU はローカル機材の代わりになりますが、インスタンス利用時間とストレージの料金が発生します。エージェントやモデルの利用にも費用がかかる場合があります。README のひな形や例だけでは、クラスターの互換性や性能は確認できません。
関数を 1 つずつ書き換えて確認する
- 元の動作を固定する。 選択した UDF についてエージェントに
udf-gen-testを使わせ、生成されたテストを自分で確認します。契約に沿った実例を追加してください。必要に応じて null、空文字や空コレクション、不正な入力、境界値、数値精度、順序、エラー動作を含めます。元の UDF で実行し、基準となるテストが通ることを確認します。まだ書き換えには進みません。NVIDIA の温度関数の例は null 入力に null を返しますが、SQL への書き換えが有効なのは、その動作が実データ型と Spark 設定でも保たれる場合だけです。 - 対応が確認できる最も単純な方法を選ぶ。 Spark SQL や DataFrame 式で表現できるロジックなら、
udf-convert-to-sqlを依頼します。式が Spark のプランナーに見えるため、プラグインが対応する演算を GPU 用に置き換えられる可能性があります。SQL で必要なロジックをきれいに表現できない場合は、udf-convert-to-cudfを依頼します。そのRapidsUDF.evaluateColumnarは GPU の列ベクトルを受け取り、cuDF 演算を組み合わせます。udf-convert-to-cudaは JNI 経由のカスタムカーネルが必要で、追加の実装と保守の負担に見合う場合に限ります。どの演算も GPU で動く保証ではなく、比較検討する選択肢です。 - 変換を確認してから受け入れる。 書き換えた実装を元の実装と比べ、同じ承認済みテストケースで両方を実行します。リポジトリには、テスト漏れや変換の不具合を別途確認するための
udf-judge-conversionもあります。型、null の伝播、丸め、例外、順序、リソース管理を確認してください。cuDF への書き換えでは、一時列の寿命も調べます。 チュートリアルの Scala の例 はスコープ管理されたリソースを使い、結果列を返します。生成テストが通ることは有用な証拠ですが、関数の契約を十分に網羅しているかは人が判断する必要があります。 - 実行されたプランを調べる。 cuDF プラグインを有効にして変更後のクエリを実行し、対象オペレーターと前後の変換について、プランと RAPIDS 診断を確認します。NVIDIA の プラグイン概要 によると、未対応の SQL 演算は Spark CPU にフォールバックします。プラン上で UDF や周辺オペレーターがまだ CPU にある場合は、未対応の式や型を特定し、方式を見直してください。テスト結果と併せて変更前後のプランを保存します。クラス名に
RapidsUDFが含まれるだけでは、ジョブ全体が GPU で実行された証明になりません。 - 実際に実行するジョブをベンチマークする。 同じ入力、クラスター規模、構成、測定方法で元の実装と変更後を比較するために
udf-benchmarkを使います。ジョブの経過時間、入力サイズ、出力の一致、GPU/CPU 使用量を記録します。起動、キャッシュ、競合の影響を見分けるため、複数回実行してください。正しい cuDF 版が遅い場合、リポジトリのudf-optimize-cudfでプロファイルと修正ができます。変更のたびに正しさとプランを再確認します。書き換えが遅くても、再現できる比較結果を得ることが目標です。
成功した結果の目安
選んだ UDF が承認済みケースで文書化された動作と一致し、実行計画から対象の CPU フォールバックがなくなり、代表的なベンチマークでエンドツーエンドの改善が確認できれば、通常のコードレビューに進めます。いずれかの確認に失敗したら元の実装を維持し、失敗した式に書き換えを絞ってその段階をやり直します。ベンチマークが速くなっても意味が変われば採用できません。プランが変わらなければ、意図した GPU 経路は確認できていません。
NVIDIA は本番環境の例を 1 件報告しており、cuDF 対応 UDF により 6,000 億行のワークロードでオペレーターの処理時間が 274.55 時間から 12.78 時間へ短縮した としています。これはそのワークロードにおけるベンダー報告のオペレーター時間であり、別の UDF やジョブ全体の予測ではありません。22 倍というより広い主張も、この文脈で捉える必要があります。GPU の容量、データ移動、未対応演算、コードレビュー、クラウド料金によって、自分のパイプラインの結果は変わります。
出典と参考資料
- NVIDIA Technical Blog、2026 年 10 月 13 日：CPU フォールバック、SQL/cuDF/CUDA の選択肢、4 段階のワークフロー、企業が引用した唯一の性能例を説明しています。性能値はベンダー報告です。
- NVIDIA cuDF Spark skills、固定されたリポジトリリビジョン：ひな形と個別スキルのバージョン管理された入口です。固定版 GitHub ページには取得経路からアクセスできませんでした。ワークフローの詳細は NVIDIA のチュートリアルとリポジトリ主ブランチの参照可能なスキル README と照合しました。
- Apache Spark 向け cuDF プラグイン概要：現在の設定と互換性に関する情報、および未対応の演算は Spark CPU で実行するという明示的な規則です。実装前にリリースごとの互換性一覧を確認してください。
