データ分析とか基盤系に興味あります。Pub/SubDataflowが得意なこと、苦手なことを考えてみました。複雑なパイプライン制御(役割が異なる)得意なことバッチ/ストリーミング処理(特にストリーミング処理)Dataflowはストリーミングとバッチ処理を同じように扱えます。ストリーミング処理はPub/Subからバッチ処理はGCSからデータを読み込むことになりますが入力先を変えるだけで行うことができます。ストリーミングとバッチの両方を対象としたプログラミングモデルは大きな差別化要素となっているようです。Pub/Subはat-least-once配信を採用しており、メッセージを1回以上配信します。これはセンサー等トリガー側に不具合があっても、データが欠損しないようにするためなのですが、データの重複が発生します。DataflowはPub/Subのメッセージに含まれているIDを考慮し重複の排除が可能です。Windowサイズを指定することでイベントデータを集計するタイミングの調整が可能です。period=1))具体的な機能などはこちらを見てみてください。www.case-k.jpサイズの大きいデータを扱うことデータサイズが大きいとそもそもメモリにデータがのりません。ファイルを分割し、PoolやPySparkで並列処理・メモリ解放など煩雑化します。Dataflowはオートスケールで並列分散処理を行うためファイル分割のような前処理も不要です。サーバ費用を抑えること必要なサーバー台数を考慮しオートスケールするため、余計にメモリやCPUの良いインスタンスを選ぶ必要はありません。ジョブた完了したらインスタンスも消えるためサーバのモニタリングも不要になります。苦手なこと逐次処理Dataflowは逐次処理が苦手です。入力から出力までのパイプラインでデータの加工を行うため、Dataflowを実行結果として出力されたファイルやテーブルを参照するような処理はできません。前処理でBigQueryを活用している場合、SQLを実行しテーブルに保存、保存したデータを参照するSQLを実行することが多いと思いますがそのようなことはできないようです。)p.run()Dataflowにも同期処理は用意されていますが、実行環境に依存しないテンプレート化する必要があるので実質できないと考えていいと思います。Fusionを使う必要があります。活用事例を調べてみたところ、Dataflowはマイクロサービスとして扱い、ComposerでDataflowをキックしているようです。www.case-k.jp複雑なパイプライン制御(役割が異なる)Dataflowは出力結果を参照するような逐次処理はできませんが、入力から出力まで複雑なパイプラインを構築することは可能です。取り込むデータに不備があった場合、最初からやり直す必要があります。活用事例をみてみるとDataflowをマイクロサービスとして扱い、Composerでワークフローを管理するのが一般的なようです。Composerはタスク単位で管理しているため、失敗したところを把握し再実行可能です。Dataflowの役割はあくまでデータの加工でパイプラインの制御ではありません。読者になる関連記事2020-06-13Dataflowでしかできないことってなんだろう。BigQueryだけじゃだめなのかな。ComposerでDataflowテンプレートを順次キックしていく逐...2019-10-13Dataflowパイプライン処理の備忘録:PythonDataflowで使うパイプライン処理の備忘録です。検索はてなブログをはじめよう!casekblogさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。