実体化

多くの Foundry ワークフローでは、最新のデータが不可欠です。オントロジーのユーザーは、入力データソースのデータとユーザーによる編集を組み合わせることで、オントロジーのインデックス化済みデータから、各オブジェクトの最新の状態を含む実体化を作成できます。

実体化のユースケース

実体化の主なユースケースは、次の2つです。

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

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

Ontology Manager のデータソースタブで編集の設定を切り替え、実体化タブに移動します。実体化タブでは、入力データソースの種類に応じたさまざまな設定で、実体化されたオブジェクトデータセットまたはオブジェクトの制限付きビューを作成できます。実体化は自動的に更新され、データセットプレビューから手動でビルドすることはできません。

ライトバックデータセットと実体化データセットの比較

Phonograph とも呼ばれる Object Storage v1（OSv1）では、ライトバックデータセットが実体化データセットに相当します。OSv1 では、オブジェクトタイプ、または結合テーブルを持つ多対多のリンクタイプでユーザー編集を有効にするために、ライトバックデータセットが必要です。

Object Storage v2（OSv2）では、ユーザー編集を有効にするために実体化データセットは必要ありません。代わりに、Ontology Manager のデータソースタブで編集設定を切り替えることで、オブジェクトタイプのユーザー編集を有効にできます。このため、OSv2 では実体化は任意となり、前述の2つの主なユースケースで必要な場合にのみ実体化を作成すればよくなります。また、OSv2 では、オブジェクトタイプのプロパティの一部だけを実体化したい場合に、複数の実体化データセットを作成できます。

OSv1 のライトバックデータセットと OSv2 の実体化データセットのその他の動作の違いを、以下で説明します。

ライトバックデータセットと実体化データセットのビルドスケジュール

OSv1（Phonograph）のライトバックデータセットと OSv2 の実体化データセットでは、ビルドスケジュールの扱いが異なります。

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

ライトバックデータセットと実体化データセットの保持

ライトバックデータセットと実体化データセットでは、保持の仕組みが異なります。

• OSv1 では、ライトバックデータセットは、プラットフォーム内で指定できる特定の保持ポリシーを適用できるという点で、通常のデータセットと同様に動作します。このため、ライトバックデータセットが定期的にビルドされていれば、オブジェクトタイプの状態の過去のスナップショットを確認できます。

• OSv2 では、実体化データセットにカスタマイズできない保持ルールが適用されます。過去のトランザクションは継続的に削除され、最新のスナップショットのみが利用可能であることが保証されます。この場合、オブジェクトタイプの状態の過去のスナップショットを保持することが重要であれば、下流にトランスフォームを設定する必要があります。この保持ポリシーはオブジェクトタイプが削除された場合にも適用されるため、削除されたオブジェクトタイプの実体化データセットを保持するには、同様に下流のトランスフォームが必要です。

ライトバックデータセットと実体化データセットのデータセットスキーマ

OSv1（Phonograph）のライトバックデータセットと OSv2 の実体化データセットでは、入力データソースのスキーマとの関係が異なります。

• OSv1 では、入力データソースのスキーマがコピーされ、ライトバックデータセットのスキーマとして使用されます。
• OSv2 では、Foundry オントロジーのわかりやすさを向上させるため、この動作が変更されています。オントロジーからデータを実体化するため、実体化データセットに使用されるスキーマは、元データソースの設定に依存せず、オントロジーの定義からコピーされます。具体的には、各プロパティの API名メタデータが実体化データセットのスキーマとして使用されます。OSv1 から OSv2 への移行時に入力データソースのスキーマを引き続き使用したい場合（たとえば、既存のライトバックデータセットの下位互換性を保証するため）は、Palantir の担当者にお問い合わせください。

制限付きビューの実体化オプション

OSv1（Phonograph）では、制限付きビューを入力データソースとして使用して詳細な権限が設定されているオブジェクトタイプに対して、制限付きビューを実体化することはできません。実体化できるのは、入力データソースである制限付きビューの元データセットのすべての行を含むライトバックデータセットのみです。その場合、ユーザーはアクセス制限に基づいて、ライトバックデータセットへのアクセスを適切に保護する責任があります。

OSv2 では、以下に示すように、制限付きビューを入力データソースとして使用して詳細な権限が設定されているオブジェクトタイプに対して、通常のデータセットと制限付きビューのどちらも実体化リソースとして設定できます。

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

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

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

制限付きビューからデータセットを実体化する

前述のとおり、OSv1 と OSv2 はどちらも、制限付きビューを入力データソースとするオブジェクトタイプを通常のデータセットとして実体化できます。制限付きビューはトランスフォームの入力として使用できないため、ここがプラットフォーム内でユーザーが制限付きビューをデータセットに変換できる唯一の場所です。実体化されたデータセットには制限付きビューのポリシーが引き継がれないため、実体化されたデータセットの作成と可視化には、より高い権限が必要です。

