Snowflake 用のクロスクラウド Lakehouse を設定する

このドキュメントでは、クロスクラウド Lakehouse を設定して、Google Cloud内から Snowflake カタログ(Snowflake Horizon)のデータを直接クエリする方法について説明します。この機能は、外部データソースを既存の Google Cloud環境と統合することで、データ分析を統合します。

その後、Lakehouse を使用して、フェデレーション データへのアクセスを管理できます。

始める前に

  1. Lakehouse の概要を確認して、Lakehouse がデータへのアクセスを管理する方法を理解します。
  2. その仕組みについては、クロスクラウド Lakehouse についてをご覧ください。
  3. サポートされているカタログを確認して、外部ロケーションの要件とサポートされている構成を確認します。
  4. リージョン Secret Manager シークレットの使用方法を理解する。これは、シークレット ベースの認証を使用して Snowflake でクロスクラウド Lakehouse を設定するために必要です。
  5. シークレット ベースの認証を使用する場合は、ターゲット カタログへの読み取りアクセス権を持つ個人用アクセス トークン(PAT)を Snowflake Horizon 環境内で生成します。このプロセスは、このドキュメントの対象範囲外です。
  6. Workload Identity 連携を使用している場合は、サービスユーザーをプロビジョニングするための ACCOUNTADMIN 権限で Snowflake アカウント UI にアクセスできることを確認してください。
  7. 省略可: Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)間のプライベート相互接続を介してクエリをルーティングする場合は、リモート プロバイダのアカウントが有効であることを確認し、Dedicated Cross-Cloud InterconnectまたはPartner Cross-Cloud Interconnectをプロビジョニングし、Cloud Router との BGP セッションを確立し、両方のクラウド環境で必要な Identity and Access Management(IAM)権限があることを確認します。
  8. Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the BigLake, Secret Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Verify that billing is enabled for your Google Cloud project.

  12. Enable the BigLake, Secret Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

必要なロール

クロスクラウド Lakehouse の設定に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

  • Lakehouse カタログを管理する: BigLake 管理者 roles/biglake.admin
  • シークレットを管理する: Secret Manager 管理者 roles/secretmanager.admin
  • プライベート相互接続でトラフィックをルーティングする: Compute ネットワーク管理者(roles/compute.networkAdmin)、Service Directory 閲覧者(roles/servicedirectory.viewer)、Service Directory PSC 承認済みサービス(roles/servicedirectory.pscAuthorizedService

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

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

このガイドでは、Amazon Web Services(AWS)と Google Cloudで Snowflake カタログ(Snowflake Horizon)を使用してクロスクラウド Lakehouse を設定する手順について説明します。外部ロケーションの要件とサポートされている構成の詳細については、サポートされているカタログをご覧ください。

制限事項と考慮事項

このセクションでは、クロスクラウド Lakehouse の使用に関する制限事項と考慮事項について説明します。

  • サポートされているクラウド プロバイダ: クロスクラウド Lakehouse でのプライベート相互接続の使用は、次のリモート クラウド プロバイダでサポートされています。アマゾン ウェブ サービス(AWS)。専用の Cross-Cloud Interconnect または パートナーの Cross-Cloud Interconnect を使用できます。
  • ネットワーク ルーティング: プライベート インターコネクト(Dedicated CCI や Partner CCI など)が構成されていない場合、クエリは公共のインターネット経由でルーティングされます。これにより、リモート クラウド プロバイダからの下り(外向き)料金が増加し、パフォーマンスの予測可能性が低下する可能性があります。
  • データの更新速度: フェデレーション カタログの --refresh-interval フラグは、メタデータの同期頻度を決定します。間隔を短くすると、より新しいデータが提供されますが、リモート カタログ プロバイダから追加の API 費用が発生する可能性があります。
  • Iceberg 指標レポート: Iceberg 指標レポートは、フェデレーション カタログでは使用できません。連携カタログにアクセスするときに、Iceberg クライアントで rest-metrics-reporting-enabled プロパティを false に設定します。

全般的なワークフロー

クロスクラウド Lakehouse を設定して使用する一般的な手順は次のとおりです。

  • Cross-Cloud Interconnect を設定する(省略可): Google Cloud VPC とリモート クラウド プロバイダの間にプライベート接続を構成します。
  • 連携を設定する: 認証を構成し、Lakehouse に連携カタログを作成します。
    • シークレットベースの認証(PAT): リモート カタログの認証情報を使用して、Secret Manager にシークレットを作成します。次に、Lakehouse に連携カタログを作成し、カタログ サービス アカウントにシークレットへのアクセス権を付与します。
    • Workload Identity 連携(WIF): 必要な Snowflake ロールを指定して、Lakehouse に連携カタログを作成します。次に、カタログのサービス アカウント ID を Snowflake のサービス ユーザーにリンクします。Snowflake サービス ユーザーには、リモート Snowflake カタログに対する使用権限が必要です。
  • 接続を確認する: Lakehouse がリモート カタログに正常に接続できることを確認します。
  • データをクエリする: BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。詳細については、クロスクラウド Lakehouse を使用するをご覧ください。
  • 権限を構成する: IAM を使用して、統合データを表示してクエリできるユーザーを管理します。

Cross-Cloud Interconnect を設定する(省略可)

リモート カタログに対するクエリは、デフォルトで公共のインターネットを経由します。セキュリティとコンプライアンスの強化、予測可能なパフォーマンスの提供、データ転送費用の削減に役立つプライベート相互接続を使用します。これにより、 Google CloudVirtual Private Cloud(VPC)とリモート クラウド プロバイダのネットワーク(AWS など)の間に専用のプライベート ネットワーク接続が確立されます。

Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)の間に、次のいずれかのプライベート相互接続オプションをプロビジョニングして構成できます。

