クロスクラウドの Lakehouse について

クロスクラウド レイクハウスを使用すると、ファイルを移行したり、 複雑な ETL パイプラインを構築したりすることなく、他のクラウド プロバイダに保存されているデータに直接クエリを実行できます。 Google Cloud

この機能は Lakehouse の一部であり、BigQuery、 スタンドアロンの Apache Spark 環境、または Managed Service for Apache Spark を使用して、分散データセット全体で統合 分析を実行し、AI を適用できます。

分析クエリに加えて、連携データを使用して AI 主導の分析情報とガバナンスを実現できます。

  • 会話分析: クロスクラウド テーブルなど、正確なデータソースに基づいて特殊なエージェントを構築し、1 回の会話でクラウド全体のデータを分析します。
  • Knowledge Catalog: 連携データソースを使用して、データ プロファイリングと分析情報に Knowledge Catalog の機能を使用します。

ユースケース

クロスクラウド レイクハウスは、複数のクラウド プロバイダにわたるデータへのアクセスに関するいくつかの重要なユースケースをサポートしています。

  • データ移動の削減 により、他のクラウド環境に保存されているデータに直接クエリを実行できるため、データアクセスと処理が簡素化されます。
  • 統合分析 により、データの保存場所に関係なく、すべてのデータに対して一貫した機能とハードウェアの最適化を使用して高度な分析を実行できます。
  • クロスクラウド AI と ML により、AI モデル、自律型エージェント、機械学習をリモートデータに直接適用できます。データを移行する必要はありません。

クロスクラウド レイクハウスの仕組み

クロスクラウド レイクハウスは、次のプロセスを使用してリモートデータにクエリを実行します。

  1. メタデータの検出: Google Cloud's Lakehouse は、Databricks Unity や AWS Glue などのリモート Apache Iceberg REST カタログに接続します。Lakehouse は、ファイルをコピーせずにデータを検出します。リモート カタログ プロバイダに応じて、Lakehouse は Secret Manager または OpenID Connect トークン フェデレーション（ID プロバイダとしての Google）を使用して安全に認証します（OIDC トークン フェデレーション）。
  2. 安全な転送: トラフィックをプライベート インターコネクト（Dedicated CCI や Partner Interconnect など）経由でルーティングすると、公共のインターネットと比較してデータ転送の費用が大幅に削減され、レイテンシを予測しやすくなります。
  3. 最適化された実行: クエリがリモートクラウドからデータを読み取ると、 Lakehouse はこれらのデータセグメントを一時的に の専用ストレージにローカルにキャッシュします。 Google Cloud 後続のクエリではローカル キャッシュが使用されるため、クロスクラウドの下り（外向き）料金の大部分を回避できます。

サポートされているカタログ

クロスクラウド レイクハウスは、次のリモート カタログ プロバイダからのデータのクエリをサポートしています。

  • 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 コネクタを使用してサポートされています。

基本コンセプト

このセクションでは、クロスクラウド レイクハウスを使用するために不可欠な主要コンポーネントについて説明します。

リモート Apache Iceberg REST カタログ

これはメタデータ レイヤです。リモート Apache Iceberg REST カタログに接続します。 Lakehouse は、ファイルをコピーせずにデータを検出します。Lakehouse は、OIDC トークン フェデレーションまたは OAuth 認証情報を使用して、有効期間の長いアクセスキーを必要とせずに安全に認証します。

クロスクラウド レイクハウスの連携カタログは、更新間隔に基づいてリモート Apache Iceberg REST カタログからメタデータを同期します。カタログのバックグラウンド メタデータの更新は、名前空間とテーブル リソースが多いほど時間がかかることがあります。前回の更新がオーバーランした場合、現在の更新はスキップされますが、次の更新は次の間隔でスケジュールされます。

トランスポート層

これはトランスポート レイヤです。公共のインターネットまたは専用のプライベート インターコネクト経由で、リモート クラウド プロバイダに保存されているデータにクエリを実行するように Lakehouse を構成できます。このセクションは、SAP Business データクラウド（BDC）接続には適用されません。

アーキテクチャとセキュリティの要件に一致する転送方法を選択します。

お客様所有（CCI）

BigQuery を構成して、プライベート クロスクラウド インターコネクト経由で Amazon Web Services（AWS）Amazon S3 バケットに保存されているデータにクエリを実行できます。使用できるのは、Dedicated Cross-Cloud Interconnect または Partner Cross-Cloud Interconnect です。

