ドキュメントの検索
karat

+

K

APIリファレンス ↗

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

オントロジークエリによるコンピュート利用

Foundry のオントロジーは、ファイルベースのデータをビジネス中心のオブジェクトにマッピングし、データ探索、データ分析、運用データ編集、シナリオ分析などの高速クエリを提供するデータバックエンドです。オントロジーは各自の目的を持つマルチモーダルストレージバックエンドにデータを格納し、単一のリクエストで柔軟にクエリを行うことができます。Foundry オントロジーのクエリには、以下で説明するいくつかの基本的な概念の理解が必要です。

Palantir と企業契約を結んでいる場合は、コンピュート利用の計算を進める前に Palantir の担当者に連絡してください。

コアコンセプト: オブジェクトタイプとオブジェクトセット

最初の重要な概念は、オブジェクトタイプとそれに対応するオブジェクトセットの違いです。オブジェクトタイプはエンティティそのもの(オブジェクトの名前やプロパティなど)のセマンティック表現です。

オブジェクトタイプには対応するオブジェクトセットがあり、それにはオブジェクト自体が含まれます。オブジェクトセットのサイズは、入力データセットの行数と、オントロジーのアクションによって作成および削除されたオブジェクトの数に対応します。

コアコンセプト: クエリタイプ

2つ目の重要な概念は、クエリタイプのアイディアで、フィルター、集約、Search Arounds、書き戻し操作などが含まれます。それぞれのクエリタイプは、実行にコンピュートを必要とします。

  • フィルターは全オブジェクトセットを考慮し、フィルタリング基準を適用してより小さな出力セットを生成します。
  • 集約は入力オブジェクトセットを取り、セット内の全オブジェクトのいずれかのプロパティに対して集約関数(例えば sumavg)を実行します。
  • Search Aroundsは入力オブジェクトセットを取り、入力セットの特定のプロパティに基づいて他のオブジェクトセットに対して二次フィルターを実行します。
  • 書き戻し操作は指定されたオブジェクトセットのオブジェクトのプロパティの値を置き換えます。

API ドキュメンテーションを参照して、クエリタイプについてさらに詳しく学びましょう。

Foundry オントロジーを使用すると、クエリタイプは以下の Foundry アプリケーション によって オブジェクトセットに対して実行されます。

  • Object Explorer
  • Workshop
  • Quiver
  • Slate
  • Vertex
  • Foundry Rules
  • Foundry Machinery
  • Object APIs (OPIs)

これらのソースからオントロジーをクエリすると、クエリを実行するためのコンピュート秒が使用されます。

  • クエリのオーバーヘッドに対して固定の最小コンピュート秒数。
  • クエリをサービスするために使用されるコンピュートの量によって測定される追加のスケーリングコンピュート秒数。

オントロジーのオブジェクトクエリによる Foundry コンピュートの測定

Object Storage V1 によるコンピュートの測定

Object Storage V1(Phonograph)は、データを耐久性のある水平スケーラブルなクラスターの分散セットのインデックスに格納します。これらのインデックスでは、データはオントロジークエリエンジンがトラバースする大きなデータ構造に配置されます。クエリが実行されると、エンジンはインデックスをトラバースすることで、検索中に大量のデータの処理を回避することができます。このプロセスは "pruning"(剪定)と呼ばれます。

このエンジンを使用すると、最大1000倍少ないレコードを評価することで、何十億ものレコードを検索することができます。レコードの物理的な評価は "hit"(ヒット)と呼ばれます。Object Storage V1は、各クエリでのヒット数を最小限にするように設計されています。

Object Storage V2 によるコンピュートの測定

Object Storage V2(OSv2)は、オブジェクトを高速インデキシング、Search Arounds、書き戻し、複雑なタスクを達成するための複数のコンピュートバックエンドへのスムーズなハンドオフを可能にするPalantirにより最適化されたインデキシングフォーマットで格納します。これには、クエリの一部として完全に並列化されたSparkコンピュートが含まれます。

