仮想テーブル

仮想テーブルを使用すると、対応するデータプラットフォームのテーブルに対して、データを Foundry のデータセットに保存せずにクエリを実行できます。

仮想テーブルは、Foundry の外部にあるソースシステムのテーブルへのポインターとして機能します。仮想テーブルは、基盤となるソースシステムやストレージ形式を抽象化するため、異なるソースシステムのデータをシームレスに組み合わせたワークフローを構築できます。また、Foundry に保存されたデータセットと仮想テーブルを組み合わせることで、データを 1 か所に集約する必要のない柔軟なアーキテクチャを実現できます。Foundry のデータ変換の出力として新しい仮想テーブルを作成することもできるため、ストレージはすべて外部に置き、Foundry がオーケストレーション、セキュリティなどの機能を担うワークフローを実現できます。

仮想テーブルは、次の要素によって定義されます。

• ソースストレージシステムへの接続（たとえば、ソース URL や資格情報）。この接続は、Foundry の Data Connection アプリケーションでソースを設定することで確立されます。
• ソースシステム内のテーブルを識別するロケーター（たとえば、データベース、スキーマ、テーブル名）。

Foundry の他のリソースと同様に、仮想テーブルは Foundry のセキュリティと権限モデルによって管理され、さまざまな Foundry アプリケーションで開いたり使用したりできます。

対応するソース

以下のソースは仮想テーブルに対応しています。接続の設定方法や対応する機能の詳細については、ソースのドキュメントを参照してください。

Iceberg カタログ

Iceberg カタログは、存在する Iceberg テーブルと、各テーブルのファイルが現在保存されている場所を記録します。Apache Iceberg テーブルを元にした仮想テーブルを読み込むために必要です。Iceberg テーブルについて詳しくはこちら。仮想テーブルが対応するカタログは、使用するソースによって異なります。ソース以外の列見出しはすべて、Foundry が対応する Iceberg カタログの名前です。各カタログの設定方法やソースの Iceberg テーブルの使用方法の詳細については、ソースのドキュメントを参照してください。

対応する Foundry ワークフロー

仮想テーブルは、以下のアプリケーションおよびワークフローで入力として利用でき、Pipeline Builder と Code Repositories では出力としても利用できます。

ソースの種類によっては、これらの機能のすべてに対応していない場合があります。詳細については、ソース別のドキュメントを参照してください。Code Repositories で仮想テーブルを使用する場合のソースの設定方法について詳しくはこちら。

一般に、仮想テーブルは、以下のいずれかの方法で Foundry の一般的なワークフローのほとんどに利用できます。

• 上記のように仮想テーブルを直接操作する、または
• 仮想テーブルを入力とし、Foundry データセットやオブジェクトを出力する変換パイプラインを作成する。これらの出力は、プラットフォームで通常どおり使用できます。

ソースおよびテーブルの種類別の仮想テーブル対応表

以下の対応表は、仮想テーブルで利用可能な主な機能を、データソースとテーブルの種類別にまとめたものです。ソース固有の制限や詳細機能を含むすべての詳細については、ソース別のドキュメントを参照してください。

^* コンピュートプッシュダウンとは、ソースシステムのネイティブコンピュートエンジンを使用することを指します。

仮想テーブルの接続を設定する

仮想テーブルに対応するソースは、Data Connection アプリケーションで設定します。使用するソースを選択し、ソース設定の仮想テーブルタブに移動します。ソースのドキュメントと、そこに記載されている仮想テーブルを使用するための要件に従ってください。

仮想テーブルを作成する

対応するすべてのソースで、ソースシステムの個々のテーブルを Foundry に登録できます。表形式のソースでは、複数の仮想テーブルをまとめて一括登録することもできます。一部のソースは、さらに 自動登録 に対応しています。この機能は、設定された資格情報でアクセスできるソース内のすべてのテーブルを、指定したプロジェクトに定期的に登録します。

仮想テーブルを登録するには、ソースの仮想テーブルタブで仮想テーブルを作成を選択します。利用可能なテーブルを参照し、登録するテーブルを選択します。別の場所を選択しない限り、仮想テーブルはソースのデフォルト出力フォルダーに作成されます。

一括登録

Databricks、BigQuery、Snowflake などの表形式のソースを使用する場合、複数の仮想テーブルをまとめて一括登録できます。まず、左側のパネルから外部テーブルを 1 つ以上選択します。右側のパネルで、新しい仮想テーブルの保存先を変更したり、名前を更新したりできます。Foundry で仮想テーブルの名前を変更しても、ソース内のテーブル名は変更されません。

自動登録

自動登録を有効にすると、仮想テーブルが自動的に作成される新しい Foundry プロジェクトを作成します。このプロジェクト内のフォルダー階層はソースシステムの構造を反映し、ソースに新しいテーブルが作成されると定期的に更新されます。ソースのテーブルが削除されても、関連する仮想テーブルはプロジェクト内で自動削除されませんが、それらにアクセスしてもデータは読み込まれません。

