Apache SparkとGPUでデータサイエンスを加速する
by Canonical on 26 August 2025

Apache Sparkは、演算処理をパーティション単位で複数のノードに分散させることで知られています。そしてCPUコアは常に単一のパーティション内で処理を実行してきました。
しかし、SparkをGPUで高速化できることは、あまり知られていません。このGPUの力を適切な状況で活用することには大きなメリットがあります。インフラストラクチャのコストとサーバー数を削減しながら、従来のCPU処理の最大7倍の速度でクエリを処理し、結果を出せます。しかも、すべてバックグラウンドで処理し、既存のSparkアプリケーションコードに変更を加える必要はありません。Canonicalのチームは、実際の大規模なデータ処理におけるパフォーマンスボトルネックを解消する機能を開発しました。それがNVIDIA RAPIDSアクセラレータを使用したSparkに対するGPUサポートです。
このブログ記事では、GPUがSparkにどのように役立ち、どのような仕組みで作用するのか、どのような場合にはGPUを選択すべきでないかを説明します。そしてGPUでSparkジョブを起動する手順をご紹介します。
データサイエンティストがSparkとGPUに注目すべき理由
Apache SparkをGPU上で実行すれば、GPU特有の強みを活用して、ビッグデータ分析やワークロードを高速処理できる大きな可能性があります。
従来のCPUが少数のコアでシーケンシャル処理を実行するのに対し、GPUは数千個の小型の省電力コアで構成され、数千もの並列スレッドを同時に実行できます。このようなアーキテクチャの違いから、Sparkのワークロードでよく見られる高度に分散されたオペレーションには、GPUのほうが適しています。そのようなオペレーションをGPUにオフロードすることで、Sparkのパフォーマンスは大幅に向上し、CPUのみの環境と比較してクエリ実行時間が大幅に短縮されます。データコンピューティングは、2倍から7倍高速化されるのが一般的です。これにより分析情報を得るのにかかる時間が大幅に短縮され、顕著な違いが生まれます。
この点において、Apache SparkのGPUアクセラレーションは、従来の分析からAIアプリケーションへの移行を進めるデータサイエンティストにとって大きなメリットとなります。標準的なSparkのワークロードはCPUコアを集中的に使用し、分散型という性質から非常に強力な計算能力を発揮しますが、AIを活用した分析ワークロードを管理する場合は、十分なパワーとはいえない可能性があります。
一方、GPUを利用することで、より大規模なデータを効率的に処理できるため、高速な作業が実現します。そのため、反復処理も高速になり、よりインタラクティブなデータ探索が可能になるため、ほぼリアルタイムで実用的な分析情報を提供できるようになります。これは、迅速な意思決定が求められる今日の環境において非常に重要です。
GPUアクセラレーションにより速度が向上するだけでなく、データエンジニアリングと機械学習のワークロードが単一プラットフォームに統合されるため、データサイエンスのワークフローが簡素化されます。SparkとGPUアクセラレーションを組み合わせることで、データ準備、フィーチャーエンジニアリング、モデルトレーニング、そして推論を単一の環境で効率的に実行できます。個別のインフラストラクチャやシステム間の複雑なデータ移動は必要ありません。ワークフローの統合により、運用上の複雑さが軽減され、エンドツーエンドのデータサイエンスプロジェクトが高速化されます。
GPU上でSparkを使用する3つ目の大きなメリットは、運用コストの削減です。GPUはマシンあたりのスループットが高いため、サーバー数を減らしながら同等以上の成果が得られます。そのためコストが抑えられ、消費電力も削減されます。これによりビッグデータ分析が低コストかつ持続可能なものとなり、企業にとっての重要性が増すと期待されます。
最後のメリットは、NVIDIA RAPIDSなどのテクノロジーがSparkとスムーズに統合され、コードの書き換えやワークフローの変更が不要なことです。導入が容易になれば、ユーザーはGPUの能力を簡単に利用し、迅速に価値を提供できます。
従来のCPUを利用すべき場合
GPUによる高速処理は、すべてのSparkワークロードに有益なわけではありません。
たとえば、小規模なデータセットのワークロードの場合、GPUは効率的とはいえません。これは、GPUとCPUメモリ間のデータ転送によるオーバーヘッドが、GPUアクセラレーションによるパフォーマンスの向上から得られるメリットを上回る可能性があるためです。小規模なワークロードでは、きめ細かな並列処理にGPUの強みが活かされません。同様に、クラスター内で常にデータシャッフルが発生するワークロードにもあまり適しません。これは、シャッフルによってCPUとGPUメモリ間でのデータ移動コストが増大し、実質的にオペレーションの速度が低下するためです。
CPUを利用すべき状況としてはそのほかに、Sparkジョブがユーザー定義関数に大きく依存していて、そのようなユーザー定義関数がGPUでの実行をサポートしていない、またはGPUでの実行に最適化されていない場合が挙げられます。
同様に、ワークロードがResilient Distributed Datasets(RDD)を直接操作する必要がある場合も、GPUは最適な選択肢とはいえない可能性があります。これは、現在のところRAPIDS Acceleratorがこのようなワークロードを処理できず、CPUで実行されるためです。最後に、環境がGPUアクセラレーションのハードウェア要件と構成要件を満たすことも重要です。
特定の環境でGPUアクセラレーションを有効に活用できるかどうかを確認するため、ワークロードの慎重なプロファイリングとベンチマーク測定をおすすめします。
GPUを使ってSparkジョブを起動する方法
Apache Sparkに対応するCanonicalのチャームはクラスターマネージャーにKubernetesを使用するため、Apache SparkでGPUを有効化するには、Podとコンテナを使用する必要があります。
まず、Apache Spark RAPIDSプラグインをサポートするCharmed Apache SparkのOCIイメージをデプロイします。こちらのガイドで手順をご覧ください。
デプロイが完了し、最初のジョブを起動する準備ができたら、コンテナあたりのGPU数を制限するPodテンプレートを作成します。これには、Podのマニフェストファイル(gpu_executor_template.yaml)を編集して、以下の内容を追加します。
apiVersion: v1
kind: Pod
spec:
containers:
- name: executor
resources:
limits:
nvidia.com/gpu: 1
spark-client snapを使用すると、GPUアクセラレーションを有効にするいくつかの構成オプションを追加して、目的のSparkジョブをサブミットできます。
spark-client.spark-submit \
... \
--conf spark.executor.resource.gpu.amount=1 \
--conf spark.task.resource.gpu.amount=1 \
--conf spark.rapids.memory.pinnedPool.size=1G \
--conf spark.plugins=com.nvidia.spark.SQLPlugin \
--conf spark.executor.resource.gpu.discoveryScript=/opt/getGpusResources.sh \
--conf spark.executor.resource.gpu.vendor=nvidia.com \
--conf spark.kubernetes.container.image=ghcr.io/canonical/charmed-spark-gpu:3.4-22.04_
edge\
--conf spark.kubernetes.executor.podTemplateFile=gpu_executor_template.yaml
…
spark-client snapを使用すると、Apache Sparkの設定をサービスアカウントレベルで構成できるため、すべてのジョブに自動的に適用できます。サービスアカウントレベルでオプションを管理する方法については、こちらのガイドをご覧ください。
SparkとGPU:まとめ
NVIDIA RAPIDSを使ったGPUアクセラレーションにより、コードの変更なしにApache Sparkのパフォーマンスが大幅に向上し、データ処理の高速化とコスト削減が実現します。つまり、大規模なデータセットや複雑なモデルをこれまで以上に効率的に処理し、これまでよりも迅速に分析情報を生成できるということです。ただし、すべてのワークロードが同じように恩恵を受けられるわけではありません。データセットが小規模な場合、データシャッフルが過剰に発生する場合、あるいはサポートされていない関数を使用する場合は、GPUのメリットが制限されてしまう可能性があります。GPUが費用対効果の高い選択肢となるかどうかを判断するには、慎重なプロファイリングが必要です。ただし総じて評価すれば、GPU上でSparkを実行する方法は、データサイエンスを加速し、イノベーションを推進する強力な手段となります。
ニュースレターのサインアップ
関連記事
Canonical、Ubuntu Pro for WSLを発表
Windows環境におけるUbuntu 24.04 LTSのWSLインスタンスにセキュリティメンテナンスとエンタープライズサポートを一括して提供。包括的なシステム管理機能も利用できるサブスクリプションサービス。 Canonicalは本日、Ubuntu Pro for WSLの一般提供を発表しました。Microsoftストアからインストール、ソースコードとベータ版はGitHubからダウンロード可能です。 「CanonicalとMicrosoftは、緊密なパートナーシップを通じてWSLの各種機能を構築しています。この取り組みは、WSLを利用して実運用向けのLinuxソリューションを構築する企業の開発者に有益です。」 Microsoft、WSLプロダクトマネージャー、Craig […]
バックポートでパッケージのサポート終了を回避
2025年7月、Gitは危険度の高い脆弱性「CVE-2025-48384」の報告を受けました。攻撃者がこの脆弱性を悪用すれば、リポジトリのクローンを作成する際に任意のコードを実行できます。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は、この脆弱性の実際の悪用事例を確認後、Known Exploited Vulnerabilities(KEV、悪用が確認されている脆弱性)のカタログに追加しました。 この脆弱性の公開時に標準サポート終了を過ぎていたユーザーにとって、選択肢は2つでした。Ubuntu Proのサブスクリプションでセキュリティパッチを入手するか、開発者の作業環境やCI/CDインフラに既知のリモートコード実行(RCE)脆弱性を抱えたまま […]
Canonical、FIPS対応のKubernetesを公開
FIPS 140-3暗号化とDISA-STIGハードニングを備えた、FedRAMP対応のKubernetesクラスターとアプリケーションスイートを導入しましょう。 本日、KubeConにおいて、Ubuntuを提供するCanonicalは同社のKubernetesディストリビューションでFIPSモードを有効化するためのサポートを公開しました。これにより、高いセキュリティの導入や連邦政府向けの導入に適したスケーラブルなクラスターの構築と管理に必要なすべての要素を提供します。バージョン1.34以降、Canonical Kubernetesは認証済みの暗号モジュールを使用した内蔵FIPS 140-3機能とともに使用できます。このFIPS機能を備えた導入により、snapパッケージと […]