クロスクラウド データアクセス機能を使用すると、ファイルの移行や複雑な ETL パイプラインの構築を行わずに、他のクラウド プロバイダに保存されているデータを Google Cloud から直接クエリできます。クエリは、公共のインターネット経由でルーティングすることも、プライベート ネットワーク転送に Cross-Cloud Interconnect を使用することもできます。
Lakehouse のクロスクラウド データアクセスは、BigQuery、スタンドアロンの Apache Spark 環境、または Managed Service for Apache Spark を介して、分散データセット全体の分析ワークロードと AI ワークロードを統合します。
分析クエリの実行に加えて、クロス クラウド ソースを含む分散テーブルを基盤とする会話分析エージェントを構築して、1 つの会話からクラウド全体のデータを分析できます。Knowledge Catalog を使用して、リモート プラットフォーム間でデータ プロファイリングと分析情報を取得することもできます。
クロスクラウド データアクセスを使用するタイミング
一般的なユースケースは次のとおりです。
- マルチクラウド テーブルをその場でクエリする: ファイルの移行や ETL パイプラインのメンテナンスを行うことなく、Amazon Web Services（AWS）と Microsoft Azure の外部 Apache Iceberg テーブルで BigQuery SQL と Managed Service for Apache Spark 分析を直接実行します。
- プライベート クロスクラウド ネットワークの分離を適用する: クエリデータの読み取りとバックグラウンド メタデータの更新の両方を Cross-Cloud Interconnect 経由でルーティングし、パブリック インターネット トラフィックを制限するセキュリティ ポリシーとコンプライアンス ポリシーを満たすことができます。
- 繰り返されるクロス クラウド データ転送のコストを削減する: 予測可能なプライベート相互接続の下り（外向き）レートと、Google Cloud での自動ローカル ブロック キャッシュを組み合わせて、繰り返される BI ダッシュボードと分析ワークロードに対応します。
- クロスクラウド ガバナンスと AI エージェントを統合する: 会話分析エージェントを分散テーブルにグラウンディングし、Knowledge Catalog の検出、プロファイリング、リネージをクラウド間で適用します。
アーキテクチャ
次の図は、Lakehouse のクロスクラウド データアクセス アーキテクチャを示しています。
上の図は、 Google Cloud と外部クラウドおよび SaaS 環境にまたがるアーキテクチャを示しています。
- Google Cloud: リモート データセット全体で AI、ガバナンス、分析、クロスクラウド データアクセスを提供します。
- AI エージェントとエクスペリエンス: 会話分析と Gemini Enterprise で自律型エージェントを構築します。このエージェントは、Knowledge Catalog でデータとセマンティックな意味を検索し、分析エンジンと処理エンジンを介してクエリを実行します。
- Knowledge Catalog: Lakehouse からメタデータとリネージを同期することで、統合ガバナンスとデータリネージ、データ分析情報、プロファイリング、データ プロダクトを提供します。
- 分析エンジンと処理エンジン: BigQuery SQL、BigQuery AI、Looker ワークロードを実行します。または、Lakehouse を介してメタデータを解決してテーブルを読み取ることで、Managed Service for Apache Spark とオープンエンジン（Apache Spark、Apache Flink、Trino）を使用してリモートデータを処理します。
- レイクハウスのクロスクラウド データアクセス: ファイルの移行や ETL パイプラインを使用せずに、リモートデータをその場でクエリします。
- メタデータの同期: Lakehouse ランタイム カタログを使用して、Apache Iceberg REST と Delta Sharing を介してテーブル メタデータを検出して同期します。OpenID Connect（OIDC）または Secret Manager を介して認証し、スコープ付きの一時的な認証情報を発行します。
- クロスクラウド機能（AWS）: ブロックレベルのリードスルー キャッシュ（インテリジェント キャッシュ（ローカル キャッシュ））を使用して、読み取られたデータブロックを Google Cloud にキャッシュし、クロスクラウド ネットワーク トランスポートを使用して、Dedicated Cross-Cloud Interconnect（CCI）、Partner Interconnect、またはインターネット（TLS を使用）経由でトラフィックをルーティングします。
- 外部クラウドと SaaS データソース: リモート カタログ、SaaS データクラウド、オブジェクト ストレージをホストします。
- 外部クラウドと SaaS カタログ: クラウド データ カタログ（AWS の AWS Glue Data Catalog、AWS または Google Cloudの Databricks Unity Catalog と Snowflake Horizon Catalog）と SaaS データクラウド（Salesforce Data Cloud、AWS またはGoogle Cloudの Workday データレイク、SAP ビジネスデータ クラウド（BDC））のメタデータを、Iceberg REST API と Delta Sharing（SAP BDC の場合）を介して同期します。
- 外部クラウド オブジェクト ストレージ（AWS）: Apache Iceberg テーブル（Parquet データファイル）と Amazon S3 テーブルを Amazon S3 に保存し、CCI またはインターネット（TLS を使用）経由で直接ブロック読み取りを行います。
クロスクラウド データへのアクセスの仕組み
Lakehouse は、次のプロセスを使用してリモートデータをクエリします。
- メタデータの検出: Lakehouse ランタイム カタログは、Databricks Unity Catalog、AWS Glue Data Catalog、Snowflake Horizon Catalog などのリモート Apache Iceberg REST カタログ エンドポイントに接続し、ファイルをコピーせずにテーブル メタデータを検出します。リモート カタログ プロバイダに応じて、Lakehouse は Secret Manager または OIDC トークン連携を介して Google を ID プロバイダとして認証します。
- 安全な転送: プライベート相互接続（Dedicated CCI や Partner Interconnect など）を介してトラフィックをルーティングすると、公共のインターネットと比較してデータ転送コストが大幅に削減され、レイテンシを高い精度で予測できます。
- 最適化された実行: 連携カタログまたは接続でクロスクラウド キャッシュを有効にすると、Lakehouse は取得したファイル ブロックを Google Cloud クエリ実行リージョン内にローカルにキャッシュします。同じファイルブロックをターゲットとする後続のクエリは、リモート クラウドからファイルを再取得するのではなく、ローカル キャッシュから直接読み取ります。これにより、クロスクラウドの下り（外向き）料金が削減され、クエリのパフォーマンスが向上します。
サポートされているカタログ
レイクハウスでは、次のリモート カタログ プロバイダからのデータのクエリがサポートされています。
- Databricks Unity Catalog: アマゾン ウェブ サービス（AWS）、Microsoft Azure、または Google Cloudでホストされます。
- AWS Glue: AWS でホストされます。
- Snowflake Horizon カタログ: AWS、Azure、または Google Cloudでホストされます。
- Workday Data Lake: AWS または Google Cloudでホストされます。
- SAP Business Data Cloud（BDC）: AWS、Microsoft Azure、または Google Cloud でホストされ、SAP BDC コネクタを使用します。
基本コンセプト
クロスクラウド データアクセスでは、バックグラウンド メタデータの更新とクエリデータの転送が分離されるため、セキュリティと費用の要件に基づいて、いずれかまたは両方のトラフィック レイヤをプライベートにルーティングできます。
メタデータ レイヤ
レイクハウス ランタイム カタログのメタデータ レイヤは、リモートの Apache Iceberg REST カタログ エンドポイントに接続し、更新間隔に基づいて Apache Iceberg の名前空間とテーブルのメタデータを同期します。Lakehouse は、Secret Manager または OIDC トークン連携に保存されている認証情報を使用して認証します。
デフォルトでは、バックグラウンドのメタデータ更新リクエストと認証リクエストは、TLS を使用してパブリック インターネット経由で送信されます。リモート カタログがパブリック ネットワーク アクセスを制限している場合や、セキュリティ ポリシーでプライベート コントロール プレーン トラフィックが必要な場合は、AWS Glue Data Catalog（AWS）、Databricks Unity Catalog（AWS と Azure）、Snowflake Horizon Catalog（AWS と Azure）にメタデータ Service Directory サービス（--metadata-service-directory-name）を構成できます。この構成では、メタデータと認証トラフィックが、プライベート クエリ トランスポート（--service-directory-name）とは別に、またはそれとともに、Dedicated Cross-Cloud Interconnect または Partner Cross-Cloud Interconnect（AWS の場合）を介してプライベートにルーティングされます。
トランスポート層
トランスポート層を使用すると、BigQuery とオープンソース エンジンは、メタデータ層から同期されたメタデータを使用してリモート テーブル ファイルをクエリできます。サポートされているリモート カタログの場合、Lakehouse はパブリック インターネットまたは専用のプライベート相互接続を介したデータのクエリをサポートします。
アーキテクチャとセキュリティの要件に合った転送方法を選択します。
お客様所有（CCI）
Dedicated Cross-Cloud Interconnect または Partner Cross-Cloud Interconnect を使用して、プライベート Cross-Cloud Interconnect 経由で Amazon S3 バケットまたは Azure Data Lake Storage Gen2（ADLS Gen2）コンテナに保存されているデータをクエリするように BigQuery を構成できます。
プライベート相互接続を使用すると、次のメリットがあります。
- セキュリティの強化: データは、 Google Cloud と AWS または Azure 間のプライベート ネットワーク接続を介して転送され、パブリック インターネットを回避します。
- 費用の削減: 特にプライベート相互接続容量と組み合わせた場合、インターネット下り（外向き）と比較して、AWS または Azure からの下り（外向き）料金が低くなる可能性があります。
- 一貫したパフォーマンス: 公共のインターネットと比較して、ネットワークのレイテンシと帯域幅をより予測しやすくなります。
アーキテクチャの概要
プライベート クエリを有効にするには、プライベート相互接続を介して BigQuery から Amazon S3 バケットまたは ADLS Gen2 コンテナへのパスを構成します。Google Cloud Virtual Private Cloud（VPC）の重要なコンポーネントは、内部ロードバランサ（ILB）です。ILB は、BigQuery から AWS VPC 内の Amazon S3（AWS PrivateLink を使用してプロビジョニング）または Azure Virtual Network（VNet）内の ADLS Gen2（Azure Private Link を使用してプロビジョニング）のプライベート エンドポイントにリクエストを分散します。
複数の Elastic Network Interface（ENI）またはネットワーク インターフェース カード（NIC）をバックエンドとして使用する ILB は、ロード バランシング、スケーラビリティ、高可用性に不可欠です。これは、Dedicated CCI と Partner Interconnect のどちらを使用する場合にも当てはまります。
プライベート クエリのワークフローは次のプロセスに従います。
- BigQuery は、Service Directory サービスで構成された接続を使用します。
- Service Directory は、サービス名を Google Cloud ILB の内部 IP アドレスに解決します。
- ILB は BigQuery からリクエストを受信し、構成されたバックエンドに分散します。
- ILB バックエンドは、ハイブリッド接続ネットワーク エンドポイント グループ（NEG）です。各 NEG は、AWS VPC の ENI または Azure VNet の NIC のプライベート IP アドレスを指します。
- トラフィックは、ILB から NEG を経由し、プライベート相互接続を介して AWS ENI または Azure NIC に流れます。
- Amazon S3 VPC インターフェース エンドポイント（AWS PrivateLink）の一部である AWS ENI、または ADLS Gen2 プライベート エンドポイント（Azure Private Link）の一部である Azure NIC は、Amazon S3 または ADLS Gen2 サービスへのプライベート アクセスを提供します。
パブリック インターネット（CCI なし）
プライベート相互接続を構成しない場合、リモート カタログへのクエリはデフォルトで公共のインターネットを介して送信されます。
パブリック インターネット経由でデータをクエリする場合は、次の点を考慮してください。
- 標準的な暗号化: データアクセス リクエストとデータ転送は、公共のインターネットを介して標準の TLS プロトコルを使用して転送中に暗号化されます。
- 下り（外向き）料金: データ転送には、リモート クラウド プロバイダ（AWS や Azure など）からの標準のインターネット下り（外向き）料金が発生します。これは通常、プライベート相互接続の下り（外向き）料金よりも高くなります。
- 変動するレイテンシ: ネットワーク パフォーマンス、帯域幅、レイテンシは、パブリック インターネットのルーティングと輻輳に依存するため、専用のプライベート相互接続と比較して、クエリ実行時間の予測が難しくなります。
- 簡素化された設定: Google Cloud またはリモート クラウド プロバイダで追加のネットワーキング インフラストラクチャ、VPC ピアリング、Service Directory の構成は必要ありません。
アーキテクチャの概要
パブリック インターネット経由でデータをクエリする場合、Lakehouse は、プライベート Google Cloud やリモート クラウド ネットワーキング インフラストラクチャを必要とせずに、リモート カタログとオブジェクト ストレージのエンドポイントに直接接続します。
パブリック インターネット クエリのワークフローは次のプロセスに従います。
- BigQuery は、Lakehouse カタログで定義されたリモートテーブルに対してクエリを開始します。
- Lakehouse は、Secret Manager または OIDC トークン連携に保存されている認証情報を使用して、リモート Apache Iceberg カタログで安全に認証します。
- Lakehouse は、パブリック インターネット経由でテーブル メタデータとマニフェスト ファイルを取得し、関連する基盤となるデータファイル（Amazon S3 や ADLS Gen2 など）を特定します。
- 基盤となるオブジェクトのデータアクセス リクエストは、標準の TLS 暗号化を使用して、パブリック インターネット経由でGoogle Cloud から直接送信されます。
- リモート ストレージ サービスは、Lakehouse から提供された一時的なスコープ付き認証情報を使用してリクエストを検証し、リクエストされたファイル ブロックをパブリック インターネット経由で Google Cloudに返します。
インテリジェントなキャッシング
クロスクラウドの下り（外向き）コストを削減し、同じファイルブロックを読み取るクエリを高速化するために、Lakehouse 連携カタログと BigQuery クロスクラウド接続でクロスクラウド キャッシュを有効にできます。追加料金は発生しません。
クロスクラウド キャッシュを有効にすると、Lakehouse は Amazon S3 または Azure Blob Storage から取得したファイル ブロックを Google Cloud クエリ実行リージョン内にローカルにキャッシュします。同じファイルブロックをターゲットとする異なるクエリを含む後続のクエリは、リモート クラウドからファイルを再取得するのではなく、ローカル キャッシュから直接読み取ります。
Google は、キャッシュ容量、保持、エビクションを自動的に管理します。実際の下り（外向き）コストの削減は、クエリパターン、ソースファイルの変更頻度、ターゲット Google Cloudリージョンのキャッシュ保持によって異なります。キャッシュに保存されたデータを提供する前に、すべてのクエリでリモート ストレージ ソースのメタデータとアクセス権限が検証されます。これにより、古いデータが読み取られたり、取り消された権限がバイパスされたりすることはありません。
クロスクラウド キャッシュはデフォルトで無効になっています。キャッシュ保存は、Lakehouse 連携カタログまたは BigQuery クロスクラウド接続を作成または更新するときに有効または無効にできます。構成手順については、サポートされているカタログ プロバイダのセットアップ ガイドまたはクロスクラウド接続を作成するをご覧ください。
キャッシュの使用状況と下り（外向き）費用の削減を確認する
キャッシュ ヒット率を確認して下り（外向き）コストの削減を測定するには、BigQuery コンソールでジョブの詳細を調べるか、BigQuery の JobStatistics2 クエリジョブ統計の objectStorageStats（object_storage_stats）フィールドを確認します。
cloudProvider（cloud_provider）: オブジェクト ストレージをホストするクラウド プロバイダ（例:AWS、AZURE）。cacheBytesRead（cache_bytes_read）: ローカル Google Cloud キャッシュから読み取られた合計バイト数。リモート オブジェクト ストレージの読み取りは回避されます。objectStorageBytesRead（object_storage_bytes_read）: クラウド プロバイダのオブジェクト ストレージから直接読み取られた合計バイト数。
bq コマンドライン ツールを使用してこれらの指標を取得する手順については、キャッシュの使用状況と下り（外向き）コストの削減をモニタリングするをご覧ください。
データ所在地と管轄区域に関する考慮事項
クロスクラウド キャッシュを有効にすると、Lakehouse は、クエリが実行される Google Cloud リージョンに、リモート ファイルのキャッシュに保存されたコピーを一時的に保存します。別の地理的リージョンまたは管轄区域にあるファイル（us-east4 からクエリされた欧州連合の Amazon S3 や Azure Blob Storage など）のキャッシュを有効にする前に、ターゲットのGoogle Cloud リージョンに一時的なキャッシュ コピーを保存することが、組織のデータ所在地とコンプライアンスの要件を満たしていることを確認してください。
暗号化と CMEK のサポート
キャッシュに保存されたデータは、デフォルトのGoogle-owned and Google-managed encryption keysを使用して保存データの暗号化が行われます。顧客管理の暗号鍵（CMEK）は、クロスクラウド キャッシュではサポートされていません。
組織で CMEK 以外のサービスを制限する組織のポリシー制約（constraints/gcp.restrictNonCmekServices）が適用されている場合、Lakehouse は制限付きテーブルにアクセスするクエリのキャッシュを自動的に無効にします。クエリは引き続き実行されますが、ファイル ブロックをキャッシュに保存せずにリモート ストレージから直接読み取ります。
ID モード
Lakehouse は、クロスクラウド データアクセス用に 2 つの ID モードをサポートしています。
- サービス ID（デフォルト）: バックグラウンド メタデータの更新とクエリの両方が、カタログのサービス アカウントを使用して実行されます。このアカウントは、OIDC（推奨）または Secret ベースの認証で構成できます。
ユーザー ID 連携: バックグラウンド メタデータの更新はカタログのサービス アカウントを使用して実行されますが、クエリはエンドユーザーの ID を使用して実行され、リモート カタログに伝播されます。これにより、リモート カタログは Google Cloud からのクエリをエンドユーザーに帰属させ、権限の適用と監査ログの生成を可能にします。リモートカタログで ID 連携を構成する必要があります。