GCP Dataflow/proc と分散並列計算フレームワークの備忘録

背景

仕事で分散並列処理を、 GCP 前提で設計から考える機会があった。 分散並列処理を実行するためには、そのためのエンジンを利用して、その上でアプリケーションを記述することになる。 それぞれのエンジン毎に、異なるアーキテクチャが採用されているはずで、それによるメリットデメリットを比較しないと適切な技術選定はできない。 なので、 hadoop や spark などを含め、有名な分散並列計算のフレームワークの特徴をざっくり調べてみたので、その備忘録。

各並列エンジンについて

Hadoop

Google が MapReduce を発表し、それが OSS として実装されたもの。

1. 分散したファイルシステムが提供され、
2. そのファイルシステムのデータに対して、どのように map して reduce するかを記述することで、エンジンがその記述に従いよしなに map reduce する。

Spark

Hadoop の、特に途中計算結果を、 HDFS ではなく Resilient Distributed Datasets と呼ばれる抽象共有メモリにストアする形式にしたような分散処理フレームワーク。 途中経過の File IO を省くことができるのがメリット。

Apache Sparkとは何か――使い方や基礎知識を徹底解説：Amazon EMRで構築するApache Spark超入門（1）（1/3 ページ） - ＠IT

本連載では、Sparkの概要や、ローカル環境でのSparkのクラスタの構築、Sparkの基本的な概念やプログラミングの方法を説明していきます。 (1/3)

atmarkit.itmedia.co.jp

Hadoop がベースなので、 Hadoop が動く環境であれば Spark も動くっぽい。

GCP Dataproc

Hadoop / Spark の Managed Service on GCP.

Apache Beam

Map Reduce による抽象化は、とにかく大規模なデータを並列で処理することだけを考えたようなモデルであるため、ストリーミング処理などリアルタイム性が要件に入ってくるようなアプリケーションには向いていない。 ということで、リアルタイム性を考慮に入れたような形で、ストリーミングを含めた大規模分散処理のモデル化とその記述言語を Google が発表した。 その結果が Apache Beam。

Flink

Apache Beam で記述されたジョブを実行するための分散計算処理の機構を、比較的素直に OSS 化したようなもの、っぽい。

GCP Dataflow

Apache Beam で記述されたジョブを引数に取り、その実行をすべて良い感じにやってくれる managed service.

Troubleshoot Dataflow autoscaling  |  Google Cloud

cloud.google.com

上記の資料を見ていると、 CPU 利用率とジョブの中のパイプラインにおけるバックログ(未処理のエントリー)の量をベースに自動でオートスケーリングする前提であり、それすらもユーザーは指定できないようになっている。

なので、純粋な computation heavy な並列処理の、モデルだけを Apache Beam で記述し、その実行はすべてクラウドでマネージドでやりたい、というユースケースに向いている模様。

まとめ

• CPU-heavy なタスクをとにかくやりたいだけだったら Dataflow 使っておけば良さそう。
• 自前サーバーでやる前提ならば Apache Flink。
• Spark / Hadoop は、それを使うないし、それしか使えない制約があるような状態で利用するのが妥当そう。