いずれもビッグデータのパイプライン構築のために使用される。
- Dataprocは、データサイズがあらかじめわかっている時や、cluster sizeを自分で設定したい時に有用。
- Dataflowは、データサイズやrateが未知の場合(
<-GCPがうまいこと調節してくれるから)や、データがリアルタイムに発生する場合に有用。
Cloud Dataproc
- managed way to run Hadoop
- HadoopとはMapReduceを使用したビッグデータの処理フレームワーク
- Hadoopと呼ばれると、一般的に以下の総称を指す。全てOSS。
- Apache Hadoop (そのもの。以下は関連プロジェクト)
- Apache Spark (Spark SQLを利用してビッグデータの分析ができる)
- Apache Pig
- Apache Hive (BigtableのOSS版)
- Hadoop clusterにリクエストを投げるだけで実行が可能
- 平均90秒でclusterが作られる
- jobの負荷に応じて、clustersをscale up/downしてくれる
- Stack driverで監視ができる
- 主に使用したリソース分が課金の大枠を占めることになる。(price rateは秒段位、課金時間は秒単位)
- バッチ処理に使用するGCEをpreemptible instanceにすることで、節約できる。
- このやり方を使用するなら、jobが停止されたら再び実行されることを保障する必要がある。
Cloud Dataflow
GCPのdoc(Apache Beam のプログラミング モデル)がわかりやすいので以下そのまま引用。
Apache Beam は、バッチとストリーミングの両方のデータの並列処理パイプラインを定義するオープンソースの統合モデルです。Apache Beam プログラミング モデルは、大規模なデータ処理の構造を単純化します。Apache Beam SDK の 1 つを使用して、パイプラインを定義するプログラムを構築します。次いで、Dataflow などの Apache Beam がサポートする分散処理バックエンドの 1 つがパイプラインを実行します。このモデルのおかげで、並列処理の物理的なオーケストレーションではなく、データ処理ジョブの論理的な構成に集中できます。つまり、ジョブの実行方法ではなく、ジョブの実行内容に焦点を絞ることができます。
Apache Beam モデルでは、有効な抽象化が提供されるため、分散処理の下層部分の細かい設定（個々のワーカーの調整やデータセットの分割などのタスク）をユーザーが扱う必要がなくなります。Dataflow ではこれらの下層レベルの細かい設定が完全に管理されます。
パイプラインの例は以下。
In this example, Dataflow pipeline reads data from a BigQuery table (=the Source) processes it in a variety of ways (=the Transforms), and writes its output to a CloudStorage (=the Sink).
Some of those transforms you see here are map operations and some are reduce operations.
話を戻す。Dataflowの用途は以下。
- ETL
- データ分析(リアルタイムも、バッチ処理も)