Google Cloud の Cloud Router とリモート クラウド プロバイダの VPC の間に BGP セッションを確立し、ルート交換を確保します。

プライベート クエリを有効にするには、プライベート相互接続を介して Lakehouse からリモート ストレージ バケット(AWS Amazon S3 バケットなど)へのパスを構成する必要があります。このルーティングを構成するには、次の 2 つのアーキテクチャ フローがあります。

  • 内部リージョン プロキシ ネットワーク ロードバランサのルーティング: このフローでは、Google Cloud 内部リージョン プロキシ ネットワーク ロードバランサを使用して、複数の AWS Elastic Network Interface(ENI)を指すハイブリッド接続ネットワーク エンドポイント グループ(NEG)にリクエストを分散します。このフローは、ロード バランシング、スケーラビリティ、高可用性に不可欠です。Partner CCI では必須であり、Dedicated CCI ではロード バランシング、スケーラビリティ、高可用性のために推奨されます。
  • 直接エンドポイント ルーティング: このフローは、Service Directory を単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接接続します。このフローは専用 CCI でのみ機能し、パートナー CCI では対象外です。

アーキテクチャ要件に合った構成フローを選択します。

内部リージョン プロキシ ネットワーク ロードバランサ

高可用性とロード バランシングのために、複数の AWS ENI にリクエストを分散するように内部リージョン プロキシ ネットワーク ロードバランサを構成する手順は次のとおりです。

AWS ネットワーキングを構成する

まず、Amazon S3 VPC インターフェース エンドポイント(AWS PrivateLink)を作成します。

  1. AWS VPC コンソールで、Amazon S3 のインターフェース エンドポイントを作成します。
  2. サービス名に「com.amazonaws.AWS_REGION.s3」と指定します。
  3. Direct Connect を介して Google Cloud VPC に接続されている VPC とサブネットを選択します。
  4. セキュリティ グループをエンドポイントに接続して、インバウンド アクセスを制御します。
  5. これにより、選択した各サブネットに Elastic Network Interface(ENI)がプロビジョニングされます。これらの ENI のプライベート IP アドレスをメモします。