説明のため、次の用語を使用します。

• オブジェクトタイプ： 対象のオブジェクトタイプ。
• 制限付きビュー： オブジェクトタイプの元となる制限付きビュー。
• 元データセット： 制限付きビューの元データセット。

以下の図は、元データセット、制限付きビュー、オブジェクトタイプの関係を示しています。

これらの定義を踏まえて、新しい実体化データセットを作成し、そのトランザクションを閲覧するためにユーザーに必要な条件を説明します。これらは別々の2つのステップです。

新しい実体化データセットを作成するには、元データセットから新しいデータセットへの恒等変換を実行する権限が必要です。セキュリティの観点では、元データセットと制限付きビューの両方の任意アクセス制御と強制アクセス制御を満たす必要があります。

これらの条件を満たす場合、以下の例に示すように、新しい実体化データセットを作成するオプションが表示されます。

これらの条件を満たさない場合、このオプションは表示されません。次の例では、ユーザーが必要な任意アクセス制御を満たしていないため、実体化データセットを作成できません。

実体化データセットのトランザクションを閲覧するには、元データセットのトランザクションを閲覧できる必要があります。つまり、元データセットのトランザクションの強制アクセス制御も満たす必要があります。

次の図はこれを示しており、元データセット、制限付きビュー、オブジェクトタイプ、実体化データセットが確認できます。制限付きビューでは切り離される元データセットのマーキングが、実体化データセットには伝播します。つまり、トランザクションを閲覧するには、このマーキングを満たす必要があります。

OSv2 のオブジェクトタイプに強制アクセス制御タイプのプロパティが含まれている場合、実体化データセットでも、ユーザーは許可されたマーキング、許可された組織、最大機密情報区分に関するすべての強制アクセス制御を満たす必要があります。前述のとおり、来歴は元データセットから引き継がれます。また、強制アクセス制御タイプのプロパティを含むオブジェクトタイプでは、オブジェクトタイプで定義された強制アクセス制御も適用されます。

以下の図は、1個のマーキングを持つ元データセットと、元データセットから引き継ぐ2個のマーキングを持つ実体化データセット、およびオブジェクトタイプで設定されたマーキングを示しています。

元データセットには、次のマーキングが含まれています。

オブジェクトタイプの設定では、以下に示すように、別のマーキングを持つ強制アクセス制御タイプのプロパティを設定できます。

この設定により、実体化データセットは、元データセットと、強制アクセス制御タイプのプロパティを含むオブジェクトタイプの両方から来歴を引き継ぎます。

制限付きビューからのデータセット実体化の制限

OSv2 の制限付きビューに次のいずれかのポリシーが含まれている場合、実体化データセットを設定できません。

1. 制限付きビューに、ユーザーの強制アクセス制御を参照し、文字列プロパティに適用される条件が含まれている場合。代わりに、オントロジー内の文字列プロパティを強制アクセス制御プロパティに変換し、最大の機密情報区分ベースのアクセス制御または必須マーキングの集合を設定できるようにする必要があります。
2. 制限付きビューに、認可されたグループIDの条件がある場合。
3. 制限付きビューのデータソースに、固定値として組織またはマーキングを直接参照する条件がある場合。代わりに、組織とマーキングのきめ細かい条件が、文字列プロパティや固定値ではなく、強制アクセス制御プロパティを参照するようにする必要があります。

ブランチ

実体化は Global Branches と組み合わせて使用できますが、次の制限があります。

• ブランチ上では実体化を作成できません。
• ブランチ上では実体化を編集できません。

実体化が関連付けられているオブジェクトタイプに加えられた変更は、ブランチでインデックス化されます。そのブランチからの更新は、実体化データセットまたは制限付きビューに書き込まれます。オブジェクトタイプを削除するか、ブランチから外すと、実体化データセット内のブランチも削除されます。制限付きビューの制約により、実体化された制限付きビューのブランチは削除されません。この制約を解消する方法は、現在開発中です。

トラブルシューティング

実体化データセットの読み取り時の Catalog:TransactionDataDeleted エラー

OSv2 の実体化データセットの読み取りが、実体化データセット以外のデータセットを参照する Catalog:TransactionDataDeleted エラーで失敗する場合、実体化がまだ読み取っている内部データが保持ポリシーによって削除された可能性があります。これは、データが長期間変更されていないオブジェクトタイプに影響する可能性がある既知の制約です。オブジェクトタイプの Funnel パイプラインが次にデータの変更を伴って実行されると、読み取りは再び成功します。

このエラーの再発を防ぐには、オブジェクトタイプの RID と完全なエラーメッセージを添えて、Palantir サポートにお問い合わせください。Palantir サポートは、オブジェクトタイプに対してインクリメンタル（差分処理）の no-op トランザクションを有効にできます。この設定を有効にすると、オブジェクトタイプのオントロジーのインデックス化に伴うコンピュート使用量が増加します。