バッチ処理は、データをまとめて決められた時間に処理する方式です。トランザクションが到着するたびに個別に処理するのではなく、システムはトランザクションをまとめて一括処理します。銀行は数十年にわたり、小切手の決済を夜間に行うためにバッチ処理を利用してきました。給与計算システムも、賃金や控除額を計算するためにバッチ処理を実行します。この方式は、処理の迅速性よりも効率性が重視される場合に有効です。

トレードオフはレイテンシです。午前 2 時に実行されるバッチ ジョブでは、前日のデータは朝まで利用できません。給与計算や請求には問題ありませんが、不正検出やリアルタイム価格設定には適していません。ストリーム処理は、データが到着するたびに分析することで、これらのケースに対応します。多くの最新のアーキテクチャでは、両方を使用しています。ストリーミングは緊急イベントを処理し、バッチは履歴分析、照合、レポート作成を処理します。この 2 つは互いに補完し合います。バッチ ジョブは、コンピューティング リソースがアイドル状態のオフ ピーク時にスケジュールできるため、実行コストも安くなります。Hadoop と Spark は、分散クラスタ全体で大規模なバッチ処理を普及させました。テクノロジーは進化しましたが、パターンは古く、収集、スケジュール、処理、配信です。

バッチ処理特性

• 定期運行 — 定められた間隔で運行され、多くの場合夜間に運行される。
• 大量処理 — 大規模なデータセットを効率的に処理します
• 遅延許容型 - 結果はすぐには必要ない
• リソース効率が高い — オフピーク時のコンピューティング能力を活用する
• 決定論的 — 同じ入力に対して同じ出力が得られる

バッチ処理は時代遅れではありません。処理速度よりもスループットが重要な場合には、バッチ処理が最適なツールです。