次に、セキュリティ グループを構成します。

  • Amazon S3 エンドポイント ENI に関連付けられているセキュリティ グループで、 Google Cloud VPC からポート 443 への TCP トラフィックの受信が許可されていることを確認します。これには、ヘルスチェックと転送されたトラフィックを許可するGoogle Cloud プロキシ専用サブネットの CIDR の範囲を含める必要があります。

Google Cloud ネットワーキングを構成する

設定を簡素化するには、次のコマンドを実行して内部ロードバランサを構成します。高度な構成または詳細については、ハイブリッド エンドポイント用に内部リージョン プロキシ ネットワーク ロードバランサを設定するをご覧ください。

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

次のように置き換えます。

  • PROXY_SUBNET_NAME: プロキシ専用サブネットの名前。
  • PROXY_SUBNET_RANGE: VPC ネットワーク内の未使用の CIDR の範囲(10.129.0.0/23 など)。
  1. リージョン ヘルスチェックを作成します。

    gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
        --region=REGION \
        --port=443

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェックの名前。
    • REGION: Google Cloud リージョン(例: us-east4)。
  2. ハイブリッド接続ネットワーク エンドポイント グループ(NEG)を作成してエンドポイントを追加します。

    各ゾーンにハイブリッド NEG(NON_GCP_PRIVATE_IP_PORT)を作成します。

    gcloud compute network-endpoint-groups create NEG_NAME \
        --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
        --zone=ZONE \
        --network=VPC_NETWORK

    AWS ENI のプライベート IP アドレスを対応するハイブリッド NEG に追加します。

    gcloud compute network-endpoint-groups update NEG_NAME \
        --zone=ZONE \
        --add-endpoint="ip=AWS_S3_IP,port=443"

    次のように置き換えます。

    • NEG_NAME: ハイブリッド NEG の名前。
    • ZONE: Google Cloud ゾーン(例: us-east4-a)。このゾーンは、Cross-Cloud Interconnect VLAN アタッチメントのリージョン内に存在する必要があります。
    • VPC_NETWORK: VPC ネットワークの名前。
    • AWS_S3_IP: そのゾーンの AWS Amazon S3 VPC エンドポイント(ENI)のプライベート IP アドレス。

    AWS ENI が複数のゾーンに分散している場合は、これらのコマンドを繰り返して NEG を作成し、他のゾーンのエンドポイントを追加します。

  3. バックエンド サービスを作成して構成します。

    内部マネージド ロード バランシングを使用してリージョン バックエンド サービスを作成します。

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --protocol=TCP \
        --region=REGION \
        --health-checks=HEALTH_CHECK_NAME \
        --health-checks-region=REGION

    ハイブリッド NEG をバックエンド サービスに追加します。

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
        --region=REGION \
        --network-endpoint-group=NEG_NAME \
        --network-endpoint-group-zone=ZONE \
        --balancing-mode=CONNECTION \
        --max-connections=MAX_CONNECTIONS

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
    • NEG_NAME: 前の手順で作成したハイブリッド NEG の名前。
    • ZONE: Google Cloud ゾーン(例: us-east4-a)。
    • MAX_CONNECTIONS: バックエンドが処理する最大同時接続数(例: 100)。

    作成したハイブリッド NEG ごとに add-backend コマンドを繰り返します。

  4. ロードバランサのフロントエンドを構成します。

    ターゲット TCP プロキシを作成します。

    gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
        --backend-service=BACKEND_SERVICE_NAME \
        --region=REGION

    ターゲット プロキシにトラフィックをルーティングする転送ルールを作成します。

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --network=VPC_NETWORK \
        --subnet=VPC_SUBNET \
        --ports=443 \
        --region=REGION \
        --target-tcp-proxy=TARGET_PROXY_NAME \
        --target-tcp-proxy-region=REGION \
        --allow-global-access

    次のように置き換えます。

    • TARGET_PROXY_NAME: ターゲット プロキシの名前。
    • FORWARDING_RULE_NAME: 転送ルールの名前。
    • VPC_SUBNET: VPC サブネットワークの名前。

ロードバランサの転送ルールを作成したら、割り当てられた内部 IP アドレスをメモします。これが ILB_IP_ADDRESS です。

