Google CloudのProfessional Data Engineer試験を勉強していると、必ずといっていいほど立ち止まるのが「SparkジョブはDataprocで回すのか、それともDataflowで動かすのか」という選択です。どちらも分散処理基盤であり、バッチ処理やETLの文脈で名前が出てきますが、試験ではその違いを整理していないと混乱します。本記事では、私自身が試験対策中に引っかかった観点を整理しながら、Sparkを実行する際にDataprocとDataflowをどう切り分ければいいのかを解説します。読了後には、試験問題で迷わず正しいサービスを選べるようになるはずです。

Sparkを扱うときに受験者が混乱するポイント

  • OSSのSparkをそのまま持ち込むのか、GCPに最適化された形で実行するのかが分かりにくい
  • DataprocとDataflowのどちらも「バッチ処理ができる」と説明されていて境界が曖昧
  • コスト・運用管理・拡張性といった観点が試験で問われる

Dataprocの特徴と選ばれるケース

OSS Spark互換を重視したいとき

DataprocはマネージドHadoop/Sparkクラスターを提供するサービスです。OSSのAPIやライブラリをそのまま活かせるので、既存のSparkジョブを最小限の修正で移行したい場合に有効です。ジョブの構造が複雑で外部ライブラリ依存が強い場合、Dataprocの方が実装コストは低くなります。

クラスター管理と柔軟性

Dataprocはクラスターサイズや構成を利用者が決められるため、細かなチューニングが可能です。ただし、クラスターの起動・終了管理やスケーリング戦略も利用者側の責任範囲になります。試験問題では「OSS移行」「既存のSparkジョブ流用」がキーワードならDataprocを選ぶのが正解です。

Dataflowの特徴と選ばれるケース

Apache Beamによる抽象化

DataflowはApache Beamをランタイムにした完全マネージドな分散処理基盤です。Sparkに似た分散処理モデルを扱えますが、APIはBeamで統一されます。そのためSparkコードを直接動作させることはできません。Spark資産を運用コストをかけずに動かしたい場合はDataproc Serverless for Apache Sparkも選択肢に入ると思います。試験では「バッチとストリームを同じモデルで扱う必要がある」「運用負荷を最小化したい」といった条件が提示されたときにDataflowが正解になります。

運用管理を任せたい場合

Dataflowはサーバーレス実行で、クラスターの起動・終了・スケーリングはすべて自動化されています。運用管理コストを下げたい、SLAベースでスケーリングを任せたいケースはDataflowの方が適します。

試験での出題パターンと判断のヒント

  • 既存のSpark/Hadoopジョブを最小修正で持ち込みたい → Dataproc
  • バッチ/ストリームの両対応やサーバーレス基盤を前提にしたい → Dataflow
  • クラスター構成やチューニングを細かく制御したい → Dataproc
  • 運用負荷を極力減らしたい → Dataflow

公式ドキュメント:
– Dataproc 概要: https://cloud.google.com/dataproc/docs/overview
– Dataflow 概要: https://cloud.google.com/dataflow/docs/concepts/overview

まとめ

Sparkをどの基盤で動かすかは、既存資産をどう扱うかと運用コストをどこまで任せたいかの二軸で判断できます。PDE試験では「OSS流用ならDataproc」「運用レスならDataflow」と整理しておけば混乱しません。学習中に感じた「どちらもバッチできるのに何が違うの？」という疑問は、運用責任とAPIモデルの違いに収束します。読了後は、実際の試験問題に出てきたケーススタディを想像し、どちらを選ぶのが妥当かを練習しておくと良いでしょう。