BatchElements変換を使用した要素の動的なグループ化

要素のバッチ処理が必要な理由

Apache Beamは、後続の操作の処理時間を償却するためにBatchElements 変換を提供します。これは、呼び出しごとにかなりの固定コストがあり、その呼び出し内で処理される要素ごとにコストが小さい操作の前に適用するのが最適です。簡単に言えば、要素のバッチ処理は、一度に複数の要素を処理する方が、一度に1つずつ処理するよりも効率的な操作の前の最適化ステップです。

例：RunInferenceでのバッチ処理

RunInferenceのコンテキストでは、要素のバッチ処理は、主に推論に使用されるモデルへの呼び出し回数を減らすのに役立ちます。これは、ワーカー上の推論コンテキストでの効率にとって重要ですが、リモートサービスに送信される推論呼び出しを検討する場合、さらに大きな影響があります。APIレート制限が考慮事項である場合、可能な限り要素をバッチ処理することは、クォータを超過するリスクを軽減するための重要な方法です。RunInference フレームワークは、常にBatchElementsに呼び出します。これは、推論ワークロードにとってこのステップがどれほど不可欠であるかをさらに強調しています。

バンドル内のバッチ処理

要素をバッチ処理するために使用される主な方法は、要素のバンドル内でバッチ処理することです。バンドルを反復処理し、ターゲットバッチサイズに達するまで要素をバンドルに追加してから、出力します。同じバッチ内の要素は、バッチ処理関数がウィンドウを認識しているため、同じイベント時間ウィンドウに存在することが保証されています。バンドルの終わりに到達したときに不完全なバッチがバッファリングされている場合は、出力されます。

パラメーター調整の考慮事項

この方法でのバッチ処理の調整の大部分は、ダウンストリームのパフォーマンスに基づいて最適なバッチサイズを推定するために使用されるパラメーターを中心に行われます。_BatchSizeEstimator オブジェクトは、出力されたバンドルのバッチサイズとクロック時間に関するデータポイントを保持し、線形回帰を使用して現在の理想的なバッチサイズを解決しようとします。BatchElementsのドキュメント文字列は、これとここで処理されるパラメーターについて詳しく説明しています。ほとんどのユーザーにとって最も重要な考慮事項は、最小バッチサイズと最大バッチサイズ（同じ値を設定すると、動的なバッチサイズではなく固定バッチサイズが生成されます）と、要素サイズ関数です。後者を使用すると、各要素を単にサイズ1としてカウントするのではなく、各入力を個別にサイズ設定できるラムダをユーザーが定義できます。これは、モデルに渡されるときに、入力の処理時間が著しく異なる場合に非常に役立ちます。たとえば、テキストの本文をモデルに送信する場合、文字長でサイズを設定できます。

バンドル間のバッチ処理

バンドル内の要素をバッチ処理することには、1つの大きな欠点があります。バンドルが小さい場合（または単一の要素の場合でも）、操作は事実上何もしません。これは、バンドルに1〜2個の要素しか含まれていないことが予想されるストリーミングパイプラインで特に当てはまります。小さなバンドルでのバッチ処理を有効にするには、代わりにバンドル間で要素をバッチ処理できる必要があります。これがどのように機能するかの詳細な技術的な説明については、バンドル間のバッチ処理（ステートフルバッチ処理とも呼ばれます）の設計ドキュメントにコードの概要が示されています。ただし、高度な説明では、Beamの状態APIを活用して、バンドル間で要素を保存し、目的のバンドルサイズに達したとき、またはバンドルを最大時間バッファリングしたときにダウンストリームに出力します。

ステートフルなバッチ処理を有効にするには、Apache Beam バージョン 2.52.0 以降で、max_batch_duration_secs パラメーター を BatchElements に渡します。これにより、ステート API が使用できるように入力要素にキーが付けられ、ステートフルなバッチ処理関数が使用されます。バッチは、現在のターゲット バッチ サイズに達するか、バッチが max_batch_duration_secs 以上の時間バッファリングされた場合に放出されます。時間ベースの動作は タイマー API を使用して実装されており、最善の結果が得られるように設計されているため、バッチが放出されるまでに保持される実際の時間は、設定された最大値よりも長くなる可能性があることに注意してください。

バンドルをまたいだバッチ処理には、固有の欠点があります。

パラメーター調整の考慮事項

バンドル内のバッチ処理に使用されるすべてのチューニングパラメータに加えて、max_batch_duration_secs パラメータを調整すると、変換のスループットに大きな影響を与えます。最大バッチ期間を選択する際にトレードオフとなるのは、スループットと一貫したバッチサイズです。値が大きいほど、不完全なバッチが推論呼び出し自体に送信されるまでに長時間保持されるため、一般的にスループットは低下しますが、より一貫してフルバッチが生成されます。一方、値が小さいほど、一般的にスループットは高くなりますが、その結果、バッチサイズが小さくなる可能性があります。どちらを重視するかは、ユースケースによって異なります。

これらの傾向が常に当てはまるわけではないことにも注意してください。ストリーミングコンテキストでは、パイプラインに要素が取り込まれる頻度に妥当なばらつきがあります。最大バッチ期間が短い場合でも、目標とするバッチサイズに到達できる可能性がありますが、これは、最大バッチ期間が長い場合に一貫してそのバッチサイズに到達することとは異なります。これらのトレードオフは平均的なケースとして考えるのが最善です。