注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry ストリームでは、1個以上の列をキー列として指定できるほか、解決済みレコードを識別するための主キーも指定できます。以下のセクションでは、ストリーミングパイプラインのパーティションキーと主キーの両方を設定し、維持する方法を説明します。
一般に、Palantir プラットフォームの主キーは、データベースのレコードを一意に識別するために使用されます。一方、Foundry ストリームのパーティションキーは、同じキーを持つレコードをグループ化します。たとえば、特定のデバイスのすべての測定値や、特定の顧客のすべてのトランザクションなどです。バッチパイプラインの主キーとは異なり、ストリームのパーティションキーはレコードを一意に識別しないため、レコードの重複排除を行いません。
Foundry のキーを使用すると、特定のキーに対応するすべてのレコードの順序が維持されることを保証できます。レコードが Foundry に入ると、内部の Kafka に保存されます。Kafka は、同じパーティションに書き込まれたレコードについて、読み取り時と書き込み時に順序が維持されることを保証します。キーなしで Foundry に送信されたレコードは、内部の Kafka トピック内のいずれかのパーティションにラウンドロビン方式で書き込まれます。一方、ユーザーがレコードのキーを指定すると、そのキー専用のパーティションにレコードが書き込まれるため、下流での読み取り時にも順序が維持されます。
同様に、Flink ストリーミングジョブは、入力ソースに設定されたパーティションキー列に基づいて順序を自動的に維持します。Flink のデータ加工ジョブは、データ加工操作ごとに1個以上の並列パーティションで実行される場合があります。パーティションキーが設定された入力ストリームでは、Flink ジョブは、すべてのキー列の値が同じレコードを、同じ並列オペレーターインスタンスに自動的に送信します（キー指定 データ加工などで）明示的にキーを再設定しない限り、パイプライン全体のパーティション分割と順序付けは、ソースに存在した時点のキー列と行の値によって決まります。これは、データ加工ロジックによって列が削除されたり、値が上書きされたりした場合も同じです。
Foundry ストリームの主キーは、リレーショナルデータベースやバッチデータセットで使用される主キーと同様に機能します。ただし、ストリーミングの主キーは、解決済みレコードを一意に識別する重複排除列で構成され、順序付け列は指定しません。
主キーは、Foundry のストリームのスキーマに格納されるメタデータです。キーは、保存されるデータの内容や、ストリーミングデータパイプラインとデータ加工の適用方法には影響しません。主キーは、一部の Foundry コンシューマーによるデータの読み取り方法を制御します。データ全体は変更履歴と考えることができ、主キーは、すべての変更を適用した後に、重複排除されたデータの現在のビューを計算する方法をコンシューマーに伝えます。
現在のビューは、キーごとに最後にストリーミングされたレコードだけを含む、絞り込み済みのデータのビューです。キーに対応する最新のレコードは、nulls を含む場合でも、常に全体が保持されます。削除済みを示す列が指定されていて、キーに対応する最後にストリーミングされたレコードのこの値が true に設定されている場合、そのレコードは除外されます。
次の例は、主キーとデータストリームを示しています。最後にストリーミングされた行ほど、テーブルの上部にあります。
主キー: {Dedeuplication column(s): [Key], isDeletedColumn: Optional[isDeleted]}
| Key | Value | isDeleted |
|------|-----------|-----------|
| Key2 | null | false |
| Key1 | thirdVal | true |
| Key2 | secondVal | false |
| Key1 | firstVal | false |
この変更履歴のストリームを CDC 対応のコンシューマーが読み取ると、次の現在のビューとして読み取られます。
| Key | Value | isDeleted |
|------|-----------|-----------|
| Key2 | null | false |
ストリーミングデータに主キーを設定する場合は、順序を維持して重複排除済みのデータビューを正しく解決するために、同じ列をパーティションキーとしても設定する必要があります。ストリーミングのセットアップインターフェースで主キーを設定すると、同じ列がパーティションキー列として自動的に追加されます。
次の2つの CDC 対応ジョブは、主キーが設定されたストリーミングデータを現在のビューとして自動的に読み取ります。
Pipeline Builder は、パイプラインのデータ加工を通じてパーティションキー列と主キー列の両方の変化を追跡し、有効なキーを出力ストリームのスキーマに書き込みます。データ加工によってキー列が無効化されなければ、連続する下流のパイプラインの数にかかわらず、同じパーティション分割と重複排除の指示が自動的に維持されます。
キー列の名前を変更すると、新しい列名を含むようにキーが更新されます。同様に、キー列を削除または上書きするデータ加工を適用すると、その列はキーから外されます。キー列の内容の上書きは、新しい順序保証や新しい重複排除戦略を表している可能性があるため、Pipeline Builder はその列をキーから完全に外します。以前に上書きされたキー列を保持するには、キー指定データ加工を再度適用する必要があります。削除や上書きによってパーティションキー列が外された場合でも、キーを再設定しない限り、パイプラインの残りの部分では同じ順序保証が維持されます。
すべてのパーティションキーまたは重複排除用の CDC キーが削除または上書きされると、キー自体が完全に削除されます。キー列の内容を削除または上書きする際は注意してください。順序保証や重複排除戦略が失われるなど、予期しない結果につながる可能性があります。
現在、ユーザー定義関数 (UDF) では、キーは決して伝播しません。関数はユーザーが定義するため、キーの伝播を意図しているかどうかや、意図している場合の伝播戦略を推測する方法がありません。キーを伝播させる場合は、必ず UDF の後にキー指定データ加工を適用してください。
また、ステートフルなデータ加工では、主キーは伝播しません（ほとんどのデータ加工はステートフルではありません）。
Pipeline Builder アプリケーションのストリーミングパイプラインで、グラフにキー指定データ加工を追加します。ここで設定したキーは、入力データに設定されていたキーをすべてオーバーライドし、置き換える点に注意してください。
パーティションキーのみを設定する場合は、CDC モードオプションをオフに切り替え、キー指定列のリストのみを指定します。CDC モードでない限り、ほかのパラメーターは不要であり、指定することもできません。
主キーとパーティションキーの両方を設定するには、CDC モードオプションをオンに切り替えます。isDeleted 列がある場合は、必要に応じて主キーの削除済みフラグ項目に指定します。ストリーミングのユースケースでは、任意の主キーの順序付け列パラメーターを空欄のままにすることを強く推奨します。このデータ加工では、パーティションキーと主キーの両方が設定され、パーティションキー列は主キーの重複排除列と同じになります。主キーの順序付け列パラメーターが意味を持つのは、バッチジョブでアーカイブデータセットを読み取る場合のみであり、ストリーミングでの重複排除の処理方法に影響することはありません。順序付け列を指定するオプションは、下位互換性のため、バッチのデータ加工を使用するユーザーのため、またはストリームのアーカイブを特定のバッチ専用の方法で読み取ることを意図しているユーザーのために利用可能です。
以下のセクションでは、Foundry ストリームのストリーミングキーロジックを見つけて確認する方法を説明します。
ストリーミングデータセットを開き、詳細タブに移動してから、スキーマタブを開いてデータスキーマを JSON で表示します。
includeInParitioning を検索します。主キーの一部である列ごとに、fieldSchemaList の要素内に表示されます。
"customMetadata": {
"includeInPartitioning": true
}
includeInParitioning を持つスキーマフィールドが見つからない場合、ストリームにキーが設定されておらず、データの保存や処理における順序は保証されません。手動でキーを追加するには、スキーマを JSON テキストとして編集し、パーティションキー列として設定する各スキーマフィールド（列）にカスタムメタデータを挿入します（前述の説明を参照）。
ストリームにすでに1個以上のパーティションキーがある場合、新しいパーティションキー列を追加するとパーティションが増えるため、順序保証が弱くなります。順序の維持が保証されるのは、すべてのパーティションキー列で同じ値を共有する行のみです。
デプロイ前に、パイプラインへの入力ストリームにパーティションキー列が設定されている場合、意図的にキーを再設定しない限り、パイプライン全体にわたり、そのソースとすべてのトランスフォームの順序が保証されます。パーティションキー列は、データプレビューでキーの記号付きで表示される場合があります。
ストリーミングデータセットを開き、詳細タブに移動してから、スキーマタブを開いてデータスキーマを JSON で表示します。
primaryKey という名前の JSON プロパティが表示されます。ストリームに uniqueCol1 および uniqueCol2 という重複排除列があり、isDeleted 列が isDeletedCol である場合、スキーマは次のようになります。
"primaryKey": {
"columns": [
"uniqueCol1",
"uniqueCol2"
],
"resolution": {
"type": "duplicate",
"duplicate": {
"resolutionStrategy": {
"type": "customStrategy",
"customStrategy": {}
},
"deletionColumn": "isDeletedCol"
}
}
}
主キーが設定されていない場合、スキーマには null が表示されます。
"primaryKey": null
主キーを手動で設定または削除するには、スキーマ JSON を編集して上記の形式でキーを指定するか、null を使用してキーを削除します。主キーを手動で設定する場合は、同じ列をパーティションキー列として設定することを強く推奨します。
順序を保証する唯一の方法は、ストリーミングのリネージ全体にパーティションキー列を設定することです。設定すると、パーティションキー列は自動的に下流に伝播します。パーティションが1個のみになるようにストリームが設定されている場合でも、Flink アプリケーションのスケーリング方法と、レコードを非決定的に処理する仕組みにより、順序が必ずしも保証されるわけではありません。
レコードの分散が非効率になるキーは、不要な負荷の増加やスループットの制限を招く可能性があるため、パーティションキーは慎重に選択してください。ユースケースにおいて順序が重要な場合は、メールID、顧客ID、組織IDなど、順序を維持したい汎用的なグループ化識別子をパーティションキーとして設定します。ユースケースにおいて順序が重要でない場合は、一意の ID をキーとして使用するか、ストリームにキーをまったく使用しないことを選択できます。
最終的なストリーミング出力の順序保証は、出力に至るまでのストリームの連なり（Kafka トピックに基づいています）とトランスフォーム（Flink ジョブ）における_最も弱い_保証と同じ強さになります。そのため、レコードを Foundry に取り込む最初のストリーミング抽出から始まるデータリネージ全体で、希望する順序が維持され、正しいパーティションキーが設定されていることを確認してください。順序保証は、Foundry への抽出元システムの保証より強くなることはありません。たとえば、Kafka コネクターを使用して Kafka から抽出する場合は、パーティションキー列を Kafka キー列と同じに設定すると、Foundry で元のシステムと同等の順序保証を維持できます。
また、一連のデータトランスフォームの途中でパーティション列（および順序保証）を完全に変更すると、問題が発生する可能性があります。新しいキー指定トランスフォームを適用する前に別の順序が保証されていた場合、そのトランスフォームは、新しく追加されたキー列に対して順序が乱れたレコードを受け取ります。これらのレコードは、一連のトランスフォームの処理中も誤った順序のままになります。