Apache Spark

Apache Sparkとは

Apache Sparkは、大規模データを複数のマシンに分散させて並列処理する統合分析エンジンです。もっとも大きな特徴は、処理の途中結果をディスクではなくメモリ上に保持できる点にあります。Hadoop MapReduceは各処理ステップの結果を都度ディスクに書き出すため、反復計算（機械学習の学習ループなど）ではディスクI/Oがボトルネックになりやすい構造でした。Sparkはこの弱点を解消する目的でUCバークレー校のAMPLab（Matei Zaharia氏らが中心）で2009年ごろに開発が始まり、2010年にオープンソース化、2013年にApache Software Foundationへ寄贈されて以降、Apacheのトップレベルプロジェクトとして開発が続けられています。

「統合」という言葉が示すとおり、Sparkは単なるバッチ処理基盤ではありません。SQLライクなデータ処理（Spark SQL）、ストリーミング処理（Structured Streaming）、機械学習（MLlib）、グラフ処理（GraphX）を、同一のクラスタ・同一のAPI体系の上でまとめて扱えることが最大の価値です。データエンジニアリング・データサイエンス・アナリティクスという異なる職種が同じ基盤を共有できるため、Hadoopエコシステム全盛期に乱立していた「用途ごとに別々のツールを組み合わせる」という運用の複雑さを大きく減らしました。実務では、AWS Glue、Amazon EMR、Google Cloud Dataproc、Databricks、Azure Synapse AnalyticsといったマネージドサービスでSparkを動かすケースが大半で、自前でクラスタを一から構築・運用する機会は年々減っています。

仕組み・詳細解説

RDDとDAG実行モデル

Sparkの内部データ表現の基本単位はRDD（Resilient Distributed Dataset）です。RDDは複数ノードに分割されたイミュータブル（不変）なデータコレクションで、ノード障害が起きても「どのデータからどう変換されたか」という系譜（lineage）情報をもとに再計算できるため、耐障害性を確保しています。Sparkはmapやfilterのような変換（Transformation）を呼び出した時点では実際の計算を行わず、collectやsaveなどの実行（Action）が呼ばれた瞬間にまとめて実行計画（DAG：Directed Acyclic Graph）を構築して処理を開始します。この「遅延評価（Lazy Evaluation）」により、不要な中間結果の計算を省き、複数のステップをまとめて最適化してから実行できます。

Catalyst OptimizerとTungsten実行エンジン

Spark SQLおよびDataFrame/Dataset APIを使う場合、記述したクエリはCatalyst Optimizerと呼ばれる最適化器を通ります。述語のプッシュダウンや不要なカラムの削除、結合順序の入れ替えなどを自動で行うため、開発者が細かいチューニングを書かなくても効率的な実行計画を得やすいのが特徴です。さらに実行段階ではTungstenエンジンがオフヒープメモリ管理やバイトコード生成（whole-stage code generation）を担い、JVM上でのオブジェクト生成コストを抑えて処理速度を高めています。

クラスタアーキテクチャ（Driver / Executor / Cluster Manager）

Sparkアプリケーションは、処理全体を統括するDriverプロセスと、実際にタスクを実行する複数のExecutorプロセスで構成されます。DriverはSparkContext（またはSparkSession）を通じてジョブをタスクに分割し、Cluster Manager経由で各Executorに配布します。Cluster ManagerにはSpark単体で動くStandaloneモードのほか、YARN、Kubernetesが選択肢になります。コンテナ運用が主流になったこともあり、Kubernetes上でSparkを動かす構成（Spark on Kubernetes）を採用する現場が増えています。

パーティショニングとシャッフル

Sparkは入力データを「パーティション」という単位に分割し、各パーティションを別々のExecutorタスクとして並列処理します。groupByやjoin、repartitionのようにパーティションをまたいでデータを再配置する操作は「シャッフル」と呼ばれ、ネットワーク転送とディスクI/Oを伴うためSparkジョブの性能劣化要因の大半を占めます。実務のチューニングでは、パーティション数の調整（spark.sql.shuffle.partitionsの設定値見直し）、ブロードキャスト結合（小さいテーブルを各Executorに配って結合コストを避ける手法）、キー分布の偏り（データスキュー）対策が定石とされています。

具体例・ユースケース