Service Directory を構成する

Lakehouse が検出できるように、ILB の IP アドレスを Service Directory に登録します。

  1. リモート クラウドの Namespace を作成します。

    gcloud service-directory namespaces create NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • NAMESPACE: 名前空間の一意の識別子。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
  2. Service Directory 名前空間にサービスを作成します。

    gcloud service-directory services create SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • SERVICE_NAME: サービスの一意の識別子。
  3. サービスで ILB のエンドポイントを作成します。

    gcloud service-directory endpoints create ENDPOINT_NAME \
        --project=PROJECT_ID \
        --namespace=NAMESPACE \
        --service=SERVICE_NAME \
        --location=REGION \
        --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
        --address=ILB_IP_ADDRESS \
        --port=443

    次のように置き換えます。

    • ENDPOINT_NAME: エンドポイントの一意の識別子。
    • PROJECT_NUMBER: Google Cloudプロジェクトの番号。--network フラグでプロジェクト番号を使用します。
    • ILB_IP_ADDRESS: ILB 転送ルールの内部 IP アドレス。

直接エンドポイント

トラフィックを単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接転送するようにサービス ディレクトリを構成する手順は次のとおりです。

  1. AWS VPC 内に Amazon S3 のインターフェース VPC エンドポイントを作成します。このエンドポイントの IP アドレスとポートをメモします。
  2. リモート クラウドの Namespace を作成します。

    gcloud service-directory namespaces create NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • NAMESPACE: 名前空間の一意の識別子。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
  3. Service Directory 名前空間にサービスを作成します。

    gcloud service-directory services create SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • SERVICE_NAME: サービスの一意の識別子。
  4. Amazon S3 インターフェース VPC エンドポイントのルーティング情報を含むエンドポイントをサービスに作成します。

    gcloud service-directory endpoints create ENDPOINT_NAME \
        --service=SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION \
        --address=S3_VPCE_IP_ADDRESS \
        --port=S3_VPCE_PORT \
        --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK

    次のように置き換えます。

    • ENDPOINT_NAME: エンドポイントの一意の識別子。
    • S3_VPCE_IP_ADDRESS: Amazon S3 インターフェース VPC エンドポイントの IP アドレス。例: 10.0.1.45
    • S3_VPCE_PORT: Amazon S3 インターフェース VPC エンドポイントのポート番号。例: 443
    • PROJECT_NUMBER: Google Cloudプロジェクトの番号。--network フラグでプロジェクト番号を使用します。
    • VPC_NETWORK: プライベート相互接続に関連付けられている Google Cloud VPC ネットワーク名。

連携を設定する

データをクエリするには、リモート Snowflake カタログに接続する Lakehouse 連携カタログを設定する必要があります。認証方法を選択します。

シークレット ベース(PAT)

認証を構成する

フェデレーションでは、リモート Snowflake カタログにアクセスするための認証情報が必要です。Snowflake Horizon では、セッションに必要な特定の Snowflake ロールとともに、Snowflake によって生成された有効期間の長いトークンである個人用アクセス トークン(PAT)を使用する必要があります。