Object Storage V2も効率的なインデキシング構造を使用しているため、Object Storage V1からの基本クエリのヒットという同じ原則が適用されます。ただし、クエリの一部として起動されたオンデマンドのSparkコンテナによってもコンピュート秒が使用されることもあります。

Object Storage V2 バックエンドのオブジェクトに対して行われたクエリは、以下のパターンでコンピュートを使用します。

  • Object Storage V1 バックエンドのオブジェクトに対するクエリの固定コンピュート秒オーバーヘッドは 16 コンピュート秒です。
  • Object Storage V2 バックエンドのオブジェクトに対するクエリの固定コンピュート秒オーバーヘッドは 10 コンピュート秒です。Object Storage V2 の最適化された構造は、Object Storage V1よりもオーバーヘッドが少ないため、固定コンピュート秒オーバーヘッドが少なくなります。
  • クエリの剪定プロセスを通じて計算作業を行うときには追加のコンピュート秒が必要です。追加のコンピュート秒は、インデックスにあるオブジェクトの数およびクエリのタイプに応じてスケールします。
  • Object Storage V2(OSv2)では、インデックス剪定も同様に追加のコンピュート秒を必要とします。ただし、OSv2は、10万オブジェクト以上に対して検索周辺を実行したり、1つのリクエストで10,000オブジェクト以上に対して書き戻し操作を実行したりするときに、オンデマンドのSparkクラスター検索をサポートしています。これらのSparkクラスターは、プラットフォーム上の他のすべてのSparkベースのアプリケーションと同様に使用量を利用します。詳細は、並列化されたコンピュートのドキュメンテーション をご覧ください。

オントロジークエリによる Foundry コンピュート利用の理解

  • 非常にシンプルなルールとして、クエリあたりの固定コンピュート利用はクエリの数に比例して線形に増えます。クエリの数を減らすと、総計でコンピュートの使用量は減ります。
  • オブジェクトセットサービスへのより複雑なクエリ、たとえば一般的なマルチオブジェクト検索などは、各オブジェクトタイプに対して複数のサブクエリを開始します。使用しているクエリの数を減らすために、検索を個々のオブジェクトタイプに限定します。
  • 小さなオブジェクトセットに対するクエリは、大きなオブジェクトセットに対するクエリよりもコンピュートを少なく使用します。クエリのヒット数は、クエリされるオブジェクトセットのサイズに比例します。
  • 他の操作を行う前にアップフロントでフィルタリングを行うと、高度にインデックス化されたバックエンド構造を活用できます。これにより、クエリのヒット数が減り、全体のコンピュート使用量が減ります。これは、フィルタリングされたオブジェクトセットがフルオブジェクトセットよりも少ないコンピュートを必要とする集約と Search Arounds で特に重要です。

オントロジークエリからの Foundry コンピュート利用の調査

Foundry では、コンピュート秒はプラットフォームのリソースに帰属し、それらのリソースと対話するユーザーではなく。

オントロジークエリに関しては、コンピュートが帰属する方法は複数あります。一般的なルールとして、コンピュートはクエリが発生したリソースに帰属します。ただし、コンピュートを生成するために使用される保存されたリソースがない場合(API経由など)、コンピュートはクエリされているオブジェクトタイプに帰属します。1つのリクエストで複数のオブジェクトがクエリされる場合、コンピュートはオブジェクト間で均等に分配されます。

以下のリソースタイプは、オントロジークエリのコンピュートがこれらに帰属し、基礎となるオブジェクトではない。

  • Workshop アプリケーション
  • Quiver 分析とダッシュボード
  • Vertex アプリケーション
  • Slate アプリケーション
  • Foundry Machinery アプリケーション
  • Foundry Rules リソース

以下のインタラクションパターンは、オントロジークエリのコンピュートが直接クエリされているオブジェクトタイプに帰属する。これは、コンピュートを帰属させるための設定されたリソースがないためです。

  • Object Explorer
  • Object APIs(OSDK を含む)