case-kの備忘録

日々の備忘録です。最近はGCPやデータ分析系のことを呟きます

Dataflowが得意なこと、苦手なこと

Dataflowが得意なこと、苦手なことを考えてみました。

得意なこと

バッチ/ストリーミング処理(特にストリーミング処理)

Dataflowはストリーミングとバッチ処理を同じように扱えます。ストリーミング処理はPub/Subからバッチ処理はGCSからデータを読み込むことになりますが入力先を変えるだけで行うことができます。ストリーミングとバッチの両方を対象としたプログラミングモデルは大きな差別化要素となっているようです。

p = beam.Pipeline(options=options)
# READ FROM Pub/Sub
p | 'Read PubSub Messages' >> beam.io.ReadFromPubSub(topic=input_topic)
# READ FROM GCS
p | 'read from gcs' >> beam.io.ReadFromText('[gcs path]') 

Pub/Subはat-least-once配信を採用しており、メッセージを1回以上配信します。これはセンサー等トリガー側に不具合があっても、データが欠損しないようにするためなのですが、データの重複が発生します。DataflowはPub/Subのメッセージに含まれているIDを考慮し重複の排除が可能です。また、Windowサイズを指定することでイベントデータを集計するタイミングの調整が可能です。

p = beam.Pipeline(options=options)
# READ FROM Pub/Sub
(p | 'Read PubSub Messages' >> beam.io.ReadFromPubSub(topic=input_topic)
 | "Set Window Size "  >> beam.WindowInto(window.SlidingWindows(size=3, period=1))

具体的な機能などはこちらを見てみてください。
www.case-k.jp

サイズの大きいデータを扱うこと

データサイズが大きいとそもそもメモリにデータがのりません。ファイルを分割し、PoolやPySparkで並列処理・メモリ解放など煩雑化します。Dataflowはオートスケールで並列分散処理を行うためファイル分割のような前処理も不要です。

サーバ費用を抑えること

必要なサーバー台数を考慮しオートスケールするため、余計にメモリやCPUの良いインスタンスを選ぶ必要はありません。また、ジョブた完了したらインスタンスも消えるためサーバのモニタリングも不要になります。

苦手なこと

逐次処理

Dataflowは逐次処理が苦手です。入力から出力までのパイプラインでデータの加工を行うため、Dataflowを実行結果として出力されたファイルやテーブルを参照するような処理はできません。特に前処理でBigQueryを活用している場合、SQLを実行しテーブルに保存、保存したデータを参照するSQLを実行することが多いと思いますがそのようなことはできないようです。

# 入力から出力まで加工処理を行う
p = beam.Pipeline(options=options)
query = "SELECT word , word_count " \
"FROM `bigquery-public-data.samples.shakespeare`" \
"LIMIT 10"

(p | 'read' >> beam.io.Read(beam.io.BigQuerySource(project=PROJECTID,
                                                   use_standard_sql=True,
                                                   query=query))
  | 'WriteToBigQuery' >> beam.io.WriteToBigQuery('{}:{}'.format(PROJECTID,table_spec), schema=table_schema)
 )
p.run()

Dataflowにも同期処理は用意されていますが、実行環境に依存しないテンプレート化する必要があるので実質できないと考えていいと思います。あくまでもETLツールなので、ワークフロー管理はCloud Composerやノンプログラミングで行うData Fusionを使う必要があります。活用事例を調べてみたところ、Dataflowはマイクロサービスとして扱い、ComposerでDataflowをキックしているようです。
www.case-k.jp

複雑なパイプライン制御(役割が異なる)

Dataflowは出力結果を参照するような逐次処理はできませんが、入力から出力まで複雑なパイプラインを構築することは可能です。しかし、もし取り込むデータに不備があった場合、最初からやり直す必要があります。活用事例をみてみるとDataflowをマイクロサービスとして扱い、Composerでワークフローを管理するのが一般的なようです。
Composerはタスク単位で管理しているため、失敗したところを把握し再実行可能です。Dataflowの役割はあくまでデータの加工でパイプラインの制御ではありません。