注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry Streaming は、高スループットかつ低遅延のコンピュート形態です。新しく到着するメッセージを継続的に待ち受け、ユーザー定義のロジックを適用して、パイプラインの次の段階に送信します。
Foundry のストリームは、分散並列ワーカーベースのアーキテクチャを採用しています。並列ワーカーにはそれぞれ、担当するストリーミングジョブ専用のリソースが割り当てられます。ストリームに必要なリソース量は、アクティブなストリームの最大スループットと、処理するメッセージの総数に応じて増加します。
ストリーミングのコンピュート使用量は、次の2種類に分かれます。
ライブ処理コンピュート: ライブデータに対してユーザー定義のトランスフォームを実行する処理です。このソースの種類は「streaming」と呼ばれます。
アーカイブコンピュート: ストリーミングレイヤーから Foundry のストレージレイヤーにデータを移動する処理です。アーカイブコンピュートはバッチ処理であり、「transform」として表示されます。
Foundry の使用量に対して支払う場合、デフォルトの streaming_usage_rate は 0.5 です。これは、ライブデータに対してユーザー定義のトランスフォームを実行する際のレートです。Palantir とエンタープライズ契約を結んでいる場合は、コンピュート使用量の計算を進める前に Palantir の担当者にお問い合わせください。
Foundry のストリームのライブ処理コンピュートは、実時間での実行期間全体にわたって使用するコンピュート秒数で測定されます。したがって、ストリーミングジョブで使用するコンピュートリソース(vCPU、メモリー、並列化など)が多くなるほど、ジョブのコストは増加します。ジョブの実行時間が長いほど、使用するコンピュート量も増加します。ストリームは継続的に実行してデータを処理し続けるように設計されているため、ユーザーが終了するまでコンピュートを使用し続けます。
ストリームのリソースは静的に割り当てられます。ストリームの実行中は、実時間の1秒あたりに一定のコンピュート秒数を使用します。また、ストリームはピーク時の需要に対応するように調整されることが多いため、ストリームのコンピュート使用量はデータ量の変動による影響を受けません。ストリームは、データが流れていない場合でもコンピュート秒数を使用します。
ストリームの使用量は、1つのジョブマネージャーと多数のタスクマネージャーが使用する総秒数の合計として計算できます。各並列ワーカーのコンピュートリソースは同一です。
ジョブマネージャーのコンピュート秒数は、次のように計算します。
max(num_vCPU, gib_ram / 7.5) * streaming_usage_rate * stream_duration_secondsタスクマネージャーのコンピュート秒数は、次のように計算します。
max(num_vCPU, gib_ram / 7.5) * streaming_usage_rate * stream_duration_seconds * (num_parallel_task_managers + 1)compute_seconds = job_manager compute_seconds + task_manager_compute_secondsコンピュート使用量の計算に使用する値については、メモリー対コア比率などの説明で詳しくはこちらをご覧ください。
アーカイブジョブは、各ストリームと並列して実行されるバッチ処理ジョブです。アーカイブジョブは、ストリームのホットストレージレイヤーから定期的にデータを読み込み、Foundry ストレージに移動して、堅牢な永続化と履歴の追跡を実現します。アーカイブジョブにはストリーム自体と同じ低遅延の要件がないため、スケジュールに従って実行され、アーカイブ対象のデータがある場合にのみコンピュートを使用します。
アーカイブジョブの使用量は、1つの Spark ドライバーに基づいており、次の式で計算できます。
compute_seconds = max(num_vcpu, gib_ram / 7.5) * num_seconds
ストリームの総使用量を表示するには、まず Resource Management アプリケーションに移動します。次に、リソース別の使用量セクションでストリームを見つけ、詳細を選択してデータセットごとの使用量を表示します。

ストリームのコストは、そのストリームが生成するチェックポイントデータセットに帰属します。このデータセットは、ストリームの処理に関する永続的な使用量の記録として機能します。このデータセットのストリーミング使用量は、Resource Management アプリケーションの「streaming」カテゴリーに分類されます。
ストリームを実行すると、ユーザーが停止するまで継続して実行されます。ユーザーがストリームを停止すると、その実行がデータセットの履歴タブに表示されます。個々のストリームのプロファイルを調査して、過去のストリーム実行のパフォーマンスとコンピュート使用量を確認できます。
履歴アーカイブを実行するたびに、そのコンピュートメトリクスが Builds アプリケーションに公開されます。Builds アプリケーションを使用して、実行された各アーカイブのリソース割り当てを調査します。
ストリームの使用量を左右する主な要因は、ストリーム自体が占有するコンピュートリソースの量です。この場合、コンピュートリソースには、タスクマネージャーあたりの vCPU 数、パーティションあたりの RAM の GiB 数、ストリームのパーティション数が含まれます。これらのリソースはストリームのプロファイルで設定され、ストリームの実行期間中は維持されます。
特定のワークフローでストリーミングを選択すべき場合と、バッチを選択すべき場合を理解することが重要です。ストリーミングは、秒単位の低遅延と常時のコンピュートを必要とするワークフロー向けに設計されています。データを数分ごとに処理してもよい場合は、小規模なマイクロバッチジョブを検討してください。マイクロバッチジョブは、ストリームと同じ量のデータを送信できますが、コンピュート秒数のコストが低くなる一方で、データの遅延は大幅に増加します。
次の例では、10分間実行される仮想的なストリームのコンピュート使用量を計算する方法を示します。ただし、ほとんどの本番ストリームは継続的に実行されます。
ストリームのプロファイル
計算
このストリームを10分間実行した場合の総コンピュート使用量は、ジョブマネージャーが150コンピュート秒、タスクマネージャーが450コンピュート秒です。Foundry のコンピュート使用量に影響する要因について、詳しくはこちらをご覧ください。