Sparkは「大量データを一定間隔でまとめて処理する」用途と「継続的に流れてくるデータをほぼリアルタイムで処理する」用途の両方で使われます。代表的な適用例は次のとおりです。

• ETLバッチ処理：S3やHDFS上に蓄積された数百GB〜数TB規模のログ・トランザクションデータを日次・時間次でクレンジング・集計し、Amazon RedshiftやBigQuery、Snowflakeなどのデータウェアハウスに投入する。
• リアルタイム異常検知・不正検知：Kafkaから流れてくる決済イベントやアクセスログをStructured Streamingで数秒〜数十秒単位のマイクロバッチとして処理し、閾値超過や異常パターンを検知してアラートを出す。
• レコメンデーション・特徴量エンジニアリング：数億件規模の行動ログからMLlibで協調フィルタリング（ALS）やユーザー特徴量を算出し、後段のレコメンドエンジンやMLモデルの学習データを作る。
• ログ分析・アクセス解析：Webサーバーやアプリケーションのログを解析し、エラー傾向やアクセス経路をSpark SQLで集計し、Tableau・Power BI・Looker Studioなどの可視化基盤に連携する。

以下はPySparkでCSVを読み込み、地域別の売上を集計する典型的なコード例です。

from pyspark.sql import SparkSession
from pyspark.sql.functions import sum as spark_sum

spark = SparkSession.builder.appName("SalesAggregation").getOrCreate()

df = spark.read.option("header", True).csv("s3://my-bucket/sales/2026-06/*.csv")

result = (
    df.groupBy("region")
      .agg(spark_sum("amount").alias("total_sales"))
      .orderBy("total_sales", ascending=False)
)

result.write.mode("overwrite").parquet("s3://my-bucket/aggregated/region_sales/")
spark.stop()

このようにSQLに近い記述でDataFrame操作を組み立てられる点が、「使い慣れたSQL・pandas感覚のまま大規模データを扱える」とSparkが評価される理由の一つです。

メリット・デメリット

メリット

• 処理速度：メモリ内処理とCatalyst Optimizerにより、反復計算や複雑な集計処理でHadoop MapReduceより大幅に高速。
• 統合性：バッチ・ストリーミング・SQL・機械学習・グラフ処理を単一エンジンでカバーし、ツールの乱立を防げる。
• 多言語対応：Scala、Java、Python（PySpark）、Rから同じAPI体系を利用でき、データサイエンティストとエンジニアが同じ基盤を共有しやすい。
• エコシステムの厚み：Delta LakeやApache Icebergとの統合、Databricks・EMR・Dataprocなどマネージドサービスの選択肢が豊富。
• スケーラビリティ：数ノードの小規模クラスタから数千ノード規模まで、同じコードのまま水平にスケールできる。

デメリット・注意点

• メモリ消費が大きい：メモリ内処理が前提のため、メモリ不足時はディスクスピル（一時的なディスク退避）が発生し、性能が急激に劣化することがある。
• 学習コスト：分散処理特有の概念（パーティショニング、シャッフル、遅延評価）を理解しないと、意図せず遅いジョブを書いてしまいやすい。
• 小規模データには過剰：数GB程度で収まるデータであれば、pandasやDuckDBなど単一マシンで完結するツールの方がシンプルで速いケースも多い。
• 運用コスト：自前でクラスタを構築・チューニングする場合、監視・障害対応・バージョンアップの継続的な運用負荷が発生する（マネージドサービス利用で軽減可能）。
• レイテンシ：Structured Streamingはマイクロバッチ方式のため、Apache Flinkのような真のイベント単位処理と比べるとミリ秒単位の超低遅延要件には不向きな場合がある。

HadoopとSparkの違い

なお、HadoopとSparkは必ずしも二者択一の関係ではありません。実務では「ストレージ層はHDFSやS3を使い、処理エンジンだけをMapReduceからSparkに置き換える（Spark on YARN、Spark on Kubernetesなど）」という併用構成もよく見られます。Hadoopエコシステムの一部（HDFS、Hive、YARNなど）を土台として残しつつ、処理エンジンの部分だけをSparkにモダナイズするアプローチです。

実務ポイント：導入時の選定基準とコスト

導入前の選定基準

