ボーダーレスな Lakehouse は、Lakehouse ランタイム カタログを介してメタデータを管理します。Apache Iceberg REST カタログのエンドポイントを使用すると、システムはデータを厳密なリソース階層に整理します。カタログ構成によって、サポートされているストレージ タイプとリージョン ルーティングの動作が決まります。
機能とコンプライアンス
Lakehouse ランタイム カタログは、標準のテーブル形式をサポートし、オープン API に準拠することで、Iceberg 準拠のクエリエンジンと統合するように構築されています。
サポートされている表の形式
Apache Iceberg V2 テーブル（一般提供版）と V3 テーブル（プレビュー版）がサポートされています。Iceberg V1 テーブルはサポートされていません。Apache Iceberg REST カタログ エンドポイントで既存の V1 テーブルを使用する前に、サポートされているバージョンにアップグレードする必要があります。詳細については、Iceberg V1 テーブルを V2 にアップグレードするをご覧ください。
API のコンプライアンスと REST オペレーション
Lakehouse ランタイム カタログは、オープン スタンダードの Apache Iceberg REST カタログ API を実装しています。クライアント クエリエンジンは、標準の REST カタログ API を使用してカタログとやり取りします。詳細については、Lakehouse で Apache Iceberg REST カタログ API を実装する方法をご覧ください。
リソース階層
Apache Iceberg REST カタログ エンドポイントは、リソースの階層を使用してデータを整理します。次の表に、これらのリソースの概要を示します。
| リソース | 説明 |
|---|---|
| カタログ | 最上位のコンテナであるカタログを使用すると、名前空間とテーブルを論理グループに整理できます。これは、名前空間とテーブルを異なるカタログに分割することで実現します。各カタログは、基盤となるメタデータとデータファイルを保存する指定されたウェアハウス ストレージ ロケーション（1 つ以上の Cloud Storage バケットなど）によってバックアップされます。 |
| 名前空間 | カタログ内のテーブルを整理するために使用される論理グループ。データベース、スキーマ、ディレクトリのように機能します。 |
| テーブル | テーブルには、クエリ可能な行と列の定義が含まれています。 |
カタログと保存場所
カタログの構成によって、カタログの動作と Google Cloud サービスとの統合方法が決まります。マルチバケット カタログ（推奨）またはシングルバケット カタログを構成できます。
どちらのオプションも認証情報のベンディングをサポートしています。
Apache Iceberg REST カタログ エンドポイントに接続するようにクライアント クエリエンジン（Spark や Trino など）を構成する場合は、カタログのタイプに基づいてウェアハウス パスを指定します。
- 複数バケット カタログ: ウェアハウス パスを
bl://projects/PROJECT_ID/catalogs/CATALOG_IDに設定します。 - 単一バケット カタログ: ウェアハウス パスを
gs://CLOUD_STORAGE_BUCKET_NAMEに設定します。
複数バケット カタログ（推奨）
この方法では、バケット名とは無関係にカタログに名前を付け、1 つのカタログに複数のバケットを構成できます。基盤となる API では、これは CATALOG_TYPE_BIGLAKE 構成に対応します。
考慮事項:
- クライアント ウェアハウス構成（
bl://）: 複数のバケット カタログに接続するように Iceberg クライアントを構成する場合は、bl://URI 形式（bl://projects/PROJECT_ID/catalogs/CATALOG_ID）を使用してウェアハウス パスを指定します。bl://形式は、クライアント構成時にカタログを識別するためにのみ使用されます。Google Cloud でカタログ自体を作成または構成する場合、ストレージの場所（default_locationとrestricted_locations）は常に Cloud Storage パス（gs://）として指定されます。 - 最大バケット数: カタログごとに最大 15 個のバケットを指定できます。
- デフォルトの場所: デフォルトのストレージ ロケーションとして機能するバケット（
default_location）またはサブパス（gs://my-bucket/pathなど）へのパスを指定します。すべてのカタログ リソース（名前空間とテーブル）は、指定されたパスの下に配置する必要があります。たとえば、gs://my-bucket/pathを指定した場合、gs://my-bucket/another/pathの下に名前空間やテーブルをホストすることはできません。ロケーションを指定せずに作成された Namespace には、default_locationが使用されます。 - 制限付きのロケーション: 名前空間とテーブルを作成できる追加のバケットまたはパスの
restricted_locations構成（省略可）を指定することもできます。サブパス（gs://my-bucket/pathなど）を指定すると、その構成を使用して作成されたリソースは、そのパスの下に配置する必要があります（たとえば、gs://my-bucket/another/pathは Namespace やテーブルをホストできません）。 - 地理的リージョン グループの要件: バケットはプロジェクト間、リージョン間、構成（単一リージョン、デュアルリージョン、マルチリージョンなど）が異なっていても構いませんが、デフォルトの場所と制限付きロケーションのすべての Cloud Storage ロケーションは、同じ地理的リージョン グループ（米国、ヨーロッパ、カナダ、アジアなど）に存在する必要があります。たとえば、ヨーロッパまたはカナダのバケットを使用して米国のマルチリージョン バケットを構成することはできません。
- バケットあたりの複数のカタログ: 複数のカタログで同じバケットを参照できます（たとえば、異なるデフォルトの場所や制限付きの場所を使用する場合など）。ただし、この構成はメタデータの競合、データの誤った上書き、権限漏洩などのセキュリティ上の問題につながる可能性があるため、強く推奨されません。
- 名前空間: デフォルトまたは制限付きの場所に構成されたパスの下にある限り、カスタム名前空間の場所を指定できます。これらのカタログで作成されたテーブルには、競合を回避するために、物理パスにランダムな文字列の接尾辞が自動的に付加されます（例:
gs://{bucket_name}/{namespace_name}/{table_name}/{random_suffix}）。詳細については、テーブルの管理とセキュリティ ルールをご覧ください。
単一バケット カタログ
これは、カタログが指定した単一の Cloud Storage バケット（gs://）内の Apache Iceberg メタデータとデータファイルを直接管理する従来の方式です。基盤となる API では、これは CATALOG_TYPE_GCS_BUCKET 構成に対応します。
単一バケット カタログの場合、カタログ名はバケットの名前に設定されます。
たとえば、バケットに iceberg-bucket という名前を付けると、カタログとバケットの両方がその名前を共有します。この名前は、BigQuery で P.C.N.T 構文（my-project.lakehouse-catalog-id.quickstart_namespace.quickstart_table など）を使用してカタログをクエリするときに使用します。
考慮事項:
以前のカタログ タイプの制限事項。新しいプロジェクトでは、以前の単一バケット構成を使用することは強く推奨されません。この構成には、次のような重大な制限事項があります。
- カタログ名: 基盤となる Cloud Storage バケット名にロックされます。
- プロジェクト: バケットのプロジェクトにロックされます（プロジェクト間のカタログは対象外です）。
- リージョン: バケットのロケーションから厳密に導出され、カスタマイズできません。
- ストレージ: カタログを単一のバケットに制限します（制限されたロケーションはありません）。
クライアント ウェアハウスの構成（
gs://）: 単一バケット カタログ用に Iceberg クライアントを構成する場合は、Cloud Storage バケットパス（gs://CLOUD_STORAGE_BUCKET_NAME）をウェアハウスのロケーションとして指定します。バケットあたりのカタログ 1 つの制限: この以前のカタログタイプでは、バケットごとに 1 つのカタログのみを使用でき、カタログ名はバケット名と一致している必要があります。
複数バケット カタログにアップグレードする（推奨）: 既存の単一バケット カタログを複数バケット カタログにアップグレードできます（推奨）。アップグレードされたカタログは、元のバケットの名前を保持します。その後、複数のバケットをカタログに関連付けて、制限付きロケーションを構成できます。
バケットとカタログのリージョン
Lakehouse ランタイム カタログ内のカタログ エンドポイントのリージョンは、基盤となる Cloud Storage バケットのリージョンによって決まります。
- 複数バケット カタログ（推奨）: カタログ リージョンは、
default_locationで構成されたバケットから派生します。 - 単一バケット カタログ: カタログのリージョンは、カタログに関連付けられたバケットから厳密に派生し、カスタマイズできません。
マッピングされたカタログ リージョンは、バケットのリージョン タイプによって異なります。
- 単一リージョン: カタログのリージョンがバケットのリージョンと完全に一致します。
- デュアルリージョン: カタログ リージョンがバケットのデュアルリージョン（
ASIA1やNAM4など）と一致します。 - マルチリージョン: カタログ リージョンは、マルチリージョンの地理的ドメイン内の特定のリージョン ロケーションに設定されます。デフォルトでは、これは
USやEUなどの一般的な BigQuery マルチリージョンと一致しない場合があります（たとえば、USマルチリージョン バケットはus-central1またはus-east4にマッピングされます）。
BigQuery がこれらのカタログ内のテーブルに対してクエリを実行すると、クエリはカタログのプライマリ リージョンに転送されます。特定の仮想リージョン（US や EU など）のテーブルをクエリし、そのロケーションにカタログ メタデータが存在しない場合、クエリは失敗します。
マルチリージョンのプライマリ リージョン
BigQuery が US または EU マルチリージョンからカタログ テーブルをクエリできるようにするには、カタログの作成時に US または EU をプライマリ リージョンとして指定します。
次の構成では、マルチリージョン（US または EU）をプライマリ リージョンとして指定できます。
default_location バケットが次の状態の場合:
USまたはEUマルチリージョン バケット。- これらのマルチリージョン内のシングルリージョン バケット（
us-central1やeurope-west4など）。 - これらのエリア内のデュアルリージョン バケットまたはカスタム デュアルリージョン バケット（
NAM4やEUR4など）。
プライマリ レプリカはカタログの作成時に定義されますが、FailoverCatalog を呼び出すことで動的にフェイルオーバーを実行できます。詳細については、カタログを作成するをご覧ください。
BigQuery からカタログをクエリする
BigQuery から Lakehouse ランタイム カタログ テーブルにクエリを実行する場合は、4 つの部分からなる命名構造を使用します。これは P.C.N.T と呼ばれることがよくあります。
- Project: カタログを所有する Google Cloud プロジェクト ID。
- Catalog: Lakehouse ランタイム カタログの名前。
- Namespace: Apache Iceberg 名前空間（BigQuery データセットに相当）。
- Table: テーブルの名前。
例: my-project.lakehouse-catalog-id.my-namespace.my-table