リージョン Secret Manager でシークレットを作成して、認証情報を保存します。

  1. ペイロードを含む credentials.json という名前の JSON ファイルを作成します。

      {
        "client_secret": "SNOWFLAKE_PAT_TOKEN",
        "scope": "session:role:SNOWFLAKE_ROLE"
      }
      

    次のように置き換えます。

    • SNOWFLAKE_PAT_TOKEN: Snowflake 個人用アクセス トークン(PAT)。
    • SNOWFLAKE_ROLE: セッションに必要な特定の Snowflake ロール。例: ICEBERG_VIEW
  2. Secret Manager のリージョン エンドポイントを構成します。

    デフォルトでは、Secret Manager はグローバル エンドポイントを使用します。ただし、クロスクラウド Lakehouse では、シークレットが Lakehouse カタログと同じリージョンに保存されている必要があります。gcloud CLI を使用してリージョン シークレットを操作するには、現在のセッションまたはプロファイルのデフォルトの API エンドポイントをオーバーライドする必要があります。接続の問題を回避するには、シークレットとカタログを同じリージョンに作成する必要があります。

      gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
      

    次のように置き換えます。

    • REGION: Secret Manager のシークレットが保存されている Google Cloud リージョン。例: us-east4。接続の問題を回避するには、シークレットとカタログを同じリージョンに作成する必要があります。
  3. ペイロードを Secret Manager にアップロードします。

      gcloud secrets create SNOWFLAKE_SECRET_NAME \
        --location="REGION" \
        --project="PROJECT_ID" \
        --data-file=credentials.json
      

    次のように置き換えます。

    • SNOWFLAKE_SECRET_NAME: Snowflake シークレットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

    連携カタログを作成する

    gcloud alpha biglake iceberg catalogs create コマンドを使用して、フェデレーション カタログを作成します。

    公共のインターネット(CCI なし)

    CCI を構成しない場合、接続はパブリック インターネット経由で安全に転送されます。

      gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
          --project="PROJECT_ID" \
          --primary-location="REGION" \
          --catalog-type="federated" \
          --federated-catalog-type="snowflake" \
          --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
          --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
          --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
          --refresh-interval="REFRESH_INTERVAL" \
          --namespace-filters="NAMESPACE_FILTERS"
      

    次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: 連携カタログが作成される Lakehouse リージョン。例: us-east4レイテンシを最小限に抑えるには、Snowflake リージョンに最も近い Google Cloud リージョンを選択します。
    • SNOWFLAKE_SECRET_NAME: Snowflake シークレットの名前。
    • SNOWFLAKE_ACCOUNT_IDENTIFIER: Snowflake アカウント ID(例: my_org-my_account)。
    • SNOWFLAKE_WAREHOUSE: 連携する Snowflake カタログ名。
    • REFRESH_INTERVAL: 省略可。カタログの情報を更新する頻度を指定します。この値を期間として設定します(例: 330s5m30s)。間隔を短くすると、データの更新頻度は高くなりますが、API 呼び出しの費用が増加する可能性があります。間隔を長くすると費用を抑えることができますが、クエリされたデータが最新のデータセットを反映していない可能性があります。省略した場合、または値が 0s に設定されている場合、バックグラウンド メタデータの更新は開始されません。更新間隔が正の値に更新されるまで無効のままになります
    • NAMESPACE_FILTERS: 省略可: フェデレーションする名前空間のカンマ区切りのリスト。例: ns1,ns2省略すると、すべての名前空間が含まれます

    お客様所有(CCI)

    プライベート インターコネクト(Dedicated CCI や Partner CCI など)を構成した場合は、Lakehouse がトラフィックを非公開でルーティングできるように、Service Directory エンドポイント参照を指定します。

      gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
          --project="PROJECT_ID" \
          --primary-location="REGION" \
          --catalog-type="federated" \
          --federated-catalog-type="snowflake" \
          --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
          --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
          --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
          --refresh-interval="REFRESH_INTERVAL" \
          --namespace-filters="NAMESPACE_FILTERS" \
          --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"
      

    次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: 連携カタログが作成される Lakehouse リージョン。注: これは、Service Directory 名前空間とリージョン Secret と同じリージョンにする必要があります。
    • SNOWFLAKE_SECRET_NAME: Snowflake シークレットの名前。
    • SNOWFLAKE_ACCOUNT_IDENTIFIER: Snowflake アカウントの識別子。
    • SNOWFLAKE_WAREHOUSE: フェデレーションする Snowflake カタログ名
    • REFRESH_INTERVAL: 省略可。カタログの情報を更新する頻度を指定します。
    • NAMESPACE_FILTERS: 省略可: フェデレーションする Namespace のカンマ区切りのリスト。
    • NAMESPACE: プライベート相互接続の設定時に作成した Service Directory の名前空間。
    • SERVICE_NAME: プライベート相互接続の設定時に作成した Service Directory サービス名。
    • ENDPOINT_NAME: プライベート相互接続の設定時に作成した Service Directory エンドポイント名。

    認証の設定を完了する

    カタログが作成されると、Lakehouse はカタログの一意のサービス アカウントをプロビジョニングします(リソースの説明で biglake-service-account として返されます)。

    このサービス アカウントに、先ほど作成したシークレットへのアクセス権を付与する必要があります。IAM ポリシーの伝播には数分かかることがあります。

    カタログのサービス アカウントにシークレットへのアクセス権を付与します。

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
    gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
      --project="PROJECT_ID" \
      --location="REGION" \
      --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
          --project="PROJECT_ID" \
          --location="REGION" \
          --format='value(biglake-service-account)')" \
      --role="roles/secretmanager.secretAccessor"

    フェデレーション カタログ サービス アカウントがシークレットにアクセスできることを確認するには、次のコマンドを実行します。

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
    gcloud secrets get-iam-policy SNOWFLAKE_SECRET_NAME \
        --project="PROJECT_ID" \
        --location="REGION"

    出力で、biglake-service-account サービス アカウントに roles/secretmanager.secretAccessor ロールが割り当てられていることを確認します。

