実体化

最新のデータは、多くの Foundry ワークフローにとって重要です。オントロジーのユーザーは、入力データソースとユーザー編集の両方のデータを組み合わせて、各オブジェクトインスタンスの最新の状態を含むオントロジーからインデックス化されたデータの実体化を作成できます。

実体化のユースケース

実体化の主なユースケースは2つあります。

• ユーザー編集を含む各オブジェクトインスタンスの最新の状態が必要な下流の Foundry パイプラインを構築する。
• オブジェクトタイプのすべてのオブジェクトインスタンスの最新の状態を含むオントロジーデータのダウンロードを可能にする。

実体化されたデータセットを作成する

オントロジー管理でデータソースタブの編集設定を切り替えることで実体化タブに移動します。実体化タブでは、入力データソースタイプに応じて、さまざまな設定でオブジェクトのデータセット、制限付きビュー、またはオブジェクトストリームを実体化できます。

書き戻しデータセットと実体化されたデータセットの比較

Object Storage V1（Phonograph）の書き戻しデータセットは、実体化されたデータセットと同等です。書き戻しデータセットは、OSv1でオブジェクトタイプまたは結合テーブルを持つ多対多のリンクタイプのユーザー編集を有効にするために必要です。

Object Storage V2 では、実体化されたデータセットを使用してユーザー編集を有効にする必要はありません。代わりに、ユーザーはオントロジー管理のデータソースタブで編集設定を切り替えることで、オブジェクトタイプのユーザー編集を有効にできます。これにより、OSv2では実体化がオプションとなり、ユーザーは上記の2つの主要なユースケースが必要な場合にのみ実体化を作成する必要があります。 OSv2 では、オブジェクトタイプのプロパティの一部だけを実体化する場合など、複数の実体化されたデータセットを作成できます。

OSv1 の書き戻しデータセットと OSv2 の実体化されたデータセットの間には、他にも以下に説明するような動作の違いがあります。

書き戻しデータセットと実体化されたデータセットのビルドスケジュール

Object Storage V1（Phonograph）の書き戻しデータセットと Object Storage V2 の実体化されたデータセットでは、ビルドスケジュールの処理が異なります。

• OSv1では、新しいユーザー編集がある場合に書き戻しデータセットのビルドをトリガーする仕組みはありません。代わりに、ユーザーはスケジュールを作成して、書き戻しデータセットを必要なだけビルドできます。新しいデータがない場合、これらのビルドは追加のコンピューティングを使用しないように自動的に中止されます。スケジュールが設定されておらず、書き戻しデータセットがビルドされていない場合、書き戻しデータセットのデータはオントロジーの正確な表現ではないかもしれません。
• OSv2 は、2つの異なるユースケースを別々に対処するように設計されています。
  • 実体化されたデータセットで編集が適用されるのと同じように、ユーザー編集を反映させるために、ユーザー編集の自動伝播を有効にできます。このモードでは、ユーザー編集が自動的に（数分の遅延で）設定された実体化されたデータセットに伝播されます。これにより、新しいユーザー編集の頻度に応じて、より頻繁なビルドが発生する可能性があり、追加のコストが発生する場合があります。
  • ユーザー編集の伝播の遅延が実体化されたデータセットにとって重要でない場合、ユーザーは定期的なビルドを設定することでコストを削減できます。このモードでは、実体化されたデータセットは、入力データソースに新しいデータがある場合、または6時間ごとに再構築されます。

書き戻しデータセットと実体化されたデータセットの保持

書き戻しデータセットと実体化されたデータセットの保持は同じようには機能しません。

• OSv1では、書き戻しデータセットは通常のデータセットのように機能し、プラットフォーム内で指定できる保持ポリシーを適用できます。これにより、書き戻しデータセットが定期的にビルドされる場合、オブジェクトタイプの状態の履歴スナップショットを参照できます。

• OSv2では、実体化されたデータセットはカスタマイズできない保持に対象となります。履歴トランザクションは常に削除され、最新のスナップショットのみが利用可能であることが保証されます。この場合、ユーザーはオブジェクトタイプの状態の履歴スナップショットを保持することが重要である場合、下流の変換を設定する必要があります。

書き戻しデータセットと実体化されたデータセットのデータセットスキーマ

Object Storage V1（Phonograph）の書き戻しデータセットと Object Storage V2 の実体化されたデータセットは、入力データソーススキーマに対して異なる関係を持ちます。

• OSv1では、入力データソースのスキーマがコピーされ、書き戻しデータセットのスキーマとして使用されます。
• OSv2 では、この動作が変更され、Foundry オントロジーの可読性が向上します。ユーザーがオントロジーからデータを実体化しているため、実体化されたデータセットのスキーマは、元のデータソースの設定に依存するのではなく、オントロジーの定義からコピーされます。具体的には、各プロパティのAPI 名メタデータが、実体化されたデータセットのスキーマとして使用されます。OSv1 から OSv2 への移行中に入力データソースのスキーマを引き続き使用したい場合（たとえば、既存の書き戻しデータセットの後方互換性を保証するために）、Palantir の担当者に連絡してください。

書き戻しデータセットと実体化されたデータセットの制限付きビュー

Object Storage V1（Phonograph）では、入力データソースとして制限付きビューを使用して粒度のある許可が設定されたオブジェクトタイプの制限付きビューを実体化することはできません。ユーザーは、制限付きビュー入力データソースの元のデータセットのすべての行を含む書き戻しデータセットを実体化することしかできません。その後、ユーザーはアクセス制限に基づいて書き戻しデータセットへのアクセスを適切に保護する責任があります。

Object Storage V2 では、入力データソースとして制限付きビューを使用して粒度のある許可が設定されたオブジェクトタイプのために、通常のデータセットまたは制限付きビューを実体化リソースとして設定できます。以下に示すように。

オブジェクトタイプに複数の入力データソースがある場合、ユーザーはどの入力データソースからデータを実体化したいかを選択することで、実体化されたデータセットを設定できます。入力データソースが選択されていない場合、その入力データソースからマッピングされたオブジェクトタイププロパティは実体化されたデータセットに反映されません。入力データソースの一部が制限付きビューである場合、ユーザーには2つのオプションがあります。

• ユーザーは、制限付きビューリソースの1つを制限付きビューとして実体化することができます。以下に例の設定を示します。

• ユーザーは複数の入力データソースを選択できますが、その場合はオントロジーデータをFoundry データセットとしてのみ実体化できます。この制約は、異なる制限付きビュー入力データソースが異なるポリシー設定を持つ可能性があり、制限付きビューは現在、列レベルのポリシーの設定をサポートしていないためです。以下に例の設定を示します。