プライベート インターコネクトを使用すると、次のメリットがあります。

  • セキュリティの強化: データは と AWS 間のプライベート ネットワーク接続を介して転送され、公共の インターネットは経由しません。 Google Cloud
  • コストの削減: 特にプライベート インターコネクトの容量と組み合わせた場合、インターネットの下り（外向き）と比較して、AWS からの下り（外向き）料金が低くなる可能性があります。
  • 一貫したパフォーマンス: 公共のインターネットと比較して、ネットワークのレイテンシと帯域幅を予測しやすくなります。

アーキテクチャの概要

プライベート クエリを有効にするには、プライベート インターコネクトを介して BigQuery から AWS Amazon S3 バケットへのパスを構成します。Virtual Private Cloud（VPC）（VPC）の主要コンポーネントは、 Google Cloud 内部ロードバランサ（ILB）です。ILB は、BigQuery から AWS VPC 内の Amazon S3 のプライベート エンドポイントにリクエストを分散します。これらのエンドポイントは AWS PrivateLink を使用してプロビジョニングされます。

複数の Elastic Network Interface（ENI）をバックエンドとして使用する ILB は、負荷分散、スケーラビリティ、高可用性に不可欠です。これは、Dedicated CCI または Partner Interconnect を使用する場合に適用されます。

プライベート クエリのワークフローは次のプロセスに従います。

  1. BigQuery は、Service Directory サービスで構成された接続を使用します。
  2. Service Directory は、サービス名を ILB の Google Cloud 内部 IP アドレスに解決します。
  3. ILB は BigQuery からリクエストを受信し、構成されたバックエンドに分散します。
  4. ILB バックエンドはハイブリッド接続ネットワーク エンドポイント グループ（NEG）で、それぞれが AWS VPC 内の ENI のプライベート IP アドレスを指しています。
  5. トラフィックは ILB から NEG を経由して、プライベート インターコネクトを介して AWS ENI に流れます。
  6. AWS ENI は、Amazon S3 VPC インターフェース エンドポイント（AWS PrivateLink）の一部であり、Amazon S3 サービスへのプライベート アクセスを提供します。

公共のインターネット（CCI なし）

プライベート インターコネクトを構成しない場合、リモート カタログへのクエリはデフォルトで公共のインターネット経由で転送されます。

公共のインターネット経由でデータにクエリを実行する場合は、次の影響を考慮してください。

  • 標準暗号化: データアクセス リクエストとデータ転送は、公共のインターネット経由で標準の TLS プロトコルを使用して転送中に暗号化されます。
  • 下り（外向き）の費用: データ転送には、リモート クラウド プロバイダ（AWS など）から標準のインターネット下り（外向き）料金が発生します。通常、この料金はプライベート インターコネクトの下り（外向き）料金よりも高くなります。
  • レイテンシの変動: ネットワーク パフォーマンス、帯域幅、レイテンシは、公共のインターネットのルーティングと輻輳に依存するため、専用のプライベート インターコネクトと比較して、クエリの実行時間を予測しにくくなります。
  • 設定の簡素化: またはリモート クラウド プロバイダで、追加のネットワーク インフラストラクチャ、 VPC ピアリング、Service Directory の構成は必要ありません。 Google Cloud

アーキテクチャの概要

公共のインターネット経由でデータにクエリを実行する場合、Lakehouse は プライベート Google Cloud またはリモート クラウド ネットワーキング インフラストラクチャを必要とせずに、リモート カタログとオブジェクト ストレージ エンドポイントに 直接接続します。

公共のインターネット クエリのワークフローは次のプロセスに従います。

  1. BigQuery は、Lakehouse カタログで定義された連携テーブルに対してクエリを開始します。
  2. Lakehouse は、Secret Manager に保存されている認証情報または OIDC トークン フェデレーションを使用して、リモート Apache Iceberg カタログで安全に認証します。
  3. Lakehouse は、公共のインターネット経由でテーブル メタデータとマニフェスト ファイルを取得して、関連する基盤となるデータファイル（AWS Amazon S3 など）を特定します。
  4. 基盤となるオブジェクトのデータアクセス リクエストは、標準の TLS 暗号化を使用して公共のインターネット経由で Google Cloud から直接送信されます。
  5. リモート ストレージ サービスは、Lakehouse によって提供される一時的なスコープ付き 認証情報を使用してリクエストを検証し、リクエストされた データブロックを公共のインターネット経由で に返します Google Cloud。

次のステップ

  • AWS Glue 用のクロスクラウド レイクハウスを設定する。
  • Databricks Unity Catalog 用のクロスクラウド レイクハウスを設定する。
  • Snowflake 用のクロスクラウド レイクハウスを設定する。