Workload Identity 連携

Workload Identity 連携(WIF)は、Lakehouse サービス アカウントを Snowflake サービス ユーザーに直接リンクすることで、有効期間の長いシークレットの使用を回避します。

連携カタログを作成する

Google Cloud コンソール、Lakehouse REST API、または gcloud CLI を使用して、フェデレーション カタログを作成します。使用する Snowflake ロールを指定する必要があります。

コンソール

シークレットベースの認証を使用して連携カタログを作成するには:

  1. Google Cloud コンソールで、[Lakehouse] に移動します。

    [レイクハウス] に移動

  2. [ カタログを作成] をクリックします。

  3. [連携カタログ] をクリックします。

    [カタログ構成] の詳細が表示されます。

  4. [Federated catalog source] で、[Snowflake Horizon] を選択します。

  5. [データのロケーション] で、フェデレーション カタログを作成する Lakehouse リージョンを選択します。例: us-east4レイテンシを最小限に抑える(パブリック インターネット経由でも)には、リージョンを選択する際に次の操作を行います。

    • Snowflake カタログが AWS にある場合は、AWS リージョンに最も近いGoogle Cloud リージョンを選択します。
  6. [続行] をクリックします。

    [接続の詳細] の詳細が表示されます。

  7. [リモート カタログの詳細] セクションの [Snowflake アカウント ID] フィールドに、Snowflake アカウント ID を入力します。例: my_org-my_account

  8. [Snowflake ウェアハウス] フィールドに、Snowflake ウェアハウスの名前を入力します。

  9. [シークレット] に、シークレットの名前を入力します。projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME 形式を使用します。

  10. 省略可: [Service Directory 名] フィールドに、Service Directory エンドポイントまたはサービスへのパスを入力します。これは、プライベート相互接続(Cross-Cloud Interconnect)を構成する場合にのみ必要です。

  11. [作成] をクリックします。

REST API

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  -d '{
    "catalog-type": "CATALOG_TYPE_FEDERATED",
    "federated-catalog-options": {
      "snowflake-catalog-info": {
        "account-identifier": "SNOWFLAKE_ACCOUNT_IDENTIFIER",
        "warehouse": "SNOWFLAKE_WAREHOUSE",
        "snowflake-role": "SNOWFLAKE_ROLE"
      },
      "refresh-options": {
        "refresh-schedule": {
          "refresh-interval": "REFRESH_INTERVAL"
        }
      }
    }
}' \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION"

gcloud CLI

公共のインターネット(CCI なし)

    gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
        --project="PROJECT_ID" \
        --primary-location="REGION" \
        --catalog-type="federated" \
        --federated-catalog-type="snowflake" \
        --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
        --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
        --snowflake-role="SNOWFLAKE_ROLE" \
        --refresh-interval="REFRESH_INTERVAL" \
        --namespace-filters="NAMESPACE_FILTERS"
    

お客様所有(CCI)

