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を実行する方法は、データサイエンスを加速し、イノベーションを推進する強力な手段となります。

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録


お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

Ubuntu ProをNutanixのベアメタルKubernetesで提供

NutanixとCanonicalのパートナーシップ拡大によりコンテナ化されたワークロードの選択肢が増加 Enterprise Kubernetes®は、柔軟性の高いマルチアーキテクチャモデルへと進化しつつあります。AI/MLやデータ集約型のワークロードが膨大なハードウェアスループットを必要とする近年、組織はクラウドプラットフォームの安定性を維持しながら、ベアメタルのパフォーマンスを求めています。 このためNutanixとCanonicalは、このたび発表されたNKP Metalソリューションも含め、ベアメタルで実行するNKP(Nutanix Kubernetes Platform)インスタンスでもUbuntu Proを利用可能にしました。もともと2025年に発表されたパ […]

Ubuntu 26.04 LTSのセキュリティ最新情報

Ubuntu 26.04 LTSは、Canonicalにとって最もセキュリティを重視したLTSリリースです。単に機能を追加しただけでなく、システムのあらゆる層で同時にセキュリティの基準を引き上げ、全体的に強化しました。しかも既存の環境を壊したり、手動での介入が増えたりすることはありません。セキュリティの心臓部、つまりデフォルト設定に注力することで、CanonicalはUbuntuのセキュリティを新しい形で強化しました。この記事では、Ubuntu 26.04 LTSの新しいセキュリティ機能について概説します。 Ubuntu 26.04 LTS は、デスクトップ、サーバー、コンフィデンシャルVM、クラウドイメージ、エッジシステムでLinuxを運用する上で、今後10年間にわたっ […]

JammyからResoluteまで:Ubuntuのツールチェーンの進化

新しいツールチェーンのバージョン、devpack、開発体験を改善するワークフローをご紹介します。 Ubuntuのツールチェーンの進化は、単にGCC、LLVM、Pythonを提供することではありません。明確な目的を持つOpenJDKのバリアント、タスクに特化したdevpack、FIPS適合のツールチェーン、そしてsnap(新しい.NET snapやSnapcraftプラグインなど)の開発も含みます。このような改善により、これまで半日かかっていたセットアップが1〜2個のコマンドで済みます。これは、Ubuntu上でフレームワークやアプリケーションを開発する者にとって、まさに「摩擦のない」開発体験です。 このブログでは、Ubuntuの過去4年間のLTSリリースにおける変更点と今後 […]