pubsub からバイト配列を読み取り、それらをウィンドウ化し、GCS のテキスト ファイルに書き込む単純なデータフロー パイプラインを作成しました。トラフィックの少ないトピックではこれが完全に機能することがわかりましたが、1 分あたり約 2.4GB のトピックで実行したところ、いくつかの問題が発生し始めました。
パイプラインを開始するとき、ワーカーの数を設定していませんでした (必要に応じて自動スケーリングされると想像していたので)。この量のデータを取り込むとき、ワーカーの数は 1 のままでしたが、TextIO.write() は 2 分のウィンドウを書き込むのに 15 分以上かかっていました。これは、メモリがなくなるまでバックアップされ続けます。このステップがバックアップされたときに Dataflow が自動スケーリングしない正当な理由はありますか?
ワーカーの数を 6 に増やしたとき、ファイルの書き込み時間は 5 分間のウィンドウで約 4 分から始まり、その後わずか 20 秒まで短縮されました。
また、ワーカを6体使用する場合、ウォールタイムの計算に問題がありそうですか？データフローが追いついたとしても、私のものは決してダウンするようには見えず、4時間実行した後、書き込みステップの要約は次のようになりました。
Step summary
Step name: Write to output
System lag: 3 min 30 sec
Data watermark: Max watermark
Wall time: 1 day 6 hr 26 min 22 sec
Input collections: PT5M Windows/Window.Assign.out0
Elements added: 860,893
Estimated size: 582.11 GB
ジョブ ID: 2019-03-13_19_22_25-14107024023503564121