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のホワイトペーパー
ビッグデータとAIのトレンドに関するCanonicalのホワイトペーパー

Pure StorageとCanonical LXDのネイティブ統合が可能に

Pure Storageは、エンタープライズグレードのオールフラッシュストレージを提供する先駆的なIT企業です。Ubuntuの発行元であるCanonicalとの提携により、LXDとPure Storage FlashArrayのネイティブ統合が実現しました。これによって企業はオープンソースの仮想化と業界をリードするブロックストレージを組み合わせ、LXDのみでも、Canonical MicroCloud全体でも、優れたパフォーマンス、シンプルさ、信頼性を備えたインフラストラクチャが得られます。LXDは、Pure Storage APIバージョン2.21以上（Purity//FAバージョン6.4.2以上に対応）をサポートしています。 Pure Storage FlashArr […]

Ubuntu CoreがMediaTek Genioに対応

CanonicalとMediaTek Inc.の戦略的パートナーシップに基づき、初めてMediaTekのGenio 350、510、700、1200プラットフォーム向けにUbuntu Coreイメージを最適化。本日、Ubuntuを提供するCanonicalとMediaTekは、MediaTekのGenioプラットフォーム向けに最適化された初のUbuntu Coreイメージを正式にリリースすることを発表しました。今回リリースの最適化されたイメージにより、MediaTek Genio 350、510、700、1200向けのUbuntu Coreをダウンロードし、IoT開発の出発点として活用できるようになります。MediaTekのGenioプラットフォームでUbuntu Co […]

コンテナイメージのセキュリティをソースで管理する

ソフトウェアサプライチェーンのセキュリティは、開発者やDevOpsエンジニア、さらにはIT責任者にとって最大の関心事です。セキュリティ侵害や依存ファイル侵害の大事件からわかるように、適切な検証と保守のないオープンソースコンポーネントはリスクの源となります。近年の開発とデプロイではコンテナ化が一般的な手法ですが、再現性とセキュリティの面に弱点があります。コンテナには、簡単に導入できるだけでなく、安全で繰り返し使用でき、長期的なメンテナンスで新たな脅威に対応することが求められています。このことからCanonicalはコンテナ構築サービスの提供を開始しました。オープンソースが抱えるセキュリティの課題企業環境では、オープンソースソフトウェア（OSS）の利用が広がっています。 […]