注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundryでデータをストリームとして処理するか、バッチデータセットとして処理するかを決定する際には、特定のユースケースの要件を理解することが重要です。ストリーミングとバッチのパイプラインの特性、パフォーマンス、技術的期待値を考慮し、ユーザーのユースケースに最適なツールを選択することを推奨します。
一般的に、ストリーミングはエンドツーエンドの遅延が少ないワークフローに使用されます。10分以上の遅延が許容できるユースケースの場合、incrementalや標準的なバッチdatasetsも適切な解決策となるかもしれません。
ストリーミングとバッチのパイプラインは多くの共通の特性を共有しています。主に考慮すべき違いは遅延、計算コスト、サポートされる変換言語です。以下の表は、ストリーミングとバッチのパイプラインで利用可能な機能を示しています。
| 特性 | ストリーミング | バッチ |
|---|---|---|
| すべての Foundry 製品での高遅延データ利用 | はい | はい |
| トランザクション性 | はい | はい |
| アトミック | はい | はい |
| ブランチング | はい | はい |
| セキュリティマーキングと分類 | はい | はい |
| 由来追跡 | はい | はい |
| オントロジー対応 | はい | はい |
| タイムシリーズ対応 | はい | はい |
| Java による変換のサポート | はい | はい |
| Pipeline Builder のサポート | はい | はい |
| Python による変換のサポート | いいえ | はい |
| 低遅延データアクセス | はい | いいえ |
一部の Foundry フロントエンドツールは、ストリーミングデータセットを "リアルタイム" で消費することができます。例えば、グラフのライブ更新などです。ストリームをネイティブに消費できるツールには、オントロジー、Pipeline Builder、Quiver、Dataset Preview、Foundry Rulesがあります。Foundryの他のアプリ、例えばContourは、ストリームのアーカイブデータセットを消費することができます。これは、ストリームの最新のデータで数分ごとに更新される標準のバッチデータセットです。実際には、任意のアプリでストリーミングデータセットを選択でき、Foundryは自動的にどのモードを使用するかを判断します。
機能に関する考慮事項と同様に、ストリーミングとバッチのパイプラインの異なるパフォーマンスの期待値を考慮します。これらの要素には遅延とスループットが含まれます。詳細はストリーミングの遅延とスループットに関する考慮事項を参照してください。
ストリーミングとバッチ処理の特性とパフォーマンスの要素を定義する上で、状態管理、ダウンタイムの影響、消費レイヤの遅延などの技術的な要素を考慮します。
バッチ変換とは対照的に、入力のサイズが制約されており、事前に知られている場合、stateful streamingアプリケーションは無制限の状態を持つ可能性があり、それが時間とともに増大し、未知の時点でメモリ不足のエラーを引き起こす可能性があります。例えば、1つ以上のキーに対する集計を行うことは、キー空間のサイズが無制限である場合、一般的に危険な操作です。バッチ計算とは異なり、通常は十分なリソースを確保し、予測するのが難しいです。このため、ほとんどのストリーミングアプリケーションが時間的な性質を持つため、ストリーミング変換を設計する際には状態の増大が無制限でないことを確認してください。
低遅延は通常、ストリーミングパイプラインの重要な要件ですが、低遅延を達成するのは常に明確なプロセスではありません。ストリーミングパイプラインは通常、複数のステップを持つため、遅延はすべてのレイヤーでの最高の遅延によって制約されます。したがって、低遅延を達成するためには、ソースシステムからストリーミングアプリケーション、下流の消費者まで、複数のアプリケーションと消費レイヤーを微調整することが必要になるかもしれません。
バッチパイプラインは通常、厳格な低遅延要件を伴う運用ワークフローには使用されず、ストリーミングパイプラインと比較してダウンタイムに対する許容度が高い傾向があります。バッチパイプラインは通常、固定スケジュールで実行され、個々の実行の失敗は通常、大きな問題ではなく、ビルドを再試行することが可能です。一方、ストリーミングパイプラインは定義されたエンドポイントがない連続した実行プロセスであり、障害はよく影響を及ぼします。リアルタイムデータを保持するデータストアの10分間の停電は、日次更新のデータストアの10分間の停電よりもはるかに大きな影響があります。
バッチパイプラインは通常、データの読み書きよりも変換によって遅れるため、ほぼ任意の消費レイヤーが使用できます。ストリーミングパイプラインの場合、低遅延を維持するためには、高速で頻繁な書き込みをネイティブにサポートする消費レイヤーが必要です。これは、エンドツーエンドのパイプラインの各アプリケーションが低遅延でデータを処理できるようにすることで、エンドツーエンドの遅延を低く保つことを意味します。ほとんどの Foundry 製品はこれをネイティブにサポートしており、Pipeline Builder、タイムシリーズ、Foundry Rules、オントロジーなどが含まれます。また、外部システムへの低遅延書き込みをサポートするデータコネクタも存在します。
高スループット、低遅延の計算のため、ストリーミングパイプラインの平均コストは、バッチパイプラインの平均コストよりも高いことがよくあります。しかし、データの低遅延処理が必要なストリーミング形状のパイプラインの場合、ストリーミングが連続して実行されるバッチパイプラインと比較して最もコスト効率の良い解決策となる可能性があります。
ストリーミングのコストがどのように計算されるかについての詳細は、Foundry Streaming における計算使用量を参照してください。