自動登録を有効にするには、Foundry のプロジェクト作成権限が必要です。

このプロジェクトは Foundry によって管理され、ユーザーはその中のリソースを手動で作成または更新できません。このプロジェクトに登録された仮想テーブルは、他のプロジェクトにインポートしてワークフローの開発に使用できます。

自動登録を有効にすると、プロジェクトの権限とアクセスを設定できます。これらは後から、プロジェクトの所有者がアクセスサイドバーで管理できます。

Databricks ソースのタグによる絞り込み

Databricks ソースの自動登録を設定する場合、絞り込みに使用するテーブルタグのリストを指定できます。Databricks の TABLE_TAGS ↗ システムテーブルで、これらのタグが 1 つ以上設定されているテーブルのみが登録されます。

Code Repositories の仮想テーブル

Code Repositories で仮想テーブルを使用する場合、それらを使用するトランスフォームは、ソースに設定されたエグレスポリシーに基づいてネットワークエグレスを自動的に取得します。ソースに設定された資格情報は、ソースへの接続に使用できるように必ずなります。これは、外部トランスフォームと同様の動作です。

ソースで以下の設定を有効にする必要があります。

1. **コードインポート：**これにより、ソースをコードリポジトリにインポートして使用できます。この設定の詳細と有効にする方法については、こちらを参照してください。
2. **エクスポート制御：**これは、仮想テーブルを使用する Python トランスフォームの入力で許可されるセキュリティマーキングと組織を制御します。この設定の詳細と有効にする方法については、こちらを参照してください。

ソースを設定してコードリポジトリにインポートすると、transforms.api.Input を使用して、データセットと同じように仮想テーブルを Python トランスフォームの入力として使用できます。インクリメンタル計算にはデータセットと一貫した API が用意されており、一部のソースで利用できます。詳細については、ソース別のドキュメントを参照してください。

一般に、仮想テーブルは Python、SQL、Java トランスフォームの入力として利用できます。新しい仮想テーブルをトランスフォームの出力として作成できるのは Python トランスフォームのみで、SQL と Java トランスフォームは既存の仮想テーブルへの書き込みに対応しています。

Python トランスフォームによる新しい仮想テーブルの作成について詳しくはこちら。

仮想テーブルの詳細を表示する

データセットプレビューの詳細パネルで、仮想テーブルに関する主な情報を確認できます。

これには以下が含まれます。

• **インクリメンタル：**対応している場合、このテーブルを使用したインクリメンタルパイプラインを設定できます。これにより、下流のビルドはすべての行を再処理するのではなく、新しいデータまたは変更されたデータのみを処理します。
• **バージョン管理：**対応している場合、テーブルはバージョン管理機能を提供します。これにより、Foundry は更新を検出し、データが変更されていない場合に不要な下流のビルドをスキップできます。

仮想テーブル入力の更新検出

更新検出機能は、仮想テーブルを監視し、ソースシステム内のテーブルの変更を検出します。これにより、仮想テーブルをパイプラインやオブジェクトなどの依存リソースのビルドトリガーとして使用できます。

更新検出は、外部で管理され、Foundry に登録されているテーブルである仮想テーブル入力を対象としています。仮想テーブル出力（Foundry パイプラインによって作成されるもの）については、Foundry がパイプラインのビルド情報を使用して更新を自動的に追跡するため、更新検出は不要です。

更新検出が有効な場合、Foundry は定期的にソースシステムをポーリングし、テーブルの更新を確認します。ソースのテーブル形式がバージョン管理に対応している場合（たとえば、Delta や Iceberg）、Foundry は変更を検出し、必要な場合にのみ下流のビルドをトリガーできます。バージョン管理に対応していない場合、すべてのポーリングが更新の可能性があるものとして扱われるため、不要な下流のビルドが発生する場合があります。

仮想テーブルがバージョン管理に対応しているかどうかは、仮想テーブルの詳細を表示することで確認できます。

更新検出は、下流のビルドがトリガーされるタイミングのみを制御します。実行されるビルドがスナップショットかインクリメンタルビルドかは決定しません。バージョン管理に対応するソースは、インクリメンタル（追加のみ）ビルドにも対応できる場合があります。この場合、Foundry は前回のビルド以降に追加された特定の行を識別し、テーブル全体を再処理するのではなく、その新しいデータのみを処理します。仮想テーブルのインクリメンタル処理は現在、追加のみの変更に限られ、Delta の Change Data Feed ↗ や Iceberg の Incremental Reads ↗ の有効化など、ソース固有の追加の前提条件があります。詳細については、ソース別のドキュメントを参照してください。ソースがバージョン管理に対応していない場合、その仮想テーブルを使用する下流のパイプラインは、トリガーされるたびにテーブル全体を再処理するスナップショットビルドを使用する必要があります。