プライベート相互接続を構成した場合は、Lakehouse がトラフィックをプライベートにルーティングできるように、Service Directory サービス参照を指定します。

    gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
        --project="PROJECT_ID" \
        --primary-location="REGION" \
        --catalog-type="federated" \
        --federated-catalog-type="snowflake" \
        --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
        --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
        --snowflake-role="SNOWFLAKE_ROLE" \
        --refresh-interval="REFRESH_INTERVAL" \
        --namespace-filters="NAMESPACE_FILTERS" \
        --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"
    

次のように置き換えます。

  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: Snowflake アカウントの識別子。
  • SNOWFLAKE_WAREHOUSE: 連携する Snowflake カタログ名。
  • SNOWFLAKE_ROLE: セッションに必要な特定の Snowflake ロール。例: ICEBERG_VIEW
  • FEDERATED_CATALOG_NAME: Lakehouse 連携カタログの名前。
  • REGION: 連携カタログが作成される Lakehouse リージョン。
  • REFRESH_INTERVAL: 省略可。カタログの情報を更新する頻度を指定します。例: 300s
  • NAMESPACE_FILTERS: 省略可: フェデレーションする名前空間のカンマ区切りのリスト。例: ns1,ns2省略すると、すべての名前空間が含まれます
  • NAMESPACE: Service Directory サービスの Namespace。
  • SERVICE_NAME: Service Directory サービスの名前。
  • ENDPOINT_NAME: Service Directory エンドポイントの名前。

カタログを作成したら、そのサービス アカウント ID を Snowflake のサービス ユーザーにリンクする必要があります。

  1. カタログの詳細から Lakehouse サービス アカウント ID(サブジェクト)を抽出します。

    これは、作成コマンドの JSON レスポンス(フィールド biglake-service-account-id)から取得できます。

    または、カタログで describe コマンドを実行して値を取得することもできます。

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

    出力で biglake-service-account-id を探します。

  2. Snowflake 管理インスタンスにログインし、次のスクリプトを実行して、Lakehouse サービス ID との信頼関係を確立します。

    USE ROLE ACCOUNTADMIN;
    
    CREATE USER SNOWFLAKE_SERVICE_USER
    TYPE = SERVICE
    WORKLOAD_IDENTITY = (
      TYPE = GCP
      SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
    )
    DEFAULT_ROLE = SNOWFLAKE_ROLE
    COMMENT = 'Service user for Lakehouse federation over WIF';
    
    -- Also explicitly GRANT permissions to the role
    GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

    次のように置き換えます。

    • SNOWFLAKE_SERVICE_USER: Snowflake の新しいサービス ユーザーの名前。
    • LAKEHOUSE_SERVICE_ACCOUNT_ID: 前の手順で抽出したサービス アカウント ID。
    • SNOWFLAKE_ROLE: Snowflake ロール(カタログの作成時に指定したロールと一致する必要があります)。

接続を確認する

カタログのバックグラウンド メタデータの更新サイクルが正常に完了し、名前空間が同期されていることを確認します。

gcloud CLI

  1. 更新ステータスが成功を示していることを確認します。

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --location="REGION"
  2. リモート データベース スキーマが同期された Namespace として表示されることを確認します。

    gcloud alpha biglake iceberg namespaces list \
      --catalog="FEDERATED_CATALOG_NAME" \
      --project="PROJECT_ID" \
      --location="REGION"

REST API

  1. カタログ フェデレーションの同期ステータスを確認します。

    curl -X GET \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -H "Content-Type: application/json" \
      -H "x-goog-user-project: PROJECT_ID" \
      "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME"
  2. 同期された Namespace を一覧表示します。

    curl -X GET \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -H "Content-Type: application/json" \
      -H "x-goog-user-project: PROJECT_ID" \
      "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces"
  3. 同期された Namespace 内のテーブルを一覧表示します。

    curl -X GET \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -H "Content-Type: application/json" \
      -H "x-goog-user-project: PROJECT_ID" \
      "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces/NAMESPACE_NAME/tables"

次のステップ