ボーダーレス レイクハウスを使用すると、ファイルを移行したり、複雑な ETL パイプラインを構築したりすることなく、 Google Cloud から他のクラウド プロバイダに保存されているデータを直接クエリできます。
Lakehouse for Apache Iceberg の一部として、この機能を使用すると、BigQuery、スタンドアロンの Apache Spark 環境、または Managed Service for Apache Spark を使用して、分散データセット全体で統合分析を実行し、AI を適用できます。
分析クエリに加えて、連携データは AI を活用した分析情報とガバナンスにも使用できます。
- 会話型分析: クロスクラウド テーブルなどの正確なデータソースに基づいて、専門のエージェントを構築し、単一の会話からクラウド全体のデータを分析します。
- Knowledge Catalog: 統合データソースを使用して、データ プロファイリングと分析に Knowledge Catalog の機能を使用します。
ユースケース
ボーダーレス Lakehouse は、複数のクラウド プロバイダにわたってデータにアクセスするためのいくつかの重要なユースケースをサポートしています。
- データ移動の削減により、他のクラウド環境に保存されているデータを直接クエリできるため、データアクセスと処理が簡素化されます。
- 統合分析を使用すると、データの保存場所に関係なく、すべてのデータに対して一貫した機能とハードウェアの最適化を使用して高度な分析を実行できます。
- ボーダーレス AI と ML を使用すると、AI モデル、自律エージェント、ML をリモートデータに直接適用できます。データを移行する必要はありません。
ボーダーレス Lakehouse の仕組み
ボーダーレス Lakehouse は、次のプロセスを使用してリモートデータをクエリします。
- メタデータの検出: Google Cloudの Lakehouse は、Databricks Unity や AWS Glue などのリモート Apache Iceberg REST カタログに接続します。レイクハウスは、ファイルをコピーせずにデータを検出します。リモート カタログ プロバイダに応じて、Lakehouse は Secret Manager または Google を ID プロバイダとする OpenID Connect トークン フェデレーション（OIDC トークン フェデレーション）を介して安全に認証します。
- 安全な転送: トラフィックをプライベート相互接続（Dedicated CCI や Partner Interconnect など）経由でルーティングすると、公共のインターネットと比較してデータ転送費用が大幅に削減され、レイテンシの予測可能性が高まります。
- 実行の最適化: クエリがリモートクラウドからデータを読み取ると、Lakehouse はこれらのデータ セグメントを Google Cloud 内の専用ストレージに一時的にローカルでキャッシュに保存します。後続のクエリではローカル キャッシュが使用されるため、クラウド間の下り（外向き）料金の大部分を回避できます。
サポートされているカタログ
ボーダーレス Lakehouse は、次のリモート カタログ プロバイダからのデータクエリをサポートしています。
- Databricks Unity Catalog: Amazon Web Services（AWS）とGoogle Cloudでサポートされています。
- AWS Glue: Amazon Web Services（AWS）でサポートされています。
- Snowflake: Amazon Web Services（AWS）と Google Cloudでサポートされています。
- SAP Business Data Cloud（BDC）: SAP BDC コネクタを使用してサポートされます。
基本コンセプト
このセクションでは、ボーダーレス Lakehouse の使用に不可欠な主要コンポーネントについて説明します。
リモート Apache Iceberg REST カタログ
これがメタデータ レイヤです。リモートの Apache Iceberg REST カタログに接続します。Lakehouse は、ファイルをコピーせずにデータを検出します。Lakehouse は、OIDC トークン連携または OAuth 認証情報を使用して、有効期間の長いアクセスキーを必要とせずに安全に認証します。
ボーダーレス Lakehouse の連携カタログは、更新間隔に基づいてリモートの Apache Iceberg REST カタログからメタデータを同期します。カタログのバックグラウンド メタデータの更新は、名前空間とテーブル リソースが多いほど時間がかかることがあります。前回の更新がオーバーランした場合、現在の更新はスキップされますが、次の更新は次の間隔でスケジュールされます。
トランスポート層
これはトランスポート レイヤです。公共のインターネットまたは専用のプライベート相互接続を介して、リモート クラウド プロバイダに保存されているデータをクエリするように Lakehouse を構成できます。このセクションは、SAP Business Data Cloud（BDC）接続には適用されません。
アーキテクチャとセキュリティの要件に一致する転送方法を選択します。
お客様所有（CCI）
専用の Cross-Cloud Interconnect または パートナーの Cross-Cloud Interconnect を使用して、プライベート Cross-Cloud Interconnect 経由でアマゾン ウェブ サービス（AWS）の Amazon S3 バケットに保存されているデータをクエリするように BigQuery を構成できます。
プライベート相互接続を使用すると、次のメリットがあります。
- セキュリティの強化: データは Google Cloud と AWS 間のプライベート ネットワーク接続を介して移動するため、公共のインターネットを回避できます。
- コストの削減: 特にプライベート相互接続容量と組み合わせた場合、インターネット下り（外向き）と比較して、AWS からの下り（外向き）料金を削減できる可能性があります。
- 一貫したパフォーマンス: パブリック インターネットと比較して、ネットワークのレイテンシと帯域幅をより予測できます。
アーキテクチャの概要
プライベート クエリを有効にするには、プライベート相互接続を介して BigQuery から AWS Amazon S3 バケットへのパスを構成します。 Google CloudVirtual Private Cloud（VPC）（VPC）の重要なコンポーネントは、内部ロードバランサ（ILB）です。ILB は、BigQuery からのリクエストを AWS VPC 内の Amazon S3 のプライベート エンドポイントに転送します。これらのエンドポイントは、AWS PrivateLink を使用してプロビジョニングされます。
ロード バランシング、スケーラビリティ、高可用性を実現するには、複数の Elastic Network Interface（ENI）をバックエンドとして使用する ILB が不可欠です。これは、Dedicated CCI と Partner Interconnect のどちらを使用する場合にも該当します。
プライベート クエリのワークフローは次のプロセスに従います。
- BigQuery は、Service Directory サービスで構成された接続を使用します。
- Service Directory は、サービス名を Google Cloud ILB の内部 IP アドレスに解決します。
- ILB は BigQuery からリクエストを受け取り、構成されたバックエンドに分散します。
- ILB バックエンドはハイブリッド接続ネットワーク エンドポイント グループ（NEG）で、それぞれが AWS VPC の ENI のプライベート IP アドレスを指しています。
- トラフィックは ILB から NEG を経由して、プライベート相互接続を介して AWS ENI に流れます。
- Amazon S3 VPC インターフェース エンドポイント（AWS PrivateLink）の一部である AWS ENI は、Amazon S3 サービスへのプライベート アクセスを提供します。
公共のインターネット（CCI なし）
プライベート相互接続を構成しない場合、リモート カタログへのクエリはデフォルトで公共のインターネット経由で送信されます。
パブリック インターネット経由でデータをクエリする場合は、次の影響を考慮してください。
- 標準の暗号化: データアクセス リクエストとデータ転送は、パブリック インターネット全体で標準の TLS プロトコルを使用して転送中に暗号化されます。
- 下り（外向き）の費用: データ転送では、通常、プライベート相互接続の下り（外向き）料金よりも高い、リモート クラウド プロバイダ（AWS など）の標準インターネット下り（外向き）料金が発生します。
- レイテンシの変動: ネットワークのパフォーマンス、帯域幅、レイテンシは、公共のインターネットのルーティングと輻輳に依存するため、専用のプライベート相互接続と比較して、クエリの実行時間が予測しにくくなります。
- 設定の簡素化: Google Cloud またはリモート クラウド プロバイダで、追加のネットワーキング インフラストラクチャ、VPC ピアリング、Service Directory の構成は必要ありません。
アーキテクチャの概要
公共のインターネット経由でデータをクエリする場合、Lakehouse はプライベート Google Cloud またはリモート クラウド ネットワーキング インフラストラクチャを必要とせずに、リモート カタログとオブジェクト ストレージ エンドポイントに直接接続します。
公共インターネット クエリのワークフローは、次のプロセスに沿って行われます。
- BigQuery は、Lakehouse カタログで定義された連携テーブルに対してクエリを開始します。
- Lakehouse は、Secret Manager に保存されている認証情報または OIDC トークン連携を使用して、リモート Apache Iceberg カタログで安全に認証します。
- Lakehouse は、パブリック インターネット経由でテーブル メタデータとマニフェスト ファイルを取得し、関連する基盤となるデータファイル（AWS Amazon S3 など）を特定します。
- 基盤となるオブジェクトのデータアクセス リクエストは、標準の TLS 暗号化を使用して、Google Cloud からパブリック インターネット経由で直接送信されます。
- リモート ストレージ サービスは、Lakehouse によって提供された一時的なスコープ付き認証情報を使用してリクエストを検証し、リクエストされたデータブロックをパブリック インターネット経由で Google Cloudに返します。
次のステップ
- AWS Glue 用のボーダーレス Lakehouse を設定します。
- Databricks Unity Catalog 用にボーダレス レイクハウスを設定します。
- Snowflake 用のボーダーレス Lakehouse を設定します。