バッチ処理

コンピュータ化されたバッチ処理は、ジョブと呼ばれるソフトウェア プログラムをバッチで自動的に実行する方法です。ユーザーはジョブを送信する必要がありますが、バッチ処理にはユーザーによるその他の操作は必要ありません。バッチは、スケジュールされた時間に自動的に実行される場合もあれば、コンピュータ リソースの可用性に応じて実行される場合もあります。

「バッチ処理」という用語は、ジョブ生産( 1 回限りの生産)、バッチ生産(一度に複数のアイテムの「バッチ」を 1 段階ずつ生産)、フロー生産(大量生産、すべての段階を一度に処理) という従来の生産方法の分類に由来しています。

初期のコンピュータは、一度に 1 つのプログラムしか実行できませんでした。各ユーザーは、スケジュールされた期間、マシンを単独で制御できました。ユーザーは、多くの場合、パンチ ペーパー カードや磁気テープまたは紙テープでプログラムとデータをコンピュータに持ち込み、プログラムをロードして実行し、デバッグし、完了したら出力を持ち帰りました。

コンピュータが高速化するにつれ、セットアップと終了に要する時間が、コンピュータの使用可能時間の中で大きな割合を占めるようになった。オペレーティング システムの前身であるモニターと呼ばれるプログラムが開発され、これは、多くの場合オフラインで準備された磁気テープから一連のプログラム、つまり「バッチ」を処理できるものであった。モニターはコンピュータにロードされ、バッチの最初のジョブを実行する。ジョブの終了時にモニターは制御を取り戻し、バッチが完了するまで次のジョブをロードして実行する。バッチの出力は、多くの場合、磁気テープに書き込まれ、オフラインで印刷またはパンチされた。モニターの例としては、IBM のFortran モニター システム、SOS (Share Operating System)、そして最後に1960 年のIBM 709xシステム用のIBSYSなどがある。 ^{[1] [2]}

マルチプログラミングが可能な第 3 世代コンピュータ^{[要説明] [3]}は、1960 年代に登場し始めました。一度に 1 つのバッチ ジョブを実行する代わりに、これらのシステムでは、システムを可能な限りビジー状態に保つために、複数のバッチ プログラムを同時に実行できます。1 つ以上のプログラムが入力を待機し、1 つが CPU 上でアクティブに実行され、他のプログラムが出力を生成します。オフラインの入出力の代わりに、スプーラと呼ばれるプログラムがカード、ディスク、またはリモート ターミナルからジョブを読み取り、実行するためにジョブ キューに配置します。デッドロックを防ぐために、ジョブスケジューラは各ジョブのリソース要件 (メモリ、磁気テープ、マウント可能なディスクなど) を知る必要があるため、この情報を構造化された方法で提供するためのさまざまなスクリプト言語が開発されました。おそらく最もよく知られているのは、IBM のジョブ制御言語(JCL) です。ジョブ スケジューラは、優先度、メモリ サイズなど、さまざまな基準に従って実行するジョブを選択します。 リモート バッチは、パンチ カード リーダーとライン プリンタを備えたリモート ターミナルからバッチ ジョブを送信する手順です。 ^[4]非対称マルチプロセッシングは、IBM System/360 Attached Support Processorのように、接続された小型で安価なシステムを使用して、1台以上の大型コンピュータのバッチ入出力をスプールするために使用されることが。 ^[a]

最初の汎用タイムシェアリングシステムである互換タイムシェアリングシステム（CTSS）はバッチ処理と互換性があり、バッチ処理からインタラクティブコンピューティングへの移行を容易にしました。^[5]

1960 年代後半以降、テキストベースのコンピュータ端末インターフェース ( Unix シェルや読み取り評価印刷ループなど) や、その後のグラフィカル ユーザー インターフェースを介した対話型コンピューティングが一般的になった。非対話型コンピューティング (コンパイルなどの 1 回限りのジョブと、複数の項目をバッチ処理するジョブの両方) は、後からバッチ処理と呼ばれるようになり、バッチ ジョブ(初期の使用では「ジョブのバッチ」と呼ばれることが多かった)という用語が一般的になった。初期の使用は、ミシガン大学のミシガン端末システム(MTS)周辺で特に見られる。 ^[6]

タイムシェアリングは存在していましたが、その使用は企業のデータ処理に十分な堅牢性を備えていませんでした。これは、人間が操作する以前のユニット記録装置とはまったく関係がありませんでした。

非対話型コンピューティングは、一般的なデータ処理とシステム「ハウスキーピング」タスク（システムソフトウェアを使用）の両方で、コンピューティングの分野で依然として広く使用されています。高水準プログラム（複数のプログラムを実行し、追加の「グルー」ロジックを使用するもの）は、今日ではスクリプトと呼ばれることが多く、スクリプト言語、特にシステムタスク用のシェルスクリプトで書かれています。IBM PC DOSおよびMS-DOSでは、これはバッチファイルとして知られています。これには、UNIXベースのコンピューター、Microsoft Windows、macOS（その基盤はBSD Unixカーネル）、さらにはスマートフォンも含まれます。実行中のスクリプト、特に対話型ログインセッションから実行されるスクリプトは、ジョブと呼ばれることがよくありますが、この用語は非常に曖昧に使用されます。

「PC や UNIX システムには、z/OS バッチ処理に直接対応するものはありません。バッチ ジョブは通常、スケジュールされた時間に、または必要に応じて実行されます。おそらく最も近い比較は、 UNIX のatコマンドまたはcronコマンドによって実行されるプロセスですが、違いは大きくあります。」^[7]

