バッチ処理システムとストリーム処理システムの違いと関係は何ですか？
設計データ集約型アプリケーションsays
バッチ処理システム（オフラインシステム）第10章
バッチ処理システムは、大量の入力データを取り、ジョブを実行してそれを処理し、出力データを生成します。ジョブは時間がかかることが多いため（数分から数日）、通常、ユーザーがジョブの完了を待っていることはありません。代わりに、バッチジョブは頻繁に定期的に（たとえば、1日1回）実行されるようにスケジュールされます。バッチジョブの主要なパフォーマンス指標は通常、スループット（特定のサイズの入力データセットを処理するのにかかる時間）です。バッチ処理については、第10章で説明します。
ストリーム処理システム（ほぼリアルタイムのシステム）第11章
ストリーム処理は、オンライン処理とオフライン/バッチ処理の間のどこかにあります（したがって、ほぼリアルタイムまたはニアライン処理と呼ばれることもあります）。バッチ処理システムと同様に、ストリームプロセッサは（要求に応答するのではなく）入力を消費して出力を生成します。ただし、ストリームジョブは発生後すぐにイベントを操作しますが、バッチジョブは入力データの固定セットを操作します。この違いにより、ストリーム処理システムは同等のバッチシステムよりもレイテンシを低くすることができます。ストリーム処理はバッチ処理に基づいて構築されるため、第11章で説明します。
第10章バッチ処理システムの要約 では、
この章では、バッチ処理のトピックについて説明しました。
awk、grep、sortなどのUnixツールを検討することから始め、これらのツールの設計哲学がどのようにMapReduceおよびより新しいデータフローに引き継がれるかを見ました。エンジン。これらの設計原則のいくつかは、入力は不変であり、出力は別の（まだ未知の）プログラムへの入力になることを目的としており、複雑な問題は「1つのことをうまく行う」小さなツールを構成することによって解決されます。 Unixの世界では、あるプログラムを別のプログラムで構成できるようにする統一されたインターフェースは、ファイルとパイプです。 MapReduceでは、そのインターフェースは分散ファイルシステムです。データフローエンジンは、パイプラインのような独自のデータ転送メカニズムを追加して、中間状態が分散ファイルシステムに具体化されないようにしましたが、ジョブの初期入力と最終出力は通常HDFSのままです。
バッチ処理システムとストリーム処理システムの違いと関係は何ですか？具体的には
バッチ処理システムとストリーム処理システムの違いは正しいですか
バッチ処理システムは、入力の処理を開始する前に、入力全体を読み取る必要がありますか？
ストリーム処理システムは、すべての入力を読み取ることなく、入力の一部を処理できますか？
パート1の答えが「はい」であると想定します。
バッチ処理システムは、入力のサイズをどのようにして知るのですか？バッチ処理システムは、入力をすべて読み取ったことをどのようにして知るのですか？
ストリーム処理システムは、処理を開始する前に読み込む必要がある入力の部分をどのようにして知るのですか？
プログラムを使用して、例として
commandB | commandAのようにbashのようなシェルでパイプします。commandAがawkgrepまたはsortの場合、それはバッチ処理システムですか、なぜですか？commandAがcatの場合、それはバッチ処理システムですか、ストリーム処理システムですか？なぜですか？
- バッチ処理システムとストリーム処理システムの両方またはいずれかが、プロデューサー/コンシューマーパターンに適合していますか？
ありがとう。
この主な方法で違いを考えてみてください。
- バッチシステムは、一度にデータのチャンクを処理します（つまり、バッチ）定期的に
- ストリーミングシステムは、各レコードを処理するときに機能します
バッチ処理の主な特徴
バッチ処理は通常、「帯域外」で行われるか、または本質的にアプリケーションスイートのコアコンポーネントとして構築されていません。注：データを一括で取り込み、マップを削減し、後で簡単にクエリできるようにデータを新しいルックアップテーブルに再構築することは、すべてバッチ処理の例です。
- バッチ処理polls新しいデータを処理する場合
- バッチ処理はうまくいけば一度に処理するレコードの数を制限します
- バッチ処理はscheduledで定期的に、または少なくともアプリケーションのアクティビティが最も低いときに発生します。
ストリーミングの主な特徴
ストリーミングはアプリケーションスイートのコアコンポーネントであり、非同期でレコードを処理する可能性がありますが、その処理はビルドされたもののコア機能です。
- データはプッシュからストリーミングプロセッサへ
- キューの長さが長くなりすぎた場合、ストリーミング処理はうまくいけばスケーリングする必要があります
- データの受信時にストリーミング処理が行われ、通常はバックグラウンドで動作するようにキューに入れられます
どちらか一方を選択する場合
それは本当に問題の性質に依存します。ストリーミングは、軽量処理とほぼリアルタイムの要件でうまく機能します。バッチ処理は、他のデータとの関連で実行する必要がある可能性のある重い計算でうまく機能します。
大きな問題は、実際の要件は何ですか？
- 処理結果を短時間で表示する必要がありますか？ （ストリーム）
- 処理の結果を数分、数時間、または数日待つことができますか？ （バッチ）
- 要約する必要がある個々の観測としてデータを受け取りますか？ （ストリーム）
- または、数時間後にファイルの束としてデータを受け取りますか？ （バッチ）
うまくいけば、バックグラウンド処理の各セットが実行できる問題の種類と種類について理解できます。
バッチ処理システムとストリーム処理システムの違いは正しいですか
- バッチ処理システムは、入力の処理を開始する前に、入力全体を読み取る必要がありますか？
- ストリーム処理システムは、すべての入力を読み取ることなく、入力の一部を処理できますか？
はいといいえ。実際にすべての入力をバッチの開始時に直接読み取ることは、バッチシステムの要件ではありません。ただし、ソフトウェアがすべての入力データがバッチの開始時に存在すると想定できることが要件です。
ストリーム処理システムの場合、入力は徐々に使用可能になります。
- バッチ処理システムは、入力のサイズをどのようにして知るのですか？バッチ処理システムは、入力をすべて読み取ったことをどのようにして知るのですか？
- ストリーム処理システムは、処理を開始する前に読み込む必要がある入力の部分をどのようにして知るのですか？
これらの質問は、実行する必要がある処理によって主に定義されるため、一般的な答えはありません。
たとえば、X日目に作成されたログを要約するバッチジョブがある場合、ジョブのサイズは不明ですが、ログが時系列で保存されていると仮定すると、ジョブは1日のログエントリを検出すると終了しますX + 1。また、ファイルシステムが入力でファイルの終わりを報告した場合、バッチジョブも実行されます。
例として、コマンドとbashのようなシェルでプログラムとパイプを使用します。コマンドA。
- CommandAがawk grepまたはsortの場合、それはバッチ処理システムですか？なぜですか？
- CommandAがcatの場合、それはバッチ処理システムかストリーム処理システムですか？なぜですか？
本から引用した定義を見ると、バッチ処理システムかストリーム処理システムかは、パイプラインを実行するためにトリガーがどのように与えられるかによって決まります。
トリガーが定期的または手動の場合は、バッチ処理システムの一部になります。トリガーが新しいデータの到着である場合、それはストリーム処理システムの一部になります。
バッチ処理システムとストリーム処理システムの両方またはいずれかが、プロデューサー/コンシューマーパターンに適合していますか？
バッチ処理システムは、プロデューサー/コンシューマーパターンのプロデューサー側にすることができますが、コンシューマー側には適合しません。
ストリーム処理システムは、プロデューサー/コンシューマーパターンのどちらの側にも存在できます。新しいデータを持つプロデューサーは、ストリーム処理システムがもう少しデータを処理するための優れたトリガーになります。