注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry でデータをストリームとして処理するか、バッチデータセットとして処理するかを決める際には、具体的なユースケースの要件を理解することが重要です。ユースケースに最適なツールを選べるよう、ストリーミングパイプラインとバッチパイプラインの機能、パフォーマンス、および技術面で期待されることを検討することを推奨します。
一般に、ストリーミングはエンドツーエンドの低遅延を必要とするワークフローで使用されます。10分を超える遅延が許容されるユースケースでは、インクリメンタル（差分処理）または標準的なバッチデータセットも適切なソリューションとなる場合があります。
ストリーミングパイプラインとバッチパイプラインには、多くの共通する機能があります。検討すべき主な違いは、遅延、コンピューティングコスト、サポートされているトランスフォーム言語です。次のテーブルに、ストリーミングパイプラインとバッチパイプラインで利用可能な機能を示します。
| 機能 | ストリーミング | バッチ |
|---|---|---|
| すべての Foundry 製品での遅延の大きいデータの利用 | はい | はい |
| トランザクション性 | はい | はい |
| 原子性 | はい | はい |
| ブランチ作成 | はい | はい |
| セキュリティマーキングと機密情報区分 | はい | はい |
| 来歴の追跡 | はい | はい |
| オントロジーのサポート | はい | はい |
| 時系列のサポート | はい | はい |
| Java トランスフォームのサポート | はい | はい |
| Pipeline Builder のサポート | はい | はい |
| Python トランスフォームのサポート | いいえ | はい |
| 低遅延でのデータアクセス | はい | いいえ |
Foundry の一部のフロントエンドツールでは、グラフのライブ更新など、ストリーミングデータセットを「リアルタイム」で利用できます。ストリームをネイティブに利用できるツールは、オントロジー、Pipeline Builder、Quiver、データセットプレビュー、Foundry Rulesです。Contour など、Foundry のほかのアプリでは、ストリームのアーカイブデータセットを利用できます。これは、ストリームの最新データで数分ごとに更新される標準的なバッチデータセットです。実際には、どのアプリでもストリーミングデータセットを選択でき、Foundry が使用すべきモードを自動的に判断します。
機能に関する考慮事項に加えて、ストリーミングパイプラインとバッチパイプラインで期待されるパフォーマンスの違いを検討します。これには、遅延やスループットなどの要素が含まれます。詳細については、ストリーミングの遅延とスループットに関する考慮事項を確認してください。
ストリーミング処理とバッチ処理を特徴づける機能およびパフォーマンスの要素に加えて、状態管理、ダウンタイムの影響、データ利用層の遅延などの技術的な要素も検討します。
入力のサイズが有限で事前にわかっているバッチトランスフォームとは対照的に、ステートフルストリーミング ↗ アプリケーションでは、状態に上限がなく、時間の経過とともに増大し、将来の予測できない時点でメモリー不足エラーが発生する可能性があります。たとえば、1個以上のキーで集計を行う場合、キー空間のサイズに上限がなければ、一般に危険な操作となります。バッチコンピューティングとは異なり、通常、十分なリソースを予測して確保することは困難です。このため、また、ほとんどのストリーミングアプリケーションが時間に関わる性質を持つことから、ストリーミングトランスフォームを設計する際には、状態が無制限に増大しないようにしてください。
低遅延は通常、ストリーミングパイプラインの重要な要件ですが、低遅延を実現する手順は必ずしも明確ではありません。ストリーミングパイプラインには通常、複数のステップがあるため、すべての層の中で最も大きな遅延が全体の遅延を制約します。そのため、低遅延を実現するには、ソースシステムからストリーミングアプリケーション、下流の利用側に至るまで、複数のアプリケーションとデータ利用層を細かく調整する必要がある場合があります。
バッチパイプラインは通常、厳格な低遅延要件を持つ業務ワークフローには使用されないため、ストリーミングパイプラインに比べてダウンタイムへの許容度が高い傾向があります。バッチパイプラインは通常、固定されたスケジュールで実行されます。個々の実行が失敗しても、通常は大きな問題にはならず、ビルドを再試行できます。対照的に、ストリーミングパイプラインは、定義された終了点を持たない継続的に実行されるプロセスであり、障害による影響はより大きくなることがよくあります。リアルタイムデータを保持するデータストアでの10分間の停止は、毎日更新されるデータストアでの10分間の停止よりも、はるかに大きな影響を及ぼします。
バッチパイプラインでは通常、データの読み取りや書き込みよりもトランスフォームが処理のボトルネックになるため、ほぼどのようなデータ利用層でも使用できます。ストリーミングパイプラインでは、低遅延を維持するために、高速で頻繁な書き込みをネイティブにサポートするデータ利用層が必要です。つまり、エンドツーエンドの低遅延を確保するには、エンドツーエンドのパイプラインに含まれる各アプリケーションが低遅延でデータを処理できる必要があります。Pipeline Builder、時系列、Foundry Rules、オントロジーを含む、ほとんどの Foundry 製品は、これをネイティブにサポートしています。外部システムへの低遅延での書き込みをサポートするデータコネクターもあります。
高スループットかつ低遅延の計算を行うため、ストリーミングパイプラインの平均コストは、バッチパイプラインの平均コストよりも高くなることがよくあります。ただし、データの低遅延処理を必要とするストリーミング向きのパイプラインでは、継続的に実行されるバッチパイプラインと比較して、ストリーミングが最も費用対効果の高いソリューションになる可能性があります。
ストリーミングのコストの計算方法について詳しくは、Foundry Streaming のコンピューティング使用量を確認してください。