Sparkを採用するかどうかは、「反復的な変換処理やジョインが多いか」「バッチ・ストリーミング・機械学習を同じ基盤で扱いたいか」「既存のHadoop/HDFS資産があるか」を軸に判断します。単純な集計だけであればBigQueryやSnowflakeのようなSQLベースのDWHで完結する場合も多く、あえて分散処理コードを自前で書く必要があるかどうかを最初に見極める価値があります。逆に、複雑な変換ロジックをコードで細かく制御したい、あるいは分析パイプラインの延長線上でMLモデルの学習まで一気通貫で行いたい、といった要件が強いほどSparkの優位性が出ます。

主要な競合・関連ツールとの比較

実務では、「変換ロジックが複雑でコードで制御したい／MLと組み合わせたい」ならSpark、「ミリ秒単位の低遅延イベント処理が必須」ならFlink、「アドホックなSQL分析が中心」ならPrestoやDWHのSQLエンジン、という住み分けが一般的です。

ライセンス・料金体系の概要

Apache Spark自体はApache License 2.0で提供されるオープンソースソフトウェアであり、ソフトウェアライセンス費用は発生しません。実際のコストは主に「どこで動かすか」で決まります。自前でEC2やオンプレサーバーにクラスタを構築する場合はインフラ費用と運用工数のみですが、マネージドサービスを使う場合は処理時間・ノード数に応じた従量課金が主流です。目安として、Amazon EMRは背後のEC2インスタンス費用に加えてEMR自体の利用料が上乗せされる料金体系で、小規模な検証であれば月数千円〜数万円程度、本番の常時稼働クラスタでは月数十万円程度になることも珍しくありません。Databricksはクラスタの計算時間に応じたDBU（Databricks Unit）課金が中心で、こちらも利用量次第で月額コストは大きく変動します。導入時は最初から自前クラスタを構築するのではなく、まずマネージドサービスのサーバーレス機能（EMR Serverless、Databricks SQLサーバーレスなど）で小さく検証し、コストとレイテンシの見合いを確認してから本格導入する進め方が実務では定石です。

2025年の最新動向

• Spark 4.0系のリリース：2025年にはSpark 4.0系のメジャーバージョンが公開され、ANSI SQLモードの既定化やPython UDFまわりの実行効率改善などが図られたとされています。
• Lakehouse アーキテクチャの標準化：Delta LakeやApache Icebergとの統合が進み、データレイクとデータウェアハウスの機能を統合した「Lakehouse」構成がSpark活用の主流パターンになりつつあります。
• Spark Connectの普及：クライアント側とクラスタ側を分離するSpark Connectアーキテクチャにより、Jupyter NotebookやIDEからリモートのSparkクラスタへ軽量に接続する使い方が広がっています。
• AI/ML統合：MLflowやHugging Face TransformersなどとSparkを組み合わせ、特徴量エンジニアリングからモデル学習・推論までを一つのパイプラインで完結させる事例が増えています。
• クラウドのサーバーレス化：Amazon EMR ServerlessやGoogle Cloud Dataproc Serverless、Databricksのサーバーレスコンピュートなど、クラスタ管理そのものを意識しない利用形態が広がっています。

よくある質問（FAQ）

関連用語

• Hadoop - Sparkの前身にあたる分散処理・分散ファイルシステム基盤。HDFSやYARNを併用するケースも多い
• Apache Kafka - Structured Streamingの入力元としてよく組み合わされる分散メッセージング基盤
• ETL - SparkがバッチジョブやDataFrame APIで実装するデータ取り込み・変換処理の基本パターン
• データレイク - Sparkが読み書きする生データの蓄積先として使われることが多いストレージ戦略
• データウェアハウス - Sparkで加工したデータの投入先となることが多い分析用データ基盤
• データパイプライン - Sparkジョブが構成要素の一つとなる、データの収集から活用までの一連の流れ
• データパイプラインアーキテクチャ - Sparkを含むデータ処理基盤全体の設計手法
• ビッグデータ - Sparkが処理対象とする大規模データの概念
• Python - PySparkとしてSparkを操作する際に広く使われるプログラミング言語

外部リンク・参考資料

• Apache Spark 公式サイト
• Apache Spark 公式ドキュメント（最新版）
• apache/spark - GitHubリポジトリ
• Amazon EMR（Sparkのマネージド実行環境）公式ページ