GCSバケットから時間とホストマシンで分割されたログファイルを読み取るデータフロージョブがあります。次のようにバケットの構造は次のとおりです。データフロージョブの読み取り時間の合計が高い値です
/YYYY/MM/DD/HH/mm/HOST/*.gz
各ジョブには約10の10,000ログファイルの順に消費してしまうことができます-100 KBのサイズ。
通常、私たちの仕事は完了するまでに約5分かかります。我々は時々、私たちの仕事がその時間の2-3倍に急増するのを見て、増加の大部分がデータファイルを読むことに関連する作業項目に見られることがわかります。どのようにしてこのジョブの実行時間のばらつきを減らすことができますか？ GCSからの読み取りにスループットの問題はありますか？
ほとんどの場合、ジョブに表示される分散は、GCSネットワークの待ち時間によるものです。通常、GCSからアイテムを取得するまでの待ち時間はやや短いですが、ネットワークの状態や時刻などのさまざまな要因によってスパイクが発生する可能性があります。 GCSからの読み取りに関するレイテンシにはSLAはありません。 GCSのスループットは、読んでいるデータファイルのサイズがかなり小さいため、おそらく要因ではありません。
遅延が大幅に増加するようなネットワーク条件の場合、この影響は読み取り中のファイル数に比例して増加します。
ジョブ時間のばらつきを緩和する方法の1つは、ログファイルを読み込む前にログファイルを結合して結合し、読み取るファイルのサイズがより小さくなるようにすることです。
私はこれについて異なる見識を持っています。 gzipファイルを読むと、最初にワーカーマシンで解凍されていることを意味します。圧縮フォーマットとしてgzipが分割可能ではないため、gzipファイルの解凍は単一コア（理想的には1 n1標準1ワーカー）操作です。
上記のシナリオでは、他のファイルと比較してかなり大きいファイルが存在する可能性があり、ジョブ実行時間を増加させるstragglers（遅延するデータフロージョブのワーカー）が作成される可能性があります。
私は可能な限り最小とジョブの実行時間を維持するために、2つの解決策を考えることができからbzip2のような分割圧縮形式に
gzipファイルのサイズをできるだけ小さくして、多数の作業者が膨大な数のファイルを消費し、合計実行時間が短くなるようにします。たとえば、10人の従業員にそれぞれ100KBの10個のgzipファイルを読み込ませると、100人の従業員にそれぞれ10KBのzipファイルが読み込まれます。 GCPは1分あたりの請求額を請求するので、コストはほとんど変わらないはずです。