カーキ色はヒンディー語らしい

技術記事は https://zenn.dev/notrogue

Building production-ready data pipelines using Dataflow: Deploying data pipelinesのメモ

cloud.google.comデプロイに関するノウハウ記事で、気になったところのメモです。他の章のメモはこちら。

Streamingだと全般的にジョブの更新面倒そうなのが辛い‥Flinkとかだと違うのでせうか。

 

CI/CD

CI/CDの一般論的な話も多いですが、

  • DirectRunnerによるテスト
  • BatchはCD出来るが、Streamingはジョブの置き換えがある関係で大変
  • CI/CDに必要な権限

などのDatalfow固有の話題が紹介されています。

 

テンプレート vs 普通のジョブ

Dataflow テンプレートのドキュメントでは、パイプラインの起動が楽になるなどのメリットが紹介されていますが、こちらのドキュメントでは、

  • batchジョブでは、ジョブが繰り返し起動される事が多いのでテンプレートが向いてる
  • Streamingジョブでは、長時間実行され続ける(ので起動回数が少ない)、テンプレートではジョブのupdateがサポートされないので、普通のジョブが向いている

と、バッチとストリーミングで向き不向きがあると紹介されています。

 

Streamingジョブの更新

Streamingは動かし続けますが、いつかはコードを変更する必要が出てきます。

その時の選択肢として

  1. ジョブのUpdate
  2. cancelとdrain
  3. (cancelかdrainと組み合わせて)Pub/SubのSeekでデータを戻して再実行
  4. 並行して複数のパイプラインを実行(重複考慮した実装が必要)

が紹介されています。

 

Dataflowジョブのライフサイクル

Dataflowのジョブがサブミットされて、ワーカーで処理されるまでの流れが紹介されています。

特に、シャッフル(GroupByKey,Combine,CoGroupByKey)は、

  • 通常はワーカー・そのディスク上で処理される
  • Streaming Engine/ Shuffleの場合は、ワーカーの外で処理される

ことが紹介されています。

 

ベストプラクティス

(いずれも要件・コスト次第だとは思いますが)

  • 複数リージョンに依存しないようにする
  • ワーカーの指定には、ゾーンよりリージョンを指定するようにする(起動時にいい感じに選んでくれる?)
  • ただし、ジョブが起動してからはゾーン依存なので注意
  • リージョン死んでも大丈夫なように、GCSやBigQueryにデータ入れとく
  • リージョン依存の障害が起きたとき、バッチの場合は建替えが無難
  • ストリーミングは待つくらいしかないが、強く必要な場合は、独立したリージョンに、ソース、パイプライン、シンクを冗長化しておく