Question#5(Professional Data Engineer)

Question#5(Professional Data Engineer)
あなたは、Streaming Engine と水平オートスケーリング(Horizontal Autoscaling)を有効にして Dataflow ストリーミングパイプラインを実行しています。最大ワーカー数を 1000 に設定しました。パイプラインの入力は Cloud Storage からの通知を含む Pub/Sub メッセージです。パイプラインの変換の 1 つが CSV ファイルを読み取り、CSV の行ごとに要素を出力します。ジョブのパフォーマンスは低く、パイプラインはわずか 10 のワーカーしか使用しておらずオートスケーラーが追加のワーカーをスピンアップしていないことに気付きました。パフォーマンスを向上させるために何をすべきですか?
ディスカッション 0

正解:B

🎯 要件の分析

  1. 問題: Dataflow ストリーミングジョブのパフォーマンスが低い。

  2. 設定: 水平オートスケーリングが有効(最大 1000 ワーカー)。

  3. 現象: 実際にはわずか 10 ワーカーしか使用しておらず、オートスケーラーがスケールアウトしていない。

  4. ボトルネックの場所: CSV ファイルを読み取り、行ごとに要素を出力する変換。

🔑 現象の分析

Dataflow のオートスケーラーが設定された最大値(1000)までスケールアウトしない主な理由は、並列処理のボトルネックがあるためです。

このパイプラインでは、Cloud Storage の通知(Pub/Sub メッセージ)から処理が始まります。通知メッセージの数や、そのメッセージが処理される最初のステップが非常に少ない場合、パイプラインの初期段階で並列処理が制限されます。

問題文にある変換「CSV ファイルを読み取り、行ごとに要素を出力する」は、前のステップの出力(Cloud Storage 通知)に**結合(フュージョン)**されています。

フュージョンが発生すると、前のステップ(Pub/Sub からの読み取り)の並列処理の度合いが、次のステップ(CSV 読み取り)の並列処理の度合いを決定します。もし、Pub/Sub からの入力が少数のワーカー(この例では 10 ワーカー)によって処理されている場合、その後の処理も同じワーカーにフュージョンされ、ジョブ全体が 10 ワーカーに制限されてしまいます

💡 解決策

  • B. パイプラインコードを変更し、フュージョンを防ぐために Reshuffle ステップを導入します。

    • Dataflow は、可能な限り多くの変換をフュージョン(結合)して、ワーカー間でのデータ転送のオーバーヘッドを削減しようとします。しかし、これにより並列処理が制限されることがあります。

    • Reshuffle 変換は、Dataflow にデータの再シャッフルを強制し、意図的にフュージョンを防ぎます。CSV ファイルを読み取った直後、またはそれ以前のステップで Reshuffle を挿入することで、大量の CSV 行データ(要素)の後にパイプラインが強制的にデータを再分配し、オートスケーラーが処理負荷に基づいて追加のワーカーをスピンアップできるようになります。これが、パフォーマンスを向上させるための適切なコーディング上の解決策です。

  • A & D. 垂直スケーリング / Dataflow Prime:

    • 垂直スケーリング(ワーカーを大きくする)は、ワーカー数が少なすぎるという根本的な並列処理のボトルネックを解決しません。ワーカーは 1000 個まで使えるはずです。

  • C. 最大ワーカー数を増やす:

    • 最大ワーカー数はすでに 1000 と非常に大きく設定されています。オートスケーラーが 10 個からスケールアップしないのは、最大値が低いためではなく、処理がボトルネックによって並列化できていないためです。


結論として、オートスケーラーを機能させるには、Reshuffle ステップを導入して、データがワーカー間で効果的に分散されるようにすることが必要です。


コメント

コメント

コメントする

目次