注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
仮想テーブルを使用すると、Foundryのデータセットにデータを最初に保存することなく、サポートされているデータプラットフォームのテーブルにクエリを実行できます。
仮想テーブルは、Foundry外のソースシステムのテーブルへのポインターとして機能します。仮想テーブルは、基盤となるソースシステムやストレージフォーマットを抽象化し、異なるソースシステムからのデータをシームレスに組み合わせたワークフローを構築できるようにします。仮想テーブルは、Foundryに保存されたデータセットと組み合わせることもでき、データを1か所に統合する必要のない柔軟なアーキテクチャの一部として機能します。
仮想テーブルは以下によって定義されます:
Foundryの他のリソースと同様に、仮想テーブルはFoundryのセキュリティおよび権限モデルによって管理され、さまざまなFoundryアプリケーションで開いたり使用したりできます。
以下のソースは仮想テーブルをサポートしています。接続の設定方法およびサポートされている機能の詳細については、ソースのドキュメントを参照してください。
ソース | ステータス | サポートされているフォーマット | 手動登録 | 自動登録 |
---|---|---|---|---|
Amazon S3 | 🟢 一般的に利用可能 | Avro ↗、Delta ↗、Iceberg ↗、Parquet ↗ | ✔️ | |
Azure Data Lake Storage Gen2 (Azure Blob Storage) | 🟢 一般的に利用可能 | Avro ↗、Delta ↗、Iceberg ↗、Parquet ↗ | ✔️ | |
BigQuery | 🟢 一般的に利用可能 | Table、View、Materialized View | ✔️ | ✔️ |
Google Cloud Storage | 🟢 一般的に利用可能 | Avro ↗、Delta ↗、Iceberg ↗、Parquet ↗ | ✔️ | |
Snowflake | 🟢 一般的に利用可能 | Table、View、Materialized View | ✔️ | ✔️ |
Apache Icebergテーブルを利用した仮想テーブルをロードするには、Icebergカタログが必要です。Icebergカタログの詳細については、Apache Icebergのドキュメント ↗を参照してください。仮想テーブルは、使用されるソースに応じて異なるカタログオプションをサポートしています。以下の表は、サポートされているカタログを示しています。各カタログの設定方法の詳細については、ソースのドキュメントを参照してください。
ソース | AWS Glue | Object Storage | Unity Catalog |
---|---|---|---|
Amazon S3 | 🟢 一般的に利用可能 | 🟢 一般的に利用可能 | 🟢 一般的に利用可能 |
Azure Data Lake Storage Gen2 (Azure Blob Storage) | 🔴 利用不可 | 🟢 一般的に利用可能 | 🟢 一般的に利用可能 |
Google Cloud Storage | 🔴 利用不可 | 🟢 一般的に利用可能 | 🔴 利用不可 |
仮想テーブルは以下のアプリケーションおよびワークフローで入力としてサポートされています:
サポートされているアプリケーション | サポートされているワークフロー | サポートされていないもの |
---|---|---|
Data Connection | ソースの設定 仮想テーブルの登録 | エージェントベースの接続 |
Contour | Contourでの分析 | データセットとして保存 |
Ontology | Pipeline Builder経由のオブジェクト作成 | Ontology Manager経由のオブジェクト作成 |
Data Lineage | Foundryデータフローの表示 | |
Pipeline Builder | パイプラインへの入力 オブジェクトおよびデータセットの出力 スナップショットビルド インクリメンタルビルド(追加のみ) | ストリーミングビルド |
Code Repositories | Pythonトランスフォーム スナップショットビルド インクリメンタルビルド(追加のみ) | Javaトランスフォーム SQLトランスフォーム |
一部のソースタイプはこれらのすべての機能をサポートしていない場合があります。詳細については、ソース固有のドキュメントを参照してください。仮想テーブルをCode Repositoriesで使用する方法についてはこちらをご覧ください。
一般的には、仮想テーブルは以下のいずれかの方法で大部分のFoundryワークフローをサポートするために使用できます:
仮想テーブルをサポートするソースは、Data Connectionアプリケーションで設定されます。使用するソースを選択し、ソース設定の仮想テーブルタブに移動します。ソースのドキュメントおよび仮想テーブルの使用に関する要件を参照してください。
すべてのソースは手動登録をサポートしており、ソースシステムからFoundryに個々のテーブルを登録できます。一部のソースは自動登録もサポートしており、構成された資格情報でアクセス可能なすべてのテーブルが指定されたプロジェクトに定期的に登録されます。
手動登録を使用する場合、仮想テーブルの作成を選択し、ソースシステム内の利用可能なテーブルを参照し、登録する個々のテーブルを選択できます。異なる場所を選択しない限り、これらはソースの接続設定で構成されたFoundryの場所に登録されます。
自動登録を有効にすると、仮想テーブルが自動的に作成される新しいFoundryプロジェクトを作成します。このプロジェクトのフォルダーヒエラルキーはソースシステムの構造を反映し、新しいテーブルがソースに作成されるたびに定期的に更新されます。ソーステーブルが削除されると、関連する仮想テーブルはプロジェクト内で自動的に削除されませんが、アクセスしてもデータは読み込まれません。
自動登録を有効にするには、Foundryでプロジェクト作成権限が必要です。
プロジェクトはFoundryによって管理され、ユーザーは手動でリソースを作成または更新できません。このプロジェクトに登録された仮想テーブルは、ワークフロー開発に使用するために他のプロジェクトにインポートできます。
自動登録を有効にすると、プロジェクトへのアクセス権限とアクセスを設定でき、その後プロジェクト所有者がアクセスサイドバーを使用して管理できます。
仮想テーブルがCode Repositoriesで使用される場合、それを消費するトランスフォームは、ソースで構成されたエグレスポリシーに基づいてネットワークエグレスを自動的に取得します。ソースで構成された資格情報は、ソースへの接続に利用可能となります。これは外部トランスフォームと同様の動作です。
ソースで次の設定が有効になっている必要があります:
ソースが設定されてコードリポジトリにインポートされると、仮想テーブルはデータセットと同様にPythonトランスフォームの入力として使用できます。transforms.api.Input
を使用します。インクリメンタル計算にはデータセットと一貫したAPIがあり、一部のソースでサポートされています。詳細についてはソース固有のドキュメントを参照してください。
仮想テーブルを使用するか、Foundryデータセットに同期するかの決定は、アーキテクチャの目標およびサポートされるターゲットワークフローに依存します。ワークフローごとに適切な統合パターンを検討することをお勧めします。この2つのアプローチは、互いに補完するために併用できます。
以下に、仮想テーブルを使用する場合とデータセットへの同期に関する利点、欠点、および制限についての考慮事項を示します。
仮想テーブルは、以下のような多くの利点を提供します:
仮想テーブルがすべての状況で最適な選択であるとは限りません。以下のような考慮事項があります:
仮想テーブルの制限には以下が含まれます:
仮想テーブルに対して直接実行されるクエリの場合、コンピュートはFoundryとソースシステムの間で分割されることがあります。具体的な動作は、クエリおよびソースシステムによってサポートされるプッシュダウン計算の度合いに依存します。詳細についてはソース固有のドキュメントを参照してください。