注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ストリーム
データセットと同様に、ストリームは、データが Foundry に到着してから下流システムで処理されるまでのデータを表します。ストリームは、永続的な「ホットバッファー」と、ファイルシステムに基づく「コールドストレージ」の両方に保存される行をまとめたラッパーです。Foundry ストリームを使用する利点は、Foundry データセットと同じ基本機能（ブランチ、バージョン管理、権限管理、スキーマ管理など）を提供しながら、データの低遅延ビューも提供することです。
ストリームは必ず表形式であり、そのため必ず構造化されています。ストリームは、Avro ↗ などのオープンソース形式で、列自体に関するメタデータとともに保存されます。このメタデータは、スキーマとしてストリームとともに保存されます。
ストリームのストレージ
ホットバッファー
レコードが Foundry ストリームに流入すると、ホットバッファーに保存されます。ストリームの読み取りをサポートするすべての下流アプリケーションは、このホットバッファーを低遅延で利用できます。このホットバッファーは、低遅延のトランスフォームとデータの可用性を実現するために不可欠です。データ取り込みには at-least-once セマンティクスを提供し、プラットフォーム内のデータ処理には任意で exactly-once セマンティクスを提供します。
コールドバッファー
Foundry ストリーム内のすべてのデータは、数分ごとにホットバッファーからコールドストレージに転送されます。このプロセスを「アーカイブ」と呼びます。これにより、データを標準の Foundry データセットとして利用できるようになります。つまり、Foundry アプリケーションは、ホットバッファーのデータをリアルタイムで処理しなくても、ストリーミングデータを扱えます。Foundry ストリームのデータセットビューは、プラットフォーム内の標準の Foundry データセットとまったく同じように動作します。
ストリーム処理
ストリームからデータを読み取る
低遅延が有効になっている Foundry 製品は、データのハイブリッドビューを読み取れます。ホットストレージ層とコールドストレージ層の両方からデータを読み取ることで、製品はデータの完全なビューを提供できます。このビューにより、製品はホットストレージに残っている低遅延のレコードと、コールドストレージに転送された古いデータにアクセスできます。このように、Foundry ストリームは、ホットストレージの低遅延とコールドストレージの低いストレージコストの両方の利点を活かせます。
トランザクション
標準の Foundry データセットとは異なり、ストリーム自体にはトランザクション境界がありません。代わりに、各行がそれぞれ独立したトランザクションとして扱われ、状態は行単位で追跡されます。これにより、ストリームを細かい粒度で読み取れるため、Foundry はバッチ処理やポーリングを必要とせずにプッシュベースのデータ加工をサポートできます。
ストリームの種類
各ストリームに必要なスループットに基づいて、ストリームの種類を設定できます。これらのストリームの種類の設定は、前述のホットバッファーストレージへのデータの書き込み方法に適用されます。ストリームメトリクスが、ホットバッファーストレージへの書き込みにボトルネックが生じていることを示している場合にのみ、ストリームの種類の設定を変更する必要があります。遅延とスループットはトレードオフの関係にあるため、高スループットまたは圧縮のストリームの種類を設定するのは、ストリームメトリクスを確認した後にしてください。 次のストリーム設定をサポートしています。
- 高スループット： 毎秒大量のデータを送信するストリームに最適です。このストリームの種類を有効にすると、スループットが高くなる代わりに、ゼロではない遅延が発生する場合があります。そのため、有効にする前にストリームメトリクスを確認してください。平均バッチサイズが最大バッチサイズに等しい場合、または Kafka の生成元のバッチの有効期限切れによってジョブに失敗する場合は、高スループット設定を有効にする必要がある可能性があります。
- 圧縮： この設定を有効にすると、ホットストレージのバッファーにデータを生成する際にメッセージバッチが圧縮されます。圧縮によって送信されるデータのサイズが小さくなり、ネットワーク使用量とストレージ使用量が減少しますが、圧縮と展開のために CPU 使用量が多少増加します。このストリームの種類を有効にすることを推奨するのは、ストリームに繰り返し出現する文字列が大量に含まれ、ゼロではないラグ、期待される値より低いスループット、レコードの欠落など、ネットワーク帯域幅不足の症状が発生している場合のみです。
新しいストリームを作成する際に、定義ページでストリームの種類を設定できます。既存のストリームについても、ストリーム設定でストリームの種類を更新できます。これを行うには、Foundry でストリーミングデータセットに移動し、ツールバーで詳細を選択します。次に、ストリーム設定に移動します。ここでストリームの種類を変更し、圧縮を有効または無効にできます。
パーティション
高いスループットを維持するために、Foundry は入力ストリームを複数のパーティションに分割して並列処理します。ストリームを作成する際に、スループットスライダーで作成するパーティションの数を制御できます。データはパーティション分割されますが、ストリームに対するすべての読み取りと書き込みは、パーティションが1個しかないかのように動作します。この動作により、Foundry ストリームの利用側と生成元側は、内部設計を意識せずに使用できます。
ストリームにパーティションを1個追加するたびに、そのストリームで処理できる最大スループットが増加します。目安として、パーティション1個ごとにスループットが約 5mb/s 増加します。
サポートされているフィールドのデータ型
Foundry ストリームは、Foundry データセットと同じデータ型をサポートしています。これには次のデータ型が含まれます。
BOOLEANBYTESHORTINTEGERLONGFLOATDOUBLEDECIMALSTRINGMAPARRAYSTRUCTBINARYDATETIMESTAMP
ストリーミングジョブ
すべてのストリーミングジョブは、内部的にジョブグラフとして表現されます。ジョブグラフは、ストリーミングパイプラインを視覚的に表します。データは処理される際に、有向エッジに沿ってジョブグラフを流れ、最終的にデータシンクに到達します。
Checkpoint の作成
Foundry ストリーミングは、アクティブな状態と現在の処理場所の両方を Checkpoint に保存することで、データ処理中の耐障害性を提供します。
Checkpoint はデータソースによって定期的に生成され、ソースからのデータとともにジョブグラフを流れます。 Checkpoint がジョブグラフの終端にあるすべてのデータシンクに到達した時点で、ソースがその Checkpoint より前に発行したすべての行も、必ずシンクに到達しています。
Checkpoint により、すでに読み取ったデータを再処理することなく、最新の Checkpoint の時点からストリーミングジョブを再開できます。Checkpoint には、ジョブグラフ内の各オペレーターの状態に加えて、ストリーム内で最後に処理されたデータポイントが保存されます。ストリーミングジョブのジョブ詳細ページでは、ストリームの直近数回の Checkpoint のステータス、サイズ、所要時間をリアルタイムで確認できます。
ストリーミングの整合性保証
Foundry のストリーミングは、AT_LEAST_ONCE と EXACTLY_ONCE の2つの整合性保証で動作します。
AT_LEAST_ONCE セマンティクス
AT_LEAST_ONCE セマンティクスは、メッセージが下流に少なくとも1回配信されることを保証しますが、Checkpoint 処理の失敗や再試行が発生した場合、メッセージが複数回配信されることがあります。つまり、重複が発生する可能性があるため、メッセージを受信するアプリケーションは、重複メッセージに対応できる、または重複を許容できるように設計する必要があります。
AT_LEAST_ONCE セマンティクスの利点
- メッセージが失われないことを保証し、高いメッセージ耐久性を提供します。
- レコードの管理処理でブロックされることなくメッセージを配信できるため、一般に
EXACTLY_ONCEセマンティクスよりも低遅延です。
AT_LEAST_ONCE セマンティクスの欠点
- 下流でメッセージを受信するアプリケーションが、重複メッセージに対応できる必要があります。
EXACTLY_ONCE セマンティクス
EXACTLY_ONCE セマンティクスは、各メッセージが正確に1回だけ配信および処理されることを保証し、メッセージの重複や欠落がないことを保証します。これは最も強いメッセージ配信保証であり、メッセージを受信するアプリケーションの設計を大幅に簡素化できます。
EXACTLY_ONCE セマンティクスの利点
- メッセージが失われないことを保証し、高いメッセージ耐久性を提供します。
- メッセージを受信するアプリケーションで、重複メッセージへの対応や冪等な処理の実装が不要になります。
- 各メッセージが正確に1回だけ処理されるため、処理結果の整合性を保証します。
EXACTLY_ONCE セマンティクスの欠点
- メッセージの重複を防ぐために追加の調整と追跡が必要になるため、通常は
AT_LEAST_ONCEセマンティクスよりも遅延が大きくなります。Foundry のストリーミングは、Checkpoint 処理によってこの問題を解決します。
遅延のトレードオフ
AT_LEAST_ONCE と EXACTLY_ONCE セマンティクスのどちらを選択するかは、多くの場合、遅延と処理の複雑さのトレードオフになります。AT_LEAST_ONCE セマンティクスは、複雑な調整や追跡の仕組みを必要としないため、一般に低遅延ですが、重複への対応と整合性の維持について、メッセージを受信するアプリケーションがより多くの責任を負います。EXACTLY_ONCE が有効な場合、レコードは各 Checkpoint が完了した後にのみ下流で表示されます（デフォルトは2秒です）。なお、レコードの処理自体はストリーミングの速度で進みますが、下流で表示されるのは「確定」したときだけです。
一方、EXACTLY_ONCE セマンティクスは、各メッセージが正確に1回だけ処理されることを保証するため、より強い保証を提供し、メッセージを受信するアプリケーションの設計を簡素化できます。ただし、この保証には追加のオーバーヘッドが必要であり、その代償として遅延が大きくなります。
Foundry のストリーミングソースは現在、抽出とエクスポートについては AT_LEAST_ONCE セマンティクスのみをサポートしています。ストリーミングパイプラインでは、AT_LEAST_ONCE と EXACTLY_ONCE の両方のセマンティクスがサポートされており、Pipeline Builder のビルド設定セクションで設定できます。