更新検出を有効にする

更新検出は、仮想テーブル入力が、下流のテーブル、データセット、オブジェクトなどの下流リソースの作成に使用されている場合にのみ利用できます。

仮想テーブル入力の更新検出を有効にするには、以下の手順に従ってください。

1. データセットプレビューで仮想テーブルを開きます。
2. 左側のパネルの更新検出セクションに移動します。
3. 更新検出を有効にし、希望するポーリングスケジュール（たとえば、毎時や毎日）を設定します。

有効にすると、仮想テーブル入力を下流のテーブルやデータセットのスケジュールトリガーとして使用できます。仮想テーブルを元にしたオブジェクトは、ソースの更新が検出されると自動的にインデックスが再作成されます。

仮想テーブルを元にしたオブジェクトを設定する

Ontology Manager で、仮想テーブルを直接元にしたオブジェクトを設定できます。

元となる仮想テーブルが Foundry の外部で更新される場合、オブジェクトがソースシステムから定期的に更新を受け取れるように、仮想テーブルの更新検出を有効にしてください。

仮想テーブルの使用とデータセットへの同期の比較

仮想テーブルを使用するか Foundry データセットに同期するかは、アーキテクチャの目標と、対応する対象ワークフローによって異なります。ワークフローごとに適切な統合パターンを検討することを推奨します。この 2 つのアプローチは、互いを補完するように併用できます。

以下に、仮想テーブルの使用とデータセットへのデータ同期について、考えられる利点、欠点、制限事項を検討する際に留意すべき点を示します。

仮想テーブルを使用する利点

仮想テーブルには、以下のようなさまざまな利点があります。

• ソースデータを Foundry に保存しないことで、重複したストレージを削減できます。ただし、Foundry パイプラインの出力であるデータセットやオブジェクトなど、下流で作成されるリソースのデータは Foundry に保存されます。
• クエリをソースシステムにプッシュダウンすることで、データ転送の総量を抑えられます。コンピュートプッシュダウンの利用可否は、ソースシステムとクエリの種類によって異なります。
• 仮想テーブルは、ストレージの重複によるコストが大きくなる非常に大規模なテーブルで、特に有益な場合があります。
• 仮想テーブルでは、使用時にデータに対して直接クエリが実行されるため、データを同期したり、データの鮮度が低下する可能性を考慮したりする必要がありません。
• 仮想テーブルは任意性を提供し、Foundry の実装を対象のアーキテクチャパターンに合わせるのに役立ちます。

仮想テーブルを使用する欠点

仮想テーブルがすべての状況で最適な選択肢となるわけではありません。以下のような点を考慮する必要があります。

• Foundry データセットに保存されたデータを扱う場合と比較して、対話的な操作のパフォーマンスが低下する場合があります。
• 仮想テーブルで実行されるクエリの種類によっては、コンピュートの使用量が増加する場合があります。たとえば、スケジュールされたパイプラインの入力として使用されるテーブルでは、Contour の分析で頻繁に対話的にアクセスされるテーブルと比較して、コンピュートの使用量が少なくなる場合があります。
• 仮想テーブルでは、データセットのバージョン管理やブランチなどの Foundry データセットの機能を利用できません。

仮想テーブルを使用する際の制限事項

仮想テーブルには、以下の制限事項があります。

• 仮想テーブルは、すべてのソースで利用できるわけではありません。
• 仮想テーブルには、Foundry ワーカーソースと直接接続のエグレスポリシーが必要です。
• セルフサービスのプライベートリンクエグレスポリシーを使用する接続は、一般に利用できません。ただし、Palantir の担当者が設定したプライベートリンクは利用できます。
• Agent プロキシポリシーを使用する接続は利用できません。
• バケットエンドポイントエグレスポリシーを使用する接続は利用できません。
• Agent ワーカーを使用する接続は利用できません。
• すべての Foundry アプリケーションや機能が、仮想テーブルを入力として使用することに対応しているわけではありません。ただし、パイプラインから出力されるデータセットやオブジェクトなど、仮想テーブルの下流で作成された実体化リソースは、通常どおり Foundry エコシステム全体で完全に利用できます。
• use_external_systems デコレーターを使用するトランスフォームは、現在、仮想テーブルに対応していません。ソースベースの external_transforms に切り替えるか、トランスフォームを、仮想テーブルを入力として使用するものと use_external_systems デコレーターを使用するものに分割してください。

仮想テーブルのクエリに使用するコンピュート

仮想テーブルに対して直接実行されるクエリでは、コンピュートが Foundry とソースシステムの間で分担される場合があります。具体的な動作は、クエリと、ソースシステムが対応するプッシュダウン計算の範囲によって異なります。詳細については、ソース別のドキュメントを参照してください。