バッチ アプリケーションは、多くの一般的なビジネス プロセスがバッチ処理に適しているため、ほとんどの組織で依然として重要です。オンライン システムは、手動による介入が望ましくない場合にも機能しますが、通常は大量の反復タスクを実行するように最適化されていません。そのため、新しいシステムであっても、通常、1 日の終わりに情報を更新したり、レポートを生成したり、ドキュメントを印刷したり、特定のビジネス期限内に確実に完了する必要があるその他の非対話型タスクを実行するためのバッチ アプリケーションが 1 つ以上含まれています。

一部のアプリケーションはフロー処理に適しています。つまり、一度に 1 つの入力からのデータのみを必要とするアプリケーション (たとえば、合計ではない) は、前のステップが完了すると、各入力の次のステップを開始します。この場合、フロー処理によって個々の入力の待ち時間が短縮され、バッチ全体が完了するのを待たずに完了できます。ただし、多くのアプリケーションでは、特に合計などの計算で、すべてのレコードからのデータが必要です。この場合、使用可能な結果を​​得るにはバッチ全体を完了する必要があります。部分的な結果は使用できません。

現代のバッチアプリケーションは、Jem The Bee、 Spring Batch ^[8]などの現代のバッチフレームワーク、またはJava用に記述されたJSR 352 ^[9]の実装、および他のプログラミング言語用の他のフレームワークを利用して、大量処理に必要なフォールトトレランスとスケーラビリティを提供します。 高速処理を保証するために、バッチアプリケーションは多くの場合、グリッドコンピューティングソリューションと統合され、バッチジョブを多数のプロセッサに分割しますが、これを行うには大きなプログラミング上の課題があります。 大量バッチ処理は、システムおよびアプリケーションアーキテクチャにも特に大きな要求を課します。 強力な入出力パフォーマンスと垂直スケーラビリティを備えたアーキテクチャ（最新のメインフレームコンピューターを含む）は、他の方法よりも優れたバッチパフォーマンスを提供する傾向があります。

スクリプト言語はバッチ処理とともに進化し、人気を博しました。^[10]

バッチウィンドウとは、「オンラインアクティビティの集中度が低い期間」^[11]であり、コンピュータシステムは、インタラクティブなオンラインシステムからの干渉を受けることなく、バッチジョブを実行できます。

銀行の終業時 (EOD)ジョブには、カットオーバーの概念が必要です。カットオーバーでは、特定の日のバッチ アクティビティのトランザクションとデータがカットオフされます (「午後 3 時以降の入金は翌日に処理されます」)。

グローバル化、インターネット、その他のビジネスニーズに対応するためにオンラインシステムの稼働時間要件が拡大するにつれて、バッチウィンドウは縮小し^{[12] [13]}、オンラインデータを最大限の時間利用できるようにする技術に重点が置かれるようになりました。

バッチサイズとは、1 つのバッチ操作内で処理される作業単位の数を指します。次に例を示します。

• トランザクションをコミットする前にデータベースにロードするファイルからの行数。
• キューからデキューするメッセージの数。
• 1 つのペイロード内で送信するリクエストの数。

• 対話型オンライン トランザクション処理(OLTP) アプリケーションとは対照的に、効率的な一括データベース更新と自動トランザクション処理。データ ウェアハウスへのデータ入力における抽出、変換、ロード(ETL) ステップは、ほとんどの実装において本質的にバッチ プロセスです。
• サイズ変更、変換、透かしの追加、画像ファイルのグループの編集など、デジタル画像に対して一括操作を実行します。
• コンピュータ ファイルをある形式から別の形式に変換します。たとえば、バッチ ジョブでは、独自のファイルやレガシー ファイルを、エンド ユーザーのクエリや表示用に共通の標準形式に変換できます。
• 機械学習モデルのトレーニング。例えば、電子商取引のウェブサイトでは、計算リソースを節約するために、顧客取引を1時間ごとにバッチ処理して、関連製品の推奨を生成するモデルを更新したい場合があります。^[14]

IBMメインフレームの z/OS オペレーティング システムまたはプラットフォームは、その起源、長い歴史、そして継続的な進化により、バッチ処理機能セットが最も洗練され進化していると言えます。今日、このようなシステムは、単一のオペレーティング システムイメージ内で数百または数千の同時オンライン タスクとバッチ タスクをサポートするのが一般的です。同時バッチ処理とオンライン処理を支援するテクノロジには、ジョブ制御言語(JCL)、REXXなどのスクリプト言語、ジョブ エントリ サブシステム ( JES2およびJES3 )、ワークロード マネージャ(WLM)、自動再始動マネージャ (ARM)、リソース リカバリ サービス (RRS)、IBM Db2データ共有、Parallel Sysplex 、 HiperDispatchなどの独自のパフォーマンス最適化、I/O チャネル アーキテクチャなどがあります。

Unixプログラムcron、、（現在はの派生）atは、ジョブの複雑なスケジューリングを可能にします。Windowsにはジョブスケジューラがあります。ほとんどの高性能コンピューティングクラスターは、クラスターの使用率を最大化するためにバッチ処理を使用します。^[15]batchbatchat

• バックグラウンドプロセス
• バッチファイル
• バッチ名前変更- 人間の介入なしに多数のファイルの名前を自動的に変更し、時間と労力を節約します。
• BatchPipes - バッチパフォーマンスを向上させるユーティリティ
• 処理モード
• プロダクションサポート- バッチジョブ/スケジュール/ストリームのサポート
• 高